Product Engineer levels | Handbook

This page defines the levels we hire Product Engineers at and what you have to be able to do to sit in each one. It's the criteria behind the salary bands published in the Product Engineer role, written out in full.

We publish it for a simple reason. A job ad with one wide range and no stated criteria isn't information, it's a guessing game, and every candidate rationally anchors at the top. If we don't write down what you need to have to sit at each point of the range, we can't complain that people place themselves at the top of it. With the levels written down, the conversation about money becomes a conversation about evidence.

This is about capability, not about years served. It's a map for locating yourself, not a promotion ladder.

How we place someone

We look at three things. They're separate on purpose, because most miscalibrated candidates are strong on one and empty on another.

How far up the value chain you can operate. Do you receive a solution, receive a problem, or find the problem? This runs from "you develop the ticket" at one end to "you decide which bets are worth making" at the other.
Systems and scale. What you've actually run in production, under real concurrent load and real data volume, and whether you know which system to reach for and why.
Autonomy and blast radius. How large a piece of work we can hand you with how little scaffolding, and how much damage the resulting mistake can do before somebody else notices.

The levels are not a hard line. Someone can hold Senior-level query optimization and Mid-Level product judgement. We place you where at least two of the three land, and the third moves you inside the band rather than across it.

Where you land inside a band depends on how many of the points below you can show evidence for. Nobody arrives with all of them, at any level. You may have run a service under real production traffic and never hit a serious data volume problem, or have spent two years on hundreds of millions of rows in a nightly pipeline nobody queried live. Both are worth a lot, and neither is the complete set. A gap moves you within the band, it doesn't drop you a level.

What does not determine your level

Each of these has come up in a real interview, so we state them explicitly.

Knowing a framework. "I'm senior because I know FastAPI" isn't an argument. Claude Code knows FastAPI better than any of us. Unless you wrote FastAPI, framework familiarity is table stakes. Same for React, Next.js, or our exact stack: we expect you to pick up whatever we use in weeks.
Years of experience on their own. Eight years of building CRUD screens behind a PM is not eight years of product engineering. Time only counts as evidence of what you were exposed to.
Your title at your last company. Titles inflate at different rates in different places.
The size of the team you led. We're not hiring managers. Leverage here comes from what you can ship and decide, not from headcount.

Junior

You can build well when the problem is framed for you, and you have the instincts that make the rest teachable.

We're not hiring Product Engineers at this level right now. The criteria are here because the level is real and we want it on the record, but the bandwidth to mentor properly is what decides whether we open it, and today we don't have it. If you're early in your career and drawn to the business and customer side of the work, our GTM Engineer role is where a junior can land here today.

We don't ask you for experience with production environments, high concurrency, or large data volumes. You'd get all of that here.

We do ask you for:

Curiosity and the will to do things properly. You want to understand why the code works, not only that it works. You look things up, and you come back with an opinion.
Respect for the practices, even before you've had to lean on them. Testing, observability, metrics, alerting: you know roughly what each is for and why a change that ships untested and unmonitored is a change nobody can trust. You don't need to have built the monitoring, you need to not be surprised that it's expected.
Basic complexity and cost intuition. You can tell constant from linear from quadratic, you know why a query without an index scans the whole table, and you can sense when a loop that's fine over 100 rows falls over at 10 million. You don't need to know where the cliff is exactly, you need to know there is one.
Tests for the changes you make. Every change that alters behavior carries a test that covers it. That's the floor, not an achievement.
Getting unblocked fast. You ask early, with context, instead of disappearing for two days.

How the work looks: well-defined tasks, with the problem and the acceptance criteria already framed. You deliver them end to end in code, tested, and you verify in production that they work, with someone reviewing your plan before you start.

Mid-Level

Hand you a problem and you own it end to end, from "should we even build this?" to "it's live and I've checked it's working".

We don't ask you for very high concurrent load, hundreds of millions of rows, or real-time pipelines. Plenty of good engineers have simply never worked somewhere with that shape of problem.

We ask you for everything in Junior, plus:

You own the task end to end. You can judge whether it makes sense to build something at all, not only how to implement it. A ticket is a hypothesis, not an order.
80/20 scoping, and knowing where to stop. You can tell us what the 2-day version that captures 80% of the value looks like, and argue for it over the 2-week one. You cut scope, not quality, and you say out loud which tradeoff you're making.
You deploy and you monitor. Before merging you decide what you'll look at one hour and one day after the deploy: which dashboard, which alert, which metric. If you break something you find out first, not support and not a customer.
Enough business context to prioritize. How the company makes money, who the paying customer is, what moving 1% is worth. Enough to say "this ticket serves 2% of revenue and that one serves 60%".
You can optimize a query. Read a plan, spot the missing index, understand why a join is expensive. This one is shared with Senior; the difference is the size of the system you can do it in.
You're a manager of one. You break down your own work, set your own deadlines, and drive it to done without being chased.

How the work looks: you get a problem and a metric, not a spec. You come back with a plan, ship it in slices, and tell us whether it worked.

Senior

Everything above, plus production scars we can't teach you here fast enough, and the product judgement to choose what's worth building.

Senior here isn't Mid-Level with more years. The bar is deliberately high and it's specific: these are the things we can't hand you on the job in a reasonable time, so we have to hire for them.

We ask you for everything in Mid-Level, plus:

Production at scale. You've owned a system serving something on the order of hundreds of requests per second, or a comparable sustained concurrent load, and you can tell us what broke first, how you found out, and what you did about it.
Large data volumes. You've worked with datasets in the hundreds of millions of rows and have the instinct that comes with it: what's cheap, what's catastrophic, when to precompute, when to denormalize, why the query that's fine on a 10M-row sample dies on the full table. Our jobs table is hundreds of millions of rows in ClickHouse, so this is our daily reality rather than a hypothetical.
Data that arrives continuously. You've dealt with data that never stops rather than a nightly batch, and you know what that changes: ordering, deduplication, backpressure, lag, and what "consistent" even means when the source never stops.
System selection. You know when a workload wants an analytical store and when it wants a transactional one, how the two are kept in sync, and what breaks at the seams. You can explain the tradeoff with its failure modes, not as a list of product names.
The product half of the job. You define the outcome and the metric before writing code, and the instrumentation ships in the same PR. You talk to real users yourself rather than outsourcing all contact with reality to sales or support. You come back to what you shipped 4 to 6 weeks later and read the churn surveys. You put two or three options on the table and compare them. You decide what not to build.
Domain depth. You speak the customer's language well enough that they think "this person understands my job".
You raise the bar around you. Code reviews that teach, docs and tooling that make everyone faster, standards that get adopted because they're good and not because you're senior.

How the work looks: you own an area, including the question of what the area should be doing.

Staff

Everything in Senior, plus the judgement about which problems deserve resources at all, and the conviction that you can take the company somewhere we hadn't planned for.

Senior is the top of "own your area extremely well". Staff is where the question changes from how well you execute on an area to which areas should exist. It overlaps with founder work, which is exactly why we don't publish a ceiling for it: tell us what you'd do with the company and the offer gets built around that.

We ask you for everything in Senior, plus:

You prioritize the bets, not the tickets. Which problems compete for resources, what goes in and what stays out. This needs the global context: what everyone else is working on, the strategy, the other open fronts.
Vision you can defend. Where the product should be in two years, stated as problems worth solving rather than a list of features.
You pick the battles. The scarcest resource in a team this size is attention, and the most expensive mistake available to us is a quarter spent building the wrong thing well.
Leadership without management. Engineers get better because you're here, decisions get made faster because you're in the room, and standards spread because you set them and they're good.
You want the company to end up somewhere bigger than our current plan, and you can say concretely how.

How the work looks: you're in the prioritization conversation, not downstream of it. You bring the bet, the evidence, and the reason it beats the alternatives.

How we use this

When you apply. You choose the level you're applying for, with these criteria in front of you, and the interview goes after the evidence rather than the label. We'd rather argue about what you've actually run than about what your last title was.

Once you're here. Levels are not re-litigated every few months. The performance review scores how you're doing at your level, and a level change is a separate, explicit conversation.

The bands for each level are published in the Product Engineer role.