Working at Warp
Warp is a blazingly fast, Rust-based terminal reimagined from the ground up to work like a modern app.
How engineering works at Warp
How are the teams structured?
We are a remote-first company, which means that we hire anyplace (in the US for now) and do not have any expectation that employees will regularly come to an office. We do however have an “opt-in” office in the Soho neighborhood of NYC.
For now we don’t have any standing “tech leads” who “own” different parts of the code. Instead, when there is a significant project to be done that requires more than one engineer, we generally ask one engineer to be the “lead” for that project pod.
The lead should be the “driver” on a project rather than a gatekeeper - the lead needs to keep the project moving forward, should be responsible for communication about its progress, timeline, goals, etc. The lead should coordinate the work associated with the project - creating the tasks, driving the design, talking to users. The lead is responsible for the overall quality and timeline of the outcome - ultimately for any project what matters is (a) how well does it work and (b) how long did it take and (c) was it built well so that we can continue building on it.
Right now for instance we have about 5 pods going, focusing on different features and infrastructure areas – everything from single-user improvements to Teams and cloud infrastructure. We have a public Notion doc that describes our structure in more detail.
What tools do engineers use?
- Design: Figma
- Builds/CI: GitHub Actions
- Source control: GitHub
- Issue tracking: GitHub issues for external tracking and bug reports. Linear for internal issue tracking.
- Error reporting: Sentry
- Monitoring/logs: Sentry, Amplitude
- Chat: Slack
- Wiki: Notion
Can developers pick their own tools?
Yup, except everyone uses Warp as their terminal, since that's our product :)
How does the development process work? What's the process for working through bugs, features and tech debt?
Every quarter we develop a set of OKRs that are the high-level goals we want to achieve as a company and an engineering team.
OKRs are typically focused on moving user metrics like retention, growth, NPS, etc.
We have product pods that form to tackle the product initiatives that we think are most likely to help us achieve the OKRs.
On a weekly basis, each of these pods prioritizes what it wants to get done and creates a set of tasks in Linear, our task tracking tool.
In addition to feature pods, we also have a separate “Product Quality” rotation, where 1-2 engineers every week focus solely on moving through our backlog of user issues. Besides this rotation, engineers generally are responsible for fixing bugs related to any features they are working on. And we have a culture that encourages engineers to fix any bugs they find, no matter who wrote the original code.
We don’t have a dedicated track towards fixing “tech debt” as I think that’s an anti-pattern. Any tech-debt change or refactor or code improvement needs to come with a user-facing improvement, which is in line with our general orientation of building code to fix user needs, not building beautiful code for its own sake.
How does code get reviewed, merged, and deployed?
Our development process is based around using local branches, making small incremental changes, pushing them to GitHub and picking a code reviewer. We take code review very seriously – it’s one of the main tools we have for ensuring code and product quality.
Please refer to How We Code at Warp for a very detailed description of our coding processes.
What is the QA process?
QA starts with automated tests that accompany PRs. Generally we have three types of tests: unit tests, functional tests, and integration tests. Engineers are encouraged to write whatever makes the most sense for verifying their change – we favor pragmatism here above all else.
On top of automated tests, engineers are expected to manually test their own features and bug fixes – there is no external manual QA team.
In addition to testing and manual QA, our releases go through various stages of canarying and dogfood – we have a nightly build that the whole team uses, and then a canary build for external testers. We do one production push a week.
Moreover, features are typically developed behind flags so that we can enable them once they are ready.
What are some recent examples of interesting development challenges solved by internal teams as part of building the product?
We have a ton of great deep-dives written by our engineers that explore a number of interesting technical challenges that our team works through while building Warp. Check them out on Warp’s Engineering Blog!
How does on-call work?
We have a weekly rotation, but engineers are not on 24/7 oncall because our app is primarily client side right now. That will likely change as we add more server features.
Hiring process at Warp
How does the application process work? What are the stages and what is the timeline?
- An initial phone call where we go over the basics of our product, company, roadmap and culture. We also want to learn about you, your interests and career goals, and see if there’s a good match with what we are looking for in an engineer.
- A second phone call with an engineer on the Warp team to discuss what it’s like working at Warp, and to answer any further questions that might determine whether to start the formal interview process.
- A 2-hour technical session. This has 3 sections - coding, algorithms and runtime analysis, system design. The primary goal of the session is for us to get a sense of your level as an engineer and make sure that you’d be able to succeed technically at Warp. The questions do not test for knowledge of any particular language or stack, and are intended to assess general programming and problem solving ability.
- A 1-hour product session. This happens on a separate day from the technical session. The goal of the product session is to see how you think about product issues in general, the terminal in particular, and to see how you gel working with us as a team. There are no right or wrong answers in this session, and it’s meant to simulate us really working together. It’s meant to be pretty low stress and even fun.
- A decision on an offer, followed by a call with Zach (Warp’s founder and CEO) about offer details. All of our offers give candidates a sliding scale of equity and cash to choose from, and come with a model for understanding what the equity is worth in different scenarios. We think this is important, as startup equity can be difficult to value.
- A couple reference checks.
- An optional conversation with one of our investors about why they invested in Warp and how they see the opportunity.
A more detailed breakdown of the process is available in the Warp Notion doc.
What is the career progression framework? How are promotions and performance reviews managed?
We do not yet have a formal promotion process and ladder and at the moment are a very flat, non-hierarchical company. Most engineers report to an engineering manager or directly to the CEO (who is an engineer and manager himself). Managers focus on giving constructive feedback about how to grow technically, culturally, and in user-orientation that is driven by the Warp Growth Rubric.
We plan on adding a ladder once the company has around 20 engineers. We will do this while trying not to create a promo-oriented culture.
See more in the Warp Notion doc.
Console is the place developers go to find the best tools. Each week, our weekly newsletter picks out the most interesting tools and new releases. We keep track of everything - dev tools, devops, cloud, and APIs - so you don't have to.