hardNewMetaGoogleMicrosoft

What actually changes between senior and staff engineer in infrastructure?

Not depth, which is where most people push and where the returns flatten. What changes is the size of the problem you are handed, how ambiguous it is when you get it, and whether things happen because you asked rather than because you built them.

Updated Sep 2026 · Grounded in real AI infrastructure interview loops and written to a senior-engineer editorial bar, with every number worked and every diagram hand-built.

20 answers per topic instead of 10, plus saved progress and bookmarks · no cardor unlock all 283 remaining answers · ₹2,000 / $25

The concepts behind this question

Ranked by how closely each one overlaps this question's topic, so the first card is the thing to read if the answer above moved too fast.

Advanced

🧭 Ownership & Judgment🔒 Premium

Leveling Signals: Senior vs StaffThe same loop decides two things: whether you are hired and at what level, and the second is decided by a small set of signals interviewers are trained to listen for. Senior is scope you own and execute; staff is scope you define, across teams, under ambiguity, with the organization's defaults changed behind you. The signals are audible in every round: how you frame a design prompt, which failure modes you name unprompted, whose problem an incident was, what changed after it, and what you chose not to do. This page lists the signals per round, the stories each level needs, and the down-leveling traps.

Foundational

🧭 Ownership & Judgment

Escalation That WorksEscalation has a reputation as a political act because most of it is done badly: a problem handed upward with no options and an implicit request that someone else choose a side. Done well it is a one-page artifact with two or three costed options, a recommendation, the decision needed, a date, and what you will do by default if no answer arrives. That last line is what converts a message into a decision, and it is the part almost everyone omits.

Advanced

🧭 Ownership & Judgment🔒 Premium

Working with ResearchersInfrastructure engineers at AI labs and platform teams have an unusual customer: a researcher whose experiment is the company's product, who needs the cluster today, and whose request may be a bad idea for the fleet. The behavioral round tests whether you can serve that customer without being run by them: saying no with data, saying yes with conditions, finding the need behind the ask, and sharing ownership of outcomes neither side controls alone. This page gives the recurring situations at the boundary, the responses that work in each, worked narratives, and the answers that sound collaborative and fail.

Foundational

🧭 Ownership & Judgment

Talking About Cost and Capacity with LeadershipInfrastructure engineers are asked to justify large numbers to people who do not share their vocabulary, and the conversations go wrong in predictable ways: a technical objection with no alternative, a forecast with no assumptions, or a cost quoted in a unit the listener cannot act on. What works is a small number of costed options, a stated recommendation, the decision needed by a date, and every figure expressed in whatever the listener actually controls.

Explore the full curriculum →

UP NEXT ON YOUR JOURNEY

Next in this trackWhy would you leave a hyperscaler for a GPU cloud, or a GPU cloud for a hyperscaler?Next in this trackDescribe something you built that made researchers meaningfully more productive.Next in this trackWhat would you build in your first 90 days on this team?

FEDITOR'S NOTE

Scored on scope and ambiguity rather than technical depth, on influence without authority described concretely, and on the examples that demonstrate each rather than assert it.

DISCUSSION · 0

No comments yet — be the first to share your approach.