We asked two Notion engineers — Alma Wang and Karunya Sethuraman — to share a behind-the-scenes look into their typical day at Notion. Alma started on the Platform team focused on Notion’s public API and integrations before transitioning to the Enterprise Engineering team, which builds features for Notion’s enterprise customers. Karunya is a full stack software engineer on the Collections team, which owns databases.
Here are their stories — in their own words:
I start my morning by walking into Notion’s NYC office and pouring myself a cup of cold brew, ready to start the day with an interview.
Notion is still in growth mode, which makes interviewing a notable chunk of almost everyone’s job. Luckily, a Notion database makes tracking and organizing the interviews easier — I can create pages and then organize them by building different views on top of the data (just like a real computer database).
I prep by creating a page from my database, where I have templates for different types of interviews. I add reminders to go deep on our company values and note key signals to look for in my technical interview. I add the candidate’s name, the link to the CodeSignal platform, and the post-interview scorecard.
Over the next hour I work through a problem with an eager candidate and envision what it would be like to work with them. Notion is still small enough that I get to work with most of the NYC engineers, which makes our interviews extra exciting and personal.
After filling out the interview scorecard, I take a look at my personal planning page — my home base within Notion — to get a sense of what I need to work on. On the Enterprise Engineering team we face the unique challenge of not trying to build for the everyday Notion user. Instead we typically build for owners of Notion enterprise workspaces, which is more difficult to test as we don’t have those higher admin permissions in the internal Notion workspace. To remedy this the team aggressively adds more integration and unit tests. Unfortunately simple changes such as re-ordering and parallelizing integration tests have caused our testing frameworks and build systems to fail — another reminder of how quickly Notion’s once-small developer infrastructure has needed to grow over the last year.
I settle on my first task: implementing changes from my teammate’s review of my pull request (PR) for a new feature. My teammate approved the PR but left some insightful comments about reusing some functions that are already present in the codebase. My team aims to unblock engineers whenever possible, and we mark the PR with a “Approve, but with comments” status, which allows me to get code in without having to chase down someone for each typo I make. I push the changes and wait for the build system to finish.
As part of the PR description, I added a link to the Notion Task (a page within the Notion Tasks Database) associated with the work. At Notion we track company-wide information by using shared database types like Tasks, Docs, Meeting Notes, and Projects. After the PR merges, a custom Notion Bot that our developer infrastructure maintains uses the Public Notion API to comment on the task and update the Status property to Completed. My personal planning database view filters out Completed tasks, so this linked task automatically disappears from the view. This helps me seamlessly make progress on the next open tasks of my projects. Within an hour or so, I check our internal version of Notion and can see and use the feature I just added. I’m excited to show folks in our cross-functional sync meeting later today!
Lunchtime at the NYC office means time for hanging out with coworkers, reading feedback from Notion users about the new comment reactions feature or the new Status property type in our databases, or answering a Notino’s questions about peak New England foliage trips. Lunchtime chatter is always a highlight of my day.
After lunch I catch up on Slack messages and Notion notifications, making note of any new inbound tasks or requests, before my afternoon meeting. My team has a biweekly cross-functional sync with Marketing and Customer Success managers, which allows us to organize beta testing of new features and customer calls and deliver well-coordinated feature launches that meet our customers’ needs. We value going the extra mile for customers, and these meetings move us in that direction.
I prepare for the afternoon meeting by first checking for recurring meetings on our Notion-wide Meeting Notes database which anyone at the company can use to create and categorize a new document for an upcoming meeting. I link to a draft of the Help Center documentation changes to get the Marketing team’s eyes on it. Working closely with our Marketing team has taught me how important it is to introduce new features in a way people can use right off the bat. During the meeting, my manager demos the new tool I merged in this morning. Folks are really excited about the feature and provide loads of helpful feedback.