Software Engineering & Development

How to get hired as a staff software engineer in 2026-27

Updated 6 October 2026 · 44 min read · by SkillSculptor

The short answer

To get hired as a staff software engineer in 2026-27, prove scope beyond one team, influence over people who do not report to you, and technical bets you documented before you knew the outcome. Senior is judged on delivering hard work well; staff is judged on choosing which work the organisation does, getting several teams to agree, and owning a decision whose consequences arrive two years later. The loop is normally a recruiter screen, a hiring manager screen that is usually the real filter, one or two system design rounds at a wider altitude than senior, a coding or debugging round that staff candidates routinely underprepare, a 60-90 minute deep dive where an interviewer hunts for the edge of what you actually decided, and a cross-functional round, ending with a levelling committee that can offer you senior instead. Bring three sanitised artefacts you wrote (a design document, an architecture decision record, a migration plan), one of them a bet that went wrong and what you did when the evidence turned, because that artefact separates a staff hire from a strong senior one faster than anything else you can say.

What the role ownsTechnical direction and judgement at a scope wider than one team: picking which problem is worth solving, making the architecture and migration calls that several teams then live inside, and raising the ceiling of what engineers around you can do. The work is a mix of design documents, prototypes that settle an argument, code in the hard or risky places, reviews, incident involvement, and a lot of conversation with people who do not report to you. Staff engineers usually have no direct reports and no budget authority, and that is the constraint that defines the job: the output has to be achieved through evidence and persuasion.
Licence or certificationNone. No licence, registration or certification governs software engineering in the United States, and NCEES discontinued its Software Engineering PE exam in 2019 for lack of candidates. No certificate reads as staff-level evidence; at this level certifications are close to neutral on a resume and mildly negative if they crowd out the decisions you made. Two edges worth knowing: some state engineering boards assert authority over use of the word engineer in a job title, and how far that reaches has been litigated, while Canada separately regulates the P.Eng designation. Neither affects who gets hired to do this work.
Where staff sits on the ladderStaff is the first level above senior on most individual contributor ladders. Google calls it L6 and Meta calls it E6; Microsoft's Principal band covers roughly this scope and the one above it. Amazon has no staff level at all: its ladder runs SDE II, then SDE III which is the senior-equivalent level, then Principal Engineer, so staff-sized scope sits in the gap between them. Apple uses ICT numbers and no staff title. Above staff sit senior staff, principal and distinguished. None of this is portable: a staff title at a 40-person startup often maps to senior at a 5,000-person employer, and the reverse happens too. Before you apply or accept, ask for the written level rubric and read what it demands for scope and influence.
Education and time to get thereNo degree is required, though a CS or related degree is still a hard filter at some large employers for any level. A first staff offer usually comes somewhere around a decade into the industry, with several of those years at senior, but the clock is driven by the scope you were allowed to take rather than by years served. The accelerant is working somewhere with real problems and enough organisational slack to let you own one end to end; the brake is a team where every decision above your own service is made by someone else.
Typical hiring processRecruiter screen (20-30 min), hiring manager screen (45-60 min, often the real filter), then an onsite or virtual onsite of four to six rounds: one or two system or architecture design, one coding or debugging, a past-project deep dive of 60-90 minutes (sometimes a prepared presentation to a panel), a cross-functional round with a product manager or a partner team's engineering manager, and at some employers an executive or bar-raiser round. Three to eight weeks end to end, longer than a senior loop, with a levelling or hiring committee that decides title as well as yes or no, then team matching at larger employers.
PayDo not trust a band from any article, including this one. Staff pay is set by employer tier, internal level and equity shape far more than by years, and a large share of total compensation at this level is stock. Read the sources instead. BLS OES code 15-1252 (software developers) gives medians and the 75th and 90th percentile spread by metro, which is a floor rather than a staff number because it does not break out level. Department of Labor foreign labor certification disclosure data gives exact employer-filed base salaries by employer, job title and worksite, with the caveat that it is base only and therefore misses most of the package at this level. Posting ranges are mandatory in a growing list of states (Colorado, California, Washington, New York and Illinois among them, so check the current list). levels.fyi shows level-by-level shape, remembering it is self-reported and skews to high-paying employers.
The single thing that gets you downlevelledEvidence of excellent individual execution with no evidence of influence across a boundary. Candidates who describe hard systems they built alone, in detail, and cannot name a decision they changed in another team's plan, get offered senior. The fix is not louder language. It is bringing two or three specific episodes where you altered a direction you did not control, with the mechanism named: the prototype you built to end the argument, the document you circulated, the person you brought the data to, what the other side gave up.
Market shape in 2026Fewer open staff requisitions than mid-level ones, because most staff seats are filled by internal promotion, and the external openings concentrate where there is a specific unowned problem: a platform rewrite, a reliability or cost crisis, a regulated domain, or an AI product moving from prototype to production. That shape rewards targeting over volume. A staff search runs on warm paths, former colleagues and a short list of teams whose problem you can name, not on a hundred applications.

What staff actually means, and the four shapes of the job

Staff software engineer is not senior with more years. It is a different job description that happens to sit on the same ladder. A senior engineer is given a hard problem and is trusted to deliver it well, usually inside one team's boundary, on a horizon of weeks to a quarter. A staff engineer is given a messy situation and is expected to work out what the problem is, decide which version of it is worth solving, get people who do not report to them to agree, and then be accountable when the consequences arrive several quarters later. The unit of work shifts from a system to a decision.

The clearest way to understand the variants is Will Larson's four archetypes in Staff Engineer: Leadership Beyond the Management Track, which hiring managers themselves use as shorthand. The Tech Lead drives one team or a small group through a long piece of execution. The Architect owns direction in a critical area across many teams, often a data layer, a platform, or a client framework. The Solver is dropped onto whichever problem is currently on fire and expected to come out with it understood and contained. The Right Hand operates as an extension of an engineering leader, carrying their context and judgement into rooms the leader cannot attend. Tanya Reilly's The Staff Engineer's Path is the other book worth reading before a loop, especially the chapters on seeing the big picture and on making invisible work legible.

This matters for the search because the four shapes interview differently and fail differently. An Architect role will spend most of your loop on design and on how you handle disagreement across teams. A Solver role will push hard on debugging, on reading unfamiliar systems, and on how you behaved in an incident. A Tech Lead role will look a lot like a senior loop with one extra round on planning and dependencies. A Right Hand role is usually filled by referral and tests judgement and discretion more than depth.

Read the job description for which one it is, then ask the hiring manager directly: what is unowned right now that you need this person to own? The answer tells you which of your stories to lead with and whether the seat is real. If the hiring manager cannot name an unowned problem, the requisition is probably a senior role with a staff title attached for recruiting reasons, and you will arrive with no scope and spend a year trying to manufacture some.

One more honest framing. Staff is not automatically the next step after senior, and it is not a reward for tenure. Plenty of excellent engineers stay senior by choice because they prefer deep execution to influence work, and a strong senior at a high-paying employer can out-earn a staff engineer elsewhere. Chase it because the work appeals, not because the ladder points there.

The line between senior and staff, written the way a loop actually checks it

Every levelling rubric says roughly the same four things in different corporate vocabulary. Interviewers are trained to probe them, and knowing the shape lets you choose stories that hit all four rather than four stories that all hit the first one.

Scope is the first and the most mechanical. Senior scope is a system or a team. Staff scope is several teams, a technical domain, or a problem that crosses organisational lines. The test interviewers use is blast radius: if your decision had been wrong, who would have been affected and for how long? If the honest answer is one service and one sprint, that story cannot carry a staff loop no matter how technically hard it was.

Ambiguity is the second. Senior work starts from a defined problem. Staff work starts from a symptom, a disagreement or a strategy document, and the first contribution is converting it into a problem statement people accept. The question that tests this is some version of "how did you know that was the right thing to work on?" A strong answer describes the evidence you gathered, the options you rejected, and who you got to agree that this was the problem, before any solution appears.

Influence without authority is the third and the one most candidates underprepare. You cannot direct another team, so the mechanisms are evidence, writing, prototypes, incremental proof and trading. Interviewers want the mechanism, not the outcome. "I convinced the platform team to adopt it" scores low. "They did not believe the migration was safe, so I ran it on our two lowest-traffic services first, published the latency numbers and the one regression we hit, then offered to own the rollback path for their first service, and they agreed to a pilot" scores high, because it is repeatable.

Multiplier effect is the fourth. Did the engineers around you get better or faster because of something you built, wrote or taught? Concrete forms count: a test harness that cut a review cycle, a design review practice that caught problems before they shipped, a document that stopped a recurring argument, two engineers you mentored who were later promoted. Vague mentoring claims do not count, and the resume line "mentored junior engineers" is close to invisible at this level.

There is also a fifth thing nobody writes in a rubric but most loops measure anyway: do you know when not to act? Staff engineers hold veto-shaped power without the title, and an interviewer is quietly checking whether you spend it well. A story about a rewrite you argued against, or a standard you chose not to enforce because the cost was higher than the benefit, often lands better than another story about something you built.

Documented technical bets: the artefact that separates staff from senior

A technical bet is a decision made under uncertainty, with consequences that arrive later than the decision. Choosing Postgres over a document store for a new domain. Splitting a monolith by capability rather than by table. Buying a vendor instead of building. Keeping the old system running in parallel for two quarters instead of cutting over. Betting that a queue would absorb a traffic shape you had not yet seen. The staff-level claim is not that your bets paid off. It is that you made them deliberately, wrote down the reasoning before the outcome was known, said what would make you reverse, and then checked.

This is the highest-leverage preparation for a staff search and almost nobody does it. Before you apply, assemble three artefacts you personally wrote, sanitised of employer confidential detail, that you can talk through for fifteen minutes each. A design document or RFC for something that shipped. An architecture decision record in Michael Nygard's lightweight format (context, decision, status, consequences), or something close to it. A migration or deprecation plan with its phases and its abort criteria. If your employer kept these in a tool you no longer have access to, rewrite them from memory now, while the detail is still there, and mark clearly that it is a reconstruction.

One of the three must be a bet that went wrong or that you reversed. This is not a humility exercise. It is the most discriminating evidence in the loop, because a senior engineer can usually narrate a success, while only someone who has actually held direction can narrate the moment the evidence turned, what it cost to change course, who they had to tell, and what they changed about how they decide. Interviewers at this level ask for it directly, and a candidate with no such story reads either as inexperienced or as unreflective.

Write each one so it carries six things. The decision in one sentence. The constraints that were real at the time, including the ones that were organisational rather than technical. The options you seriously considered and why each was plausible. What you gave up by choosing, because a staff answer always names a cost. The signal that would make you reverse, stated in advance, with a number or an event attached. What actually happened, measured.

A note on confidentiality, because this comes up. You can describe architecture, trade-offs and your own reasoning without disclosing proprietary detail, and interviewers expect you to manage that line. Replace customer names with shapes ("our largest tenant, roughly two fifths of write volume"), round figures, drop internal service names, and say out loud at the start that you are generalising. Refusing to discuss any of your past work is read as a failure of judgement, not as integrity. Posting a real internal design document publicly is the opposite failure.

Two anti-patterns to avoid. The first is the bet with no alternative: a document that argues for the thing you had already chosen reads as a rationalisation, and interviewers probe it by asking what the second-best option was. If you do not have a real answer, do not use that example. The second is the bet with no horizon: if you cannot say when you expected to know whether it worked, it was a preference rather than a bet.

The resume: writing scope and influence without inflating it

A staff resume is skimmed by a recruiter in well under a minute, then read by a hiring manager looking for one thing: evidence that this person has operated above a single team. Most staff resumes fail because they are senior resumes with more entries. Longer technology lists, more projects, bigger adjectives, same altitude.

The structural fix is to make every role entry answer three questions in its first two lines: what was the scope you were accountable for, what decision did you own, and what changed as a result. Keep the implementation detail, but subordinate it. A hiring manager does not need to know you used gRPC; they need to know you decided the service boundary and three teams built against it.

Lead with a four-line summary that states level, domain and the shape of your scope in concrete terms, not in adjectives. Compare "Experienced staff-level engineer passionate about scalable systems and mentoring" with "Staff engineer, backend and data platform. Owned the write path for a multi-tenant system serving about 9,000 business customers across four product teams. Led the Postgres partitioning migration that removed the scaling ceiling the roadmap was planned around, and wrote the service boundary standard three teams now build against." The second tells a hiring manager which seat you fit.

Numbers matter but only the ones that describe your consequence. Teams affected, services or repositories in scope, traffic or data volume, cost before and after, incident rate before and after, how long a migration took and how many teams had to move. Avoid numbers that describe the company rather than you, and never invent one. If you cannot support a figure, describe the shape: "the busiest table in the main database" is credible, a precise invented percentage is not, and an interviewer who asks where the number came from will find out in one question.

Include an artefacts line. A short list of things you wrote, with titles and one-line summaries, is unusual enough on a resume to get read: a design document, an RFC adopted across the organisation, an internal standard, a postmortem that changed a practice, a talk, an open source contribution with a review thread attached. If any version is publicly shareable, link it. This is the cheapest way to signal the documented-bets habit before anyone has interviewed you.

What gets ignored or actively hurts: a long technology inventory with no indication of depth, "mentored junior engineers" with no outcome, "led" with no stated blast radius, certifications, agile ceremony vocabulary, and anything suggesting you are chiefly a code producer. Three pages is fine at this level if the third page is substance; eleven bullets per role with no hierarchy is not.

On applicant tracking systems: they still filter, so your resume needs the literal nouns from the posting (the languages, the cloud, the datastores, the domain words) somewhere in plain text. But at staff level the actual filter is a human skim, so put the keywords inside sentences that also carry a decision rather than in a wall of comma-separated tokens.

How the loop runs in 2026-27, round by round, and who decides

A staff loop is longer than a senior loop, has more non-engineers in it, and ends with a committee deciding level as well as outcome. Knowing what each round is for changes how you answer it.

The recruiter screen is a level and compensation calibration more than a technical one. Use it to extract three things in writing: whether the requisition is for staff or for a range that includes senior, the written level rubric or its summary, and whether AI assistants are permitted in technical rounds. Employers split three ways on that last point (required, permitted with disclosure, forbidden), the rules sometimes differ between rounds at the same employer, and guessing is a self-inflicted failure.

The hiring manager screen is the real filter and it is usually where staff candidates are lost. It is a conversation about scope: what you owned, how you decided, what you disagreed with and how it resolved. Prepare for it like a final round, not a warm-up, and come with one question that only someone who has read the team's problem would ask.

The coding round still exists, and staff candidates underprepare it because they prepared architecture and not implementation. The content is usually less algorithmic than a mid-level screen and more often debugging, extending an unfamiliar codebase, or reviewing a change, but it is still timed and it still requires fluency. The failure mode is specific and avoidable: being slow and defensive in an editor after years spent mostly reviewing other people's work. Do not skip practice on the grounds of seniority.

Design is where your technical altitude is set. Expect one round, often two, and expect the brief to be deliberately underspecified. The staff signal is that you spend the first ten minutes on requirements, constraints, traffic shape, failure tolerance and cost, name the trade-off you are making before you draw, then sketch something you can defend and evolve. Jumping straight to boxes is a senior answer, and interviewers will let you do it for forty minutes and then score you accordingly.

The past-project deep dive is the round built specifically for this level, and it is where ownership is established rather than altitude. Sixty to ninety minutes on one project of your choosing, with an interviewer whose job is to keep asking why until they find the edge of what you actually decided. Some employers replace or precede it with a prepared presentation to a panel, usually thirty to forty-five minutes with questions. If you get the presentation format, ask whether the audience will be mixed in seniority and domain, and build it so a non-expert can follow the stakes while an expert can interrogate the mechanism.

Then there is a cross-functional round, usually a product manager, a partner team's engineering manager, or occasionally a designer or data scientist. It tests whether you can be disagreed with, whether you can explain a technical cost in terms of product consequence, and whether you push back on scope in a way people can work with. Candidates who are strongest in the design round sometimes fail here by treating the partner as an obstacle.

Finally the committee. At larger employers your packet goes to a hiring or levelling committee that never met you, which is why the written feedback matters and why your stories need to be legible to someone reading a summary. The committee can and often does come back with an offer one level down. Separately, some employers run team matching after the loop, where the scope on offer is finally specific. Treat that conversation as part of the negotiation, not as paperwork.

The two rounds that decide it: staff-altitude design and the deep dive

If you prepare two things properly, prepare these. They carry most of the level signal, and the behaviours that pass them are learnable.

Staff-altitude system design differs from senior design in four observable ways. You establish requirements and non-requirements before designing, including what you are explicitly choosing not to support. You state the constraint that dominates the design (a latency budget, a consistency requirement, a cost per request, a compliance boundary, a migration that cannot have downtime) and let it drive your choices visibly. You cost your design, in money and in operational burden and in how many teams have to change, not only in latency. And you talk about the second order: how it gets rolled out, how it fails, how it is observed, how the next engineer extends it, and how it gets deleted.

Expect briefs shaped like real organisational problems rather than product clones. Design the rate limiter that four hundred internal services share, with per-tenant fairness. We have one Postgres instance with four hundred tables and three teams blocked on each other every week; give us a decoupling plan for the next eighteen months. We are two years into a migration that is half done and the team that owned it has been reorganised; what do you do on Monday. Here is a design another engineer wrote; review it. That last format, the architecture review, has become more common, and it suits you: say what you would approve, what you would block, what you would need evidence for, and in what order you would ask.

The deep dive rewards structure. Open with ninety seconds of context, then the problem, then the decision, then the consequence, and let the interviewer pull on whatever they want. Keep the altitude high and drop down on request; the most common failure is thirty minutes of implementation detail that proves you can build but not that you can choose. Have the architecture sketchable on a whiteboard from memory, including the parts you are not proud of.

Prepare for the three questions that always come. What would you do differently? The answer must name a specific decision, not a platitude about communicating earlier, and must say what evidence you lacked at the time and how you would get it sooner. What was the hardest disagreement? The answer must include a person, their actual objection stated fairly, and the mechanism that resolved it, including the case where they were right. What did it cost? Every real decision has a cost, and a candidate who presents a project with no downside reads as either junior or unreliable.

One tactical point on the presentation format, if your loop uses it. Build it as five parts: the situation and the stakes in business terms, the constraint that dominated everything, the options and why you chose, what actually happened with numbers, and what you would change. Put your own decisions in the first person and the team's work in the plural, honestly, because a panel can usually tell and will ask. Leave a third of the time for questions and do not read slides.

Internal promotion versus changing jobs, honestly compared

Most staff seats are filled by internal promotion rather than external hire, and that fact should shape your plan. Promotion is usually the shorter path if you are already somewhere with scope available, because the hardest part of an external staff hire is proving influence to strangers, and internally everyone already saw it. The cost is that promotion is gated on your organisation's calendar, your manager's political capital, and whether a staff-sized problem happens to be unowned near you.

If you are going for promotion, the mechanism is a packet. Most large employers want written evidence mapped to the rubric: the projects, the scope, the documents you wrote, and peer feedback from outside your team. Start it a full cycle early, keep a running file of artefacts and quotes as they happen rather than reconstructing at the deadline, and ask your manager to show you a successful packet from a previous cycle. Then ask the question that actually matters: which rubric line am I weakest on, and what piece of work would close it? If your manager cannot answer, that is information about your odds.

Watch for the glue work trap, which Tanya Reilly named in her talk Being Glue. The work that holds a team together, unblocking people, writing the doc nobody wanted to write, chasing the dependency, is genuinely valuable and often invisible at promotion time. The answer is not to stop doing it. It is to make it legible: give it a name, attach it to an outcome, and make sure it appears in writing somewhere other than your own memory.

Going outside has one structural advantage and one structural risk. The advantage is price: a level change plus an employer change is where large compensation jumps happen, and some organisations simply have no staff seat available at any speed. The risk is downlevelling. External candidates are levelled on what they can prove in six hours to people with no context, so a strong senior-shaped loop performance lands a senior offer even when your current title is staff.

Reduce that risk with three moves. Ask for the level rubric before the loop and map two stories to each line. Ask the recruiter explicitly, early, whether the role can be filled at senior, and if yes, treat every round as a levelling exam. And bring the artefacts, because written evidence travels where reputation does not.

If an offer comes back at senior, do not reflexively decline and do not reflexively accept. Ask what specific signal was missing, since recruiters will often tell you, and ask whether a supplementary round or a written artefact can address it; this sometimes works and costs nothing to ask. Then evaluate the seat on scope rather than title: a senior title with real cross-team scope and a visible promotion path can beat a staff title with none, and a staff title at an employer with nothing above it can be a dead end. At this band the lever on compensation is the level and the placement within its range, not the base salary, so negotiating level is negotiating pay.

Running the search in 2026, and what to do if you are not there yet

Staff searches do not work like mid-level searches. The number of open requisitions is smaller, most are filled from inside, and the ones that reach the market exist because something specific is unowned. So the search is a targeting exercise. Pick fifteen to thirty employers whose problem you can name in one sentence, find the person who owns that problem, and get introduced. Former colleagues are the highest-yield channel at this level by a wide margin; a cold application into a staff requisition without a warm path is the low-probability route, not the default one.

Make the introduction easy to say yes to. The message that works is short and names the problem rather than asking for help: three sentences saying what you noticed about their system or their public engineering writing, the thing you have done that is the same shape, and a request for twenty minutes with the person who owns it rather than a request for a referral. Attach or link one artefact. The person forwarding you needs something they can paste, so write the two sentences they will paste.

Make yourself findable in the one way that works for this level: writing. A handful of public posts explaining a real decision you made, with the trade-offs intact, does more than a year of profile tending, because it is the same evidence the loop is looking for and it arrives before the interview. Conference or meetup talks work the same way. Neither has to be frequent. Two good artefacts beat twenty posts.

Give yourself a longer runway than a senior search. Three to eight weeks per loop, more rounds, committees that meet on a schedule, and team matching afterwards means a staff search commonly runs three to six months end to end even when it goes well. Run several processes in parallel so that no single committee decision is the whole outcome.

If you are senior and aiming at staff rather than searching today, the useful question is not what to learn but what to own. Find an unowned problem that crosses at least two teams and that someone with budget cares about, and take it: a migration nobody will start, a reliability or cost problem that keeps coming back, a platform seam that causes recurring arguments, a domain the company is about to need and nobody understands yet. Then do the thing that converts it into evidence: write the document, circulate it, name the alternatives, state what would make you reverse, and publish what happened.

Two adjacent paths are worth naming because they genuinely work. Contract or fractional staff-level work, where a company brings in a senior outsider specifically to make an architecture or migration call, produces exactly the scope stories a staff loop wants. And a deliberate sideways move into a smaller company at senior title, where the scope is immediately wider because there is nobody else, often reaches staff faster than waiting for a cycle at a large one, at the cost of a less portable title.

Last thing. The failure mode of a staff job search is not technical unpreparedness; it is telling senior stories in a staff loop. Spend your preparation time choosing and sharpening five episodes that each show scope, a decision under uncertainty, a mechanism of influence, and a measured consequence, with one of them a reversal. That is a weekend of work and it changes outcomes more than another month of practice problems.

Working with AI in this role

What a staff software engineer must know about AI in 2026-27

Start with the part that is easy to get wrong in both directions. AI has not changed what makes a staff engineer good. Distributed systems still fail the way they fail, data models still outlive the code that reads them, a bad service boundary still costs two years, and nobody has automated the judgement call about whether to finish a half-done migration or abandon it. A staff engineer who was strong in 2023 is still strong. What has changed, substantially, is the environment the role operates in, and at this level you are expected to have opinions about it that are specific enough to be wrong. Generic enthusiasm now reads as a weak answer rather than a strong one, for the same reason a generic design answer does: it shows no judgement about a specific system.

The first real change is the volume and provenance of change reaching production. Assistants and increasingly agentic tooling now write first drafts of application code, infrastructure definitions, CI configuration, tests and migrations at most employers. More change arrives faster, authored with less context about the surrounding system, and review capacity is the bottleneck rather than typing speed. That has made a set of staff-level responsibilities more valuable, not less: clear ownership boundaries, interfaces strict enough that a wrong change fails loudly, tests that assert behaviour rather than implementation, progressive delivery with automatic rollback, and a codebase legible enough that a newcomer or a machine can infer the convention instead of inventing one. If you tightened a release path, a type boundary or a review policy specifically because change volume and provenance shifted, that is one of the strongest current answers you can give.

The second is that staff engineers are now the people who make AI architecture bets, and these have a different risk shape from the bets you are used to. Model choice has a swap cost you should know before you sign: how much of your prompt, evaluation and tooling investment is provider-specific, and what it would take to move. Latency is two numbers users feel separately, time to first token and tokens per second after that, so a single p99 target is the wrong requirement. Cost is per request and varies with input length, which makes unit economics an engineering design constraint rather than a finance afterthought. Non-determinism breaks the testing assumptions in your pipeline. And correctness is not a status code: a model returns a well-formed answer that is wrong, so the familiar error-rate signal does not catch the failure that matters.

The third is evaluation, and it is the clearest competence gap in the market right now. The staff-level skill is being able to say what good looks like before building: an offline evaluation set with real failure cases, a small number of online guardrail metrics, a threshold that decides whether a change ships, and a rollback criterion written in advance. This is the same discipline as defining acceptance criteria and service objectives, applied to a system whose output is probabilistic. In interviews for anything AI-adjacent, the candidate who can design the evaluation tends to beat the candidate who can only describe the architecture.

The fourth is policy and the organisational surface, which lands on staff engineers because it is partly technical and partly judgement. Expect to be asked how you would set guidance for assistant use across a large engineering organisation: what may be pasted into a third-party service and what may not, how generated code is reviewed and attributed, how dependency and licence provenance is checked, how secrets and customer data are kept out of prompts, what gets logged for audit, and where a human must remain accountable for a decision. If you work in a regulated domain, know which obligations attach to your system and treat the dates as something to verify rather than recite. AI rules in several jurisdictions have been amended and deferred since they were first published, and quoting a deadline that has moved is worse in an interview than saying you would check the current text before relying on it.

Finally, the practical interview mechanics. Ask in writing whether an assistant is permitted in your technical rounds, because employers split three ways and the rules differ between rounds at the same employer. Where it is permitted, use it the way a staff engineer would: state your approach first, use the tool for mechanical work, and review its output out loud, because what is being scored is your judgement about the output and not the typing. A growing number of loops include a round that hands you a change you did not write, sometimes explicitly generated, and asks what is wrong with it. That round is a gift if you have spent the last two years reviewing seriously, and brutal if you have been approving quickly.

Making change safe at high volume and lower authoring context

More code reaches production faster, written with less understanding of the surrounding system, so the systems that catch a wrong change are now the constraint on delivery speed. This is squarely staff-level work and it is what hiring managers are actually buying.

Show it: Describe one specific thing you tightened and why: a type or schema boundary that turned a silent failure into a loud one, a test layer that caught a class of regression, canary analysis with automatic rollback, a CODEOWNERS and review policy change, or a convention made machine-checkable in CI. Attach a before and after number.

Designing an evaluation before building an AI feature

A model-backed feature can be fully available and completely wrong, so correctness needs its own definition. Teams routinely ship these with no agreed definition of good, and a staff engineer who supplies one is the person the project gets handed to.

Show it: Walk through an evaluation you built or would build: how you assembled the offline set from real failure cases, what you measured, the one or two online guardrail metrics, the threshold that gates a release, and the rollback criterion written in advance. Say what you deliberately did not measure.

Owning cost and latency as design constraints

Inference pricing moved cost from capacity planning into per-request economics, and token streaming splits latency into two numbers users feel differently. Budgets are now part of the architecture rather than something finance raises later.

Show it: Give a cost per request or per tenant for something you designed, with the lever you used to change it: prompt and context size, caching, model tiering, batching, admission control, or graceful degradation. Separate time to first token from tokens per second when you state a latency target.

Deciding build, buy or host, and knowing the swap cost

This is the most common AI architecture bet a staff engineer is asked to make, and it is usually made badly: by model benchmark rather than by what it costs to reverse. Vendor and model choices create lock-in through evaluation harnesses, prompts and tooling more than through the API call.

Show it: Lay out a real comparison with the dimensions that decide it: data boundary and residency, latency and capacity guarantees, cost at your volume, how much of your investment is provider-specific, and what a swap would actually take in engineering weeks. Name what you gave up.

Reviewing code and designs you did not write, rigorously

Review has become the scarce skill, and loops have adapted: a growing number include a round where you are handed a plausible-looking change or design and asked what is wrong with it. It is also most of the daily job at this level.

Show it: Have a review method you can state: what you check first, how you decide between blocking and commenting, what you ask for evidence on rather than arguing about, and an example of a problem you caught that looked correct. A public review thread on an open source project is unusually strong evidence here.

Making a codebase workable for both newcomers and agents

The properties that let an assistant contribute safely are the properties that let a new engineer contribute safely: one obvious way to do things, a fast and deterministic build and test loop, conventions written down, and failures that surface in CI rather than in production.

Show it: Describe something concrete you changed: contributor or convention documentation that is actually read, a test suite made fast and deterministic, lint or codegen that enforces a pattern, sandboxed execution for automated changes, or a CI gate that became the arbiter of a recurring argument. Cite the time or defect change.

Writing the organisation's guidance on assistant use

Staff engineers get handed this because it sits between legal, security and engineering practice, and because it requires someone who can be specific about what is and is not allowed without stopping work.

Show it: Be able to sketch a one-page policy: what data may leave the organisation, how generated code is reviewed and provenance checked, licence and dependency checks, secrets handling in prompts, what gets logged, and which decisions require a named human owner. Say which obligations in your domain you would verify against the current regulation rather than quoting a date.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

Mistakes that cost people this job

Submitting a senior resume with more years on it.

Rewrite every role entry so the first two lines state the scope you were accountable for, the decision you owned, and what changed. Push implementation detail below that. A hiring manager skimming for staff signal is looking for blast radius and decisions, and will not find them inside a list of technologies however impressive the list is.

Describing the size of a project instead of the content of your decision.

Separate the two explicitly. Say what the system was, then say the specific call you made, the alternatives you rejected, and what you traded away. "A platform serving millions of users" describes your employer. "I chose a per-tenant write path over a shared one, accepting four times the operational surface to get isolation the compliance review required" describes you.

Bringing only bets that worked.

Prepare one reversal in detail: the decision, the signal that changed your mind, what reversing cost in time and credibility, who you had to tell, and what you changed about how you decide. This is the most discriminating evidence in a staff loop. A candidate with no such story reads as either untested or unreflective, and interviewers will ask for it directly.

Treating the coding round as beneath the level and skipping practice.

Practise until you are fluent in an editor under time pressure, with emphasis on reading unfamiliar code, debugging and reviewing rather than algorithm puzzles. Years spent mostly reviewing other people's work makes you slow and defensive when you have to write, and the round is routinely underprepared by candidates who prepared architecture instead.

Answering a design round at senior altitude.

Spend the first ten minutes on requirements, non-requirements, traffic shape, failure tolerance and cost, and say out loud which constraint dominates. Then design against it, and cover rollout, failure modes, observability and eventual deletion. An interviewer will let you draw boxes for forty minutes without interrupting and then score the round as senior.

Claiming influence with no mechanism: "I convinced the other team."

Narrate the mechanism step by step, including their actual objection stated fairly. The prototype that settled it, the document you circulated, the pilot you offered to own, the data you brought, what they gave up and what you gave up. Interviewers at this level are listening for a repeatable method rather than an outcome.

Presenting your manager's or tech lead's scope as your own.

State your contribution precisely and let it be smaller. Experienced interviewers probe ownership with two follow-up questions, and an inflated claim that collapses costs you the entire round plus your credibility on everything else you said. A clearly owned narrow decision beats a vaguely owned broad one.

Not asking for the level rubric or whether the role can be filled at senior.

Ask the recruiter in the first call, in writing, and map two concrete stories to each rubric line before the loop. At this band candidates are downlevelled more often than they are rejected outright, and the decision is usually made by a committee reading written feedback from interviewers who did not know what to probe for.

Chasing the title rather than the scope.

Ask the hiring manager what is unowned today that this person owns by day 90. If there is no answer, the staff title comes with senior scope and you will spend a year manufacturing some. Also check what sits above the title: a staff seat at an employer with nothing above it is a ceiling, and a senior seat with real cross-team scope can be the better move.

Having no shareable artefacts because everything lived in an internal tool you no longer have access to.

Reconstruct two or three now, sanitised: a design document, an architecture decision record, a migration plan. Replace customer names with shapes, round the numbers, drop internal service names, and label it a reconstruction. Refusing to discuss any past work at all reads as poor judgement rather than integrity.

Talking about AI in generalities, or dismissing it entirely.

Pick two specific things and be concrete: one change you made because change volume and provenance shifted (a type boundary, a test layer, a rollback path, a review policy), and one AI architecture bet with its real dimensions (data boundary, cost per request, latency split between first token and the rest, evaluation design, swap cost). Both the enthusiastic generality and the flat dismissal score badly, for the same reason: neither shows judgement.

Running a volume application campaign.

Target fifteen to thirty employers whose unowned problem you can name in one sentence, and reach the person who owns it through someone you have worked with. Most staff seats are filled internally, so the ones that reach the market are specific, and the warm path is the main channel rather than a shortcut. Budget three to six months and run loops in parallel.

Questions people ask

What is the difference between a senior and a staff software engineer?

A senior software engineer is given a hard problem inside roughly one team's boundary and is trusted to deliver it well. A staff software engineer is given a messy situation, works out which version of the problem is worth solving, gets people who do not report to them to agree, and is accountable for a decision whose consequences arrive several quarters later. Four differences show up in every levelling rubric: scope measured by blast radius across teams and months, comfort with ambiguity about what the problem even is, influence exercised without authority through evidence and writing rather than direction, and a multiplier effect on the engineers nearby. The honest shorthand is that senior is judged on execution and staff is judged on choosing.

How many years does it take to become a staff software engineer, and do I need a degree?

A first staff software engineer offer usually arrives somewhere around a decade into the industry, with several of those years spent at senior, but the clock is driven by the scope you were allowed to own rather than by years served. No degree or certification is required: there is no licence for this work in the United States, NCEES discontinued its Software Engineering PE exam in 2019, and no certificate reads as staff-level evidence, although a CS degree is still a hard filter at a few large employers for any level. An engineer at a company with hard unowned problems and some organisational slack reaches staff faster than an engineer on a team where every decision above their own service belongs to someone else. If you want to compress it, the lever is not more study: it is taking one problem that crosses two teams and that someone with budget cares about, and converting it into written, measured evidence.

Do staff software engineers still write code?

Yes, staff software engineers still write code, typically less of it than a senior engineer but in the places that matter most: the prototype that settles an architectural argument, the hard core of a migration, the library three teams will build against, the instrumentation that proves where the time goes. The proportion varies with the shape of the role, from a tech lead who is hands-on most days to an architect who codes a few weeks a quarter. Interviews still test implementation fluency, and candidates who assumed the level excused them from a timed coding round are the ones most often caught out by it.

Is it easier to reach staff by internal promotion or by changing jobs?

For most people, internal promotion to staff software engineer is the shorter path, because the hardest part of an external hire is proving cross-team influence to strangers in six hours, and internally everyone already watched it happen. The cost is that promotion depends on your organisation's calendar, your manager's capital, and whether a staff-sized problem is unowned near you. Changing jobs is where the large compensation jumps occur and is sometimes the only option when no seat exists, but it carries real downlevelling risk: an external candidate who performs like a strong senior will be offered senior regardless of their current title. Running both in parallel is reasonable and common.

What does a staff software engineer interview loop look like?

A staff software engineer loop usually runs a recruiter screen, a hiring manager screen that is the real filter, then four to six rounds: one or two system or architecture design rounds with deliberately underspecified briefs, a coding or debugging round, a sixty to ninety minute deep dive on a past project (sometimes a prepared presentation to a panel), a cross-functional round with a product manager or partner engineering manager, and at some employers an executive or bar-raiser round. It takes three to eight weeks, longer than a senior loop, and ends with a levelling or hiring committee that decides title as well as yes or no, followed by team matching at larger employers. Ask the recruiter in writing for the round list and the AI-assistant policy, because employers split three ways on whether an assistant may be used.

What should a staff software engineer put on a resume?

A staff software engineer resume should lead with scope and decisions, not technologies. For each role, state what you were accountable for across how many teams, which calls you owned, what you traded away, and the measured consequence: cost before and after, incident rate, latency, how many teams had to migrate and how long it took. Add a short artefacts section listing documents you wrote that were adopted, standards, postmortems that changed a practice, talks, or open source review threads, because written evidence is the thing hiring managers at this level are hunting for. What gets ignored: technology inventories, certifications, agile vocabulary, and the line "mentored junior engineers" with no outcome attached.

Why do staff software engineer candidates get downlevelled to senior, and what can be done about it?

A staff software engineer candidate gets downlevelled almost always for the same reason: strong evidence of individual execution, no evidence of influence across a team boundary. Six hours is not long enough for an interview panel to infer scope you did not explicitly demonstrate, so the committee defaults to the level it can justify in writing. The countermeasures are concrete. Ask for the level rubric before the loop and map two stories to each line. Ask the recruiter directly whether the role can be filled at senior. Bring sanitised written artefacts, including one bet you reversed. And if the offer still comes back at senior, ask what signal was missing and whether a supplementary round or a written artefact can address it, which sometimes works.

How much do staff software engineers make, and where should I check?

Staff software engineer pay varies more by employer tier, internal level and equity shape than by experience, and a large share of total compensation at this band is stock, so any single number is misleading. Check the sources rather than an article. BLS OES code 15-1252 (software developers) gives medians and the 75th and 90th percentile spread by metro, which is a floor because it does not break out level. Department of Labor foreign labor certification disclosure data gives exact employer-filed base salaries by employer, title and worksite, but base only, so it misses most of the package. Posting ranges are mandatory in a growing list of states. levels.fyi shows level-by-level shape, treating it as self-reported and skewed toward high-paying employers. Because level sets the range, negotiating level is how you negotiate pay at this point.

Is staff engineer better than becoming an engineering manager?

Neither is senior to the other at most employers: staff software engineer and engineering manager are usually paired levels with similar compensation bands and different work. The staff software engineer path keeps technical judgement as the product and exchanges formal authority for influence, which means your leverage comes from evidence, writing and credibility. Management trades depth for responsibility over people, hiring and performance. The practical test is which problem you would rather spend a bad Tuesday on: an architecture that is wrong and expensive to change, or a team member who is struggling. Moves between the two tracks are common, and a stint in one makes you better at the other.

How has AI actually changed the staff software engineer job?

For a staff software engineer, AI has changed the environment more than the core skill. Distributed systems still fail the same way, data models still outlive their code, and nobody has automated the judgement about whether to finish or abandon a half-done migration. What changed is that more code reaches production faster with less authoring context, which makes review capacity the bottleneck and raises the value of ownership boundaries, strict interfaces, behaviour-level tests and automatic rollback. Staff software engineers are also now the people who make AI architecture bets (data boundary, cost per request, latency split between first token and the rest, evaluation design, swap cost if the model changes) and who often write the organisation's policy on assistant use. In interviews, generic AI enthusiasm scores badly and so does flat dismissal; two specific examples score well.

Put this on a resume in about a minute

Paste your history once and point it at the Staff Software Engineer posting you are looking at. No account, no card.

Build my resume free More roles

Related roles