Track F — Warmup: Staff-Altitude Behavioral, Worked

Self-contained. Every story category with a worked model answer, the probes that follow each, and the forward-looking answers written out in full.

The model answers use a fictional composite engineer whose background resembles yours — multilingual search and ranking, streaming, infrastructure. They are here to show you the shape and the density. Do not tell these stories. Tell yours, at this density.

Table of Contents

• Chapter 0: Why This Round Is Failed
• Chapter 1: DTAO
• Chapter 2: The Twelve Categories, With Worked Answers
  • F1. Architecture decision across teams
  • F2. A disagreement you lost
  • F3. A disagreement you won
  • F4. An outage you owned
  • F5. A project you killed
  • F6. Raising a team's bar
  • F7. A bet that failed
  • F8. Consensus without authority
  • F9. Deadline versus quality
  • F10. Changed your mind from data
  • F11. Working with non-engineers
  • F12. What you would build differently
• Chapter 3: The Probe Playbook
• Chapter 4: The Forward-Looking Answers
• Chapter 5: The Career Narrative
• Chapter 6: What Not To Do
• References

Chapter 0: Why This Round Is Failed

Three findings, and together they should change how much time you give this.

1. It is graded at Staff, not Senior. AI-lab levelling is compressed — reported consensus is that an OpenAI level maps roughly one level higher than the same number at Google or Meta, and that "L5 Senior" carries Staff-equivalent scope. So a story where you personally made a good call on your own service is a Senior story and will be scored as one.

2. Reported sources name the values/culture round as the leading failure point at a peer lab. For companies whose technical bars are this high, that is a remarkable claim. It means the round is not a formality, and it means the failure is not "seemed unfriendly" — it is "had no substantive position".

3. Senior engineers systematically under-prepare it, because it does not feel like real work. Preparing a design or a coding problem feels like engineering; writing down what you decided and why feels like paperwork. That asymmetry is exactly why the round discriminates.

The reliable test for whether a story is Staff-altitude: did anyone disagree? Consequential decisions attract disagreement. A story with no opposition is either not consequential, or you have edited the opposition out — and interviewers probe for precisely that.

Chapter 1: DTAO

Not STAR. STAR was designed for interviews that wanted to know whether you were a good teammate; it front-loads Situation — the least interesting part — and buries the decision three paragraphs in. By the time you reach it the interviewer has stopped listening.

Context goes in a clause, not a paragraph: "On the multilingual ranking pipeline, we decided X." That is enough. If the interviewer needs more they will ask — and them asking is a good sign, because it means they are engaged rather than waiting for you to finish.

The four sentences that make a story Staff-altitude, and most stories are missing at least two:

1. "The decision was ___." (first sentence, no preamble)
2. "I rejected ___ because ___." (with a number)
3. "___ disagreed, and their argument was ___." (stated fairly)
4. "I got ___ wrong." (specific, with a generalizable lesson)

Chapter 2: The Twelve Categories, With Worked Answers

Each has: the question as asked, what is being tested, a weak answer, a strong answer, and the probes.

F1. Architecture decision across teams

"Tell me about an architecture decision you made that affected teams beyond your own."

Tested: cross-team scope, quantified tradeoffs, how you got alignment. This is the core Staff signal and it is asked in some form in every loop.

Weak (no-hire at staff):

"We were having scaling problems with our search infrastructure, so I proposed moving to microservices. I worked with the team on the design and we migrated over six months. It was successful and latency improved a lot."

No decision — "microservices" is a category, not a choice. No alternatives. No constraint. No disagreement. No numbers. No mistake. This is a tour, and it takes twenty seconds to recognize as one.

Strong (strong hire at staff):

"I decided to move our multilingual ranking pipeline from per-language index shards to a single shared-embedding index with a language-conditioned reranker.

The constraint was the tail. We had 40-plus languages, and the bottom 25 were 15% of traffic and 60% of the relevance complaints — they simply didn't have enough labelled data to hold their own shard's quality.

Two alternatives. Keep per-language shards and backfill training data: we priced the annotation at about $400k and nine months, and it would decay as the corpus shifted, so we'd be paying it repeatedly. Or a single multilingual model with no reranker: our offline evals showed a 4-point nDCG drop on the top three languages, which were 70% of revenue traffic. I wasn't willing to pay for the tail with the head.

The search infra team pushed back hard, and they weren't wrong. The shared index roughly tripled memory per replica on our estimate, and they'd just finished a capacity plan they'd spent a quarter defending. What settled it was building it for six languages and measuring: memory came in at 2.2×, not 3×, and while profiling we found we could store the tail languages' vectors at int8 with no measurable nDCG change, which brought it to 1.6×. They co-authored the rollout plan after that.

Result: tail-language nDCG up 11 points, head languages flat within noise, memory up 60%, and we retired 40 index-build pipelines in favour of one.

What I got wrong: I badly under-scoped tokenization. I assumed a shared vocabulary was a solved problem, and it cost us six weeks on the two languages with the worst subword segmentation. The lesson I actually took is narrower than 'estimate better' — it's that when I'm making an architecture bet, I should prototype the part I'm least curious about, because that's the part I haven't thought hard about."

Why it works: decision in sentence one · constraint quantified · two alternatives with numeric rejection reasons · a named opponent whose objection is stated as legitimate · alignment achieved through measurement rather than authority · measured outcome including the cost · a specific self-critique with a lesson that generalizes.

Probes to expect:

• "What was the infra team's strongest argument?" (If you can't produce one, the story fails.)
• "What would have had to be true for the per-language option to win?"
• "Who else was affected that you didn't mention?"
• "How long did the disagreement take, out of the total?"
• "How do you know the 11 points weren't a coincidence?"

F2. A disagreement you lost

"Tell me about a technical disagreement where you did not get your way."

Tested: whether you can update, whether you distinguish being wrong from being outvoted, and whether you commit after losing. This is the highest-signal behavioral prompt in existence and the one candidates prepare least.

Four ways it fails:

Strong:

"I wanted to build our own vector index. The team wanted to buy a managed one.

My argument was that our access pattern was unusual — heavy filtered search, where most queries constrain to a small subset before the ANN lookup — and every managed product at the time did filtering as a post-filter, which meant either over-fetching by 10× or accepting recall loss. I'd prototyped a pre-filtered HNSW variant that held recall at 0.95 with a 20× tighter fetch.

Their argument, which I'll state properly because it's the one that won: we were four engineers, the index would become a permanent on-call surface, and my prototype's recall number came from a benchmark I'd built, on a filter distribution I'd chosen. They weren't disputing my number — they were disputing whether it would survive contact with production query distributions that neither of us had characterized yet. And they pointed out that if we were wrong about that after six months of building, we'd have burned half our capacity.

The tech lead decided to buy. I disagreed and committed — I wrote the evaluation harness for the managed option and I made it a genuinely fair test, including the filtered cases I thought would fail.

They were right, and not for the reason either of us argued. The managed option's recall on real traffic was 0.91, worse than my prototype — but the actual query distribution turned out to be far less filter-heavy than I'd assumed. My prototype was optimized for a workload we didn't have. I'd characterized the queries I found interesting rather than the queries users sent.

What I changed: I now refuse to defend a design on benchmark numbers until I've characterized the real input distribution. On the next project I spent the first week just analyzing traffic, and it killed two of my three design ideas before I wrote any code — which was the point."

Why it works: the disagreement mattered · his position is stated as strongly as he held it · their argument is stated well enough that they would recognize it · he committed after losing and demonstrably did not sandbag · the honest read is "they were right, and for a reason neither of us had" — which is more credible than either "they were right" or "I was right all along" · the lesson is specific and he can point at what he did differently.

Probes:

• "What was their strongest argument?" (He already gave it — which pre-empts the probe.)
• "Did you actually commit, or did you sandbag?" (The harness is the evidence.)
• "If you had the same argument today, what would you do differently?"
• "Was the process sound, even though you disagreed with the outcome?"

F3. A disagreement you won

"Tell me about a time you convinced people to go your way."

Tested: whether you persuade with evidence or with persistence. The failure mode is a story where you won because you were more stubborn.

Strong, compressed:

"I argued for killing our A/B framework's fixed 14-day test duration in favour of sequential testing with always-valid p-values.

The objection was legitimate: sequential methods are less familiar, and the data science team was worried people would peek and stop early, which is exactly the error fixed-horizon testing exists to prevent.

What convinced them wasn't argument. I re-ran our last 40 completed experiments through both methods offline. 31 of them would have reached the same conclusion in a median of 6 days instead of 14. Three would have concluded differently — and when we dug into those three, two were cases where the fixed-horizon result was a fluke that a longer run reversed. That third one is what actually won the argument, because it was evidence against my own position and I brought it anyway.

Outcome: median experiment duration went from 14 days to 7, so we roughly doubled experiment throughput on the same traffic. The guardrail they asked for — a hard minimum of 3 days regardless of significance, to avoid novelty effects — was a good idea and I hadn't thought of it."

Why it works: he won with replayed real data, not with argument; he volunteered the evidence against himself; and he credits the opposing side with improving the design. That last move is disproportionately effective and almost nobody makes it.

Probes:

• "What did the people who disagreed get right?"
• "Would you have gone ahead if the replay had shown 20 differences instead of 3?"
• "How did you handle the people who still disagreed after the data?"

F4. An outage you owned

"Tell me about an outage you were responsible for."

Tested: ownership without self-flagellation, blameless analysis, and whether the fix was systemic or a patch.

Strong, compressed:

"I took down multilingual search for 47 minutes with a config change.

I was rolling out a new tokenizer version. The config was per-language, and I'd written it as a map with a default fallback. The default was correct for 38 languages and wrong for two — the two with no whitespace segmentation — and for those, the tokenizer silently produced single-token documents. Every query for those languages returned nothing.

It got through canary because canary traffic was sampled uniformly, and those two languages were 0.3% of traffic, so the canary saw about 4 affected queries and the error-rate alarm didn't fire — the queries succeeded, they just returned nothing.

Detection was a customer report, which is the part I actually consider the failure. Rollback was 6 minutes once we understood it; the 41 minutes before that were diagnosis.

Three fixes, and only one of them is about the config. Immediate: the config now requires an explicit entry per language with no default, so a missing language fails the deploy instead of falling back. Systemic: we added a per-language zero-result-rate alarm, because 'requests succeed but return nothing' was a failure class we had no detector for at all. And the one I pushed hardest for: canary traffic is now stratified by language rather than sampled uniformly, so low-volume languages are represented. That third fix caught two unrelated bugs in the following year.

What I got wrong beyond the config: I'd reviewed that config myself and approved it. The lesson isn't 'review more carefully' — it's that a default value in a config that must be exhaustive is a design smell, and I now treat 'is a default correct here, or just convenient?' as a review question."

Why it works: owns it without theatre · the detection gap is named as the real failure · three fixes at three levels, with the systemic one emphasized · the alarm gap is a class of failure, not an instance · the lesson is a reusable review heuristic.

Probes:

• "Why didn't your monitoring catch it?" (Already answered — pre-empting probes is a strength.)
• "What did the postmortem process look like? Was it blameless in practice or only in name?"
• "Has that class of failure recurred?"
• "What would you have needed to catch it in canary?"

F5. A project you killed

"Tell me about something you decided to stop."

Tested: sunk-cost resistance. Rare, valuable, and hard to fake.

Strong, compressed:

"I killed a query-understanding service after five months and roughly two engineer-years.

The premise was that rewriting queries — expansion, spelling, intent classification — before retrieval would beat doing it inside the ranker. We'd built it, it worked, and it improved nDCG by 1.2 points offline.

What killed it was the online test: +0.3 points, inside the noise band, at a cost of 40 ms on the p99. Meanwhile, a two-week experiment someone else ran — adding the same signals as features to the ranker rather than as a rewriting stage — got +0.9 points for 4 ms.

The hard part wasn't the decision, it was that I'd argued for this architecture publicly for two quarters, and two engineers had spent five months on it. I wrote the recommendation to kill it myself, and I made sure the writeup said plainly that the original premise was mine and it was wrong.

We salvaged the spelling correction, which was genuinely good and shipped separately. The two engineers moved to the ranker work and one of them ended up owning it.

What I'd do differently: the online test should have come at week six, not week twenty. We had a shippable slice at week six and I chose to make it better first. The reason I chose that was that I was confident, and confidence is exactly when you should test earliest."

Why it works: a real cost is named · the alternative that beat it is credited to someone else · he wrote the kill recommendation himself and took the premise publicly · the salvage is mentioned without using it to soften the outcome · the lesson inverts the usual instinct.

Probes:

• "How did the two engineers take it?"
• "Who else had to agree?"
• "How do you decide when to kill something, in general?"

F6. Raising a team's bar

"Tell me about improving how a team works, not just what you personally shipped."

Tested: scope beyond your own output — the definition of Staff.

Strong, compressed:

"Our relevance experiments weren't reproducible. Someone would report +2 nDCG, and three weeks later nobody could reproduce it because the eval set had been regenerated, the feature pipeline had changed, or the baseline had moved.

I didn't start with a process proposal, because I'd have lost that argument. I started by trying to reproduce the last six reported wins. Two of the six reproduced. I wrote that up with the specific reason each of the other four failed.

That memo did the convincing. We then built three things: versioned, immutable eval sets; an experiment record that pins dataset version, code SHA and baseline; and a rule that a result isn't citable in a design doc unless it has a record ID.

The cost was real — an experiment went from about 20 minutes of setup to about 40, and people complained for a month. What ended the complaints was a case where the pinning caught a regression: someone's +3 was actually a baseline that had silently drifted, and the record made that visible in an afternoon instead of never.

A year later reproduction was routine, and it changed something I didn't anticipate — people started reporting negative results, because a negative result you can reproduce is worth writing down. That was the actual win."

Why it works: he measured the problem before proposing a solution, which is what made the argument unarguable · the cost is stated honestly, including the complaints · the second- order effect is the real outcome and he notices it.

Probes:

• "How did you get people to adopt something that made their work slower?"
• "What did you do about the people who never adopted it?"
• "Did it survive after you moved on?" (The strongest possible follow-up.)

F7. A bet that failed

"Tell me about a technical bet you made that didn't pay off."

Tested: calibrated risk-taking. The failure mode is a story where the bet failed for reasons outside your control — which is not a bet, it is bad luck.

Strong, compressed:

"I bet on approximate nearest neighbour with product quantization for our largest index, against the alternative of just buying more memory and staying exact.

The reasoning was defensible: PQ would cut the index to a quarter of the memory at a projected 0.98 recall, saving about $200k a year in instances, and I'd validated the recall on a 10% sample.

It failed for a reason I should have caught. Recall at 0.98 was fine on average and terrible on the tail of the query distribution — rare, specific queries, which are disproportionately the ones where users notice search failing. Average recall hid it completely, because rare queries are rare. We saw it as a rise in query reformulation rate, which nobody had thought to watch.

We reverted after three weeks. Cost: about six weeks of work and a measurable but small hit to the reformulation metric during those three weeks.

The generalizable thing isn't 'PQ is bad' — we later shipped it successfully on a different index where the query distribution was flatter. It's that I evaluated a distributional change with an average. Now, for anything that changes a distribution, I look at the tail explicitly and I pick the metric that would move first if it were going wrong."

Why it works: the reasoning at the time was sound, which is what makes it a bet rather than a mistake · the failure is attributed to his own analysis, not to circumstance · the technology is explicitly not blamed · the lesson is about method and he applied it later.

Probes:

• "Would you make the same bet again with the same information?"
• "What would have caught it earlier?"
• "How do you decide how big a bet to take?"

F8. Consensus without authority

"Tell me about getting people to do something when you couldn't tell them to."

Tested: influence mechanism. Weak answers say "I explained my reasoning" — which is not a mechanism.

Strong, compressed:

"I needed four teams to adopt a shared embedding service instead of each running their own model. I owned none of them.

Persuading four teams simultaneously doesn't work — you get four separate arguments and any one of them can stall it. So I did it sequentially and started with the team that had the most to gain and the least to lose: the smallest one, whose model was worst and who'd been asking for help. I did their migration for them rather than asking them to do it. Two weeks of my time.

That gave me a real number — their retrieval quality up 6 points, their inference cost down 70% — from a team with no stake in my argument. The second team was much easier because I was no longer making a projection.

The third team refused, and I want to be clear that they were right to. They had a domain-specific model genuinely better than the shared one on their vertical. What I did was make the shared service support bring-your-own-model so they could use the serving infrastructure without the shared weights. That got the infra consolidation, which was 80% of the value, without pretending their objection was invalid.

Fourth team followed once three of four were on it.

The mechanism, if I had to name it: make the first adopter's migration free, so the second conversation is about evidence rather than about projections. And take the real objection seriously enough to change the design, because the person who refuses is usually the person who understands their own constraints best."

Why it works: the mechanism is explicit and repeatable · he did the work rather than asking for it · the team that refused was accommodated by changing the design, which is a much stronger move than winning that argument · he articulates the general principle at the end.

Probes:

• "What if the first team's migration hadn't produced a good number?"
• "Was there anyone you couldn't win over? What did you do?"
• "How much of your own time did this cost, and was it worth it?"

F9. Deadline versus quality

"Tell me about shipping under a hard deadline when quality was at risk."

Tested: whether you make the tradeoff explicitly and with whom.

Strong, compressed:

"We had six weeks to ship multilingual autocomplete for a launch with a fixed external date. The honest estimate was ten.

I refused to frame it as 'cut quality'. I framed it as 'cut scope, publish the cut'. I wrote a one-page doc listing what shipped, what didn't, and — the part that mattered — what specifically would be worse for users as a result. Not 'reduced coverage' but 'the following 12 languages will fall back to prefix matching, which for the three non-whitespace-segmented ones means autocomplete will feel broken.'

Product read that and made a different call than I expected: they'd rather launch 28 languages well than 40 badly, and they took the language-count reduction to the launch stakeholders themselves. That wasn't my decision to make and I shouldn't have pre-made it.

What I refused to cut: the eval harness and the rollback path. My position was that shipping without a way to measure or revert isn't shipping fast, it's shipping blind — and if we were going to take risk, I wanted to be able to see and undo it.

We shipped 28 languages on time. Three weeks later we added the rest properly. The one thing I got wrong: I wrote that doc in week three. It should have been week one, when the options were still open — by week three, two of the alternatives were already foreclosed by work we'd done."

Why it works: reframed the tradeoff into a scope decision, which is the correct frame · made the consequence concrete and user-facing rather than abstract · escalated the decision to the people who owned it instead of quietly absorbing it · named what he would not cut and why · the self-critique is about timing, which is the most common real error.

Probes:

• "What if product had said 'ship all 40 anyway'?"
• "How did the team feel about the descope?"
• "How did you decide what to refuse to cut?"

F10. Changed your mind from data

"Tell me about a time data changed your mind."

Tested: whether you are attached to being right. Short answers are fine here.

Strong, compressed:

"I was convinced our ranking latency was dominated by feature computation, and I had a plan to cache features that would have taken a quarter.

Before starting I did a week of profiling — mostly to size the win, not to check the premise. Feature computation was 18% of p99. The dominant term was a synchronous call to a personalization service that I hadn't even drawn on the diagram, at 44%, mostly waiting.

I dropped the caching plan. We made that call concurrent with retrieval and added a 30 ms deadline with a fallback to non-personalized, which took about a week and cut p99 by 35%.

The uncomfortable part is that I'd been confidently telling people 'it's feature computation' for a month. I'd built that belief from one flame graph on a dev box under synthetic load, which had a completely different call pattern from production. What changed is that I now profile production, and I say 'I think' until I have."

Probes:

• "How long had you believed the wrong thing?"
• "Did you tell the people you'd told the wrong thing?"
• "What made you profile before starting rather than after?"

F11. Working with non-engineers

"Tell me about working with researchers, PMs, or safety/policy people."

Tested: reported explicitly for these companies — collaboration with researchers, PMs, and safety teams, not only with engineering peers.

Strong, compressed:

"Our research team had a reranker that was 4 nDCG points better offline. It was 400 ms at p99. Our whole budget was 200.

The unproductive version of this conversation is 'it's too slow' / 'make the budget bigger'. What I did instead was build them a latency-constrained eval: same eval set, but the model had to produce a result within a wall-clock budget, and I ran it at 50, 100, 200 and 400 ms.

That changed the conversation completely, because it turned a binary into a curve. At 200 ms with a distilled version they got 2.8 of the 4 points. And they found something I couldn't have: most of the gain came from one feature family, and a much smaller model using only that family got 2.1 points at 60 ms.

We shipped the 60 ms version first because it was strictly better than doing nothing, and the 200 ms version a quarter later once we'd freed budget elsewhere.

The general thing: give the other discipline a tool that expresses your constraint in their units. They don't want to violate your latency budget; they usually just have no way to see it in their workflow. The eval harness was worth more than any amount of me explaining the budget."

Probes:

• "What did they push back on?"
• "How did you handle it when research wanted to publish something you couldn't ship?"
• "Have you worked with safety or policy? What was different?"

F12. What you would build differently

"Tell me about something you built that you'd now build differently."

Tested: technical judgement developing over time. The failure mode is either "nothing" or a list of trivia.

Strong, compressed:

"I built our feature store with a single unified API for online and offline reads — same function signature, same feature definitions, and the store figured out whether you were in a training job or a serving path.

It was elegant and people liked it. It was also wrong, and it took me two years to see why.

The two paths have genuinely different requirements. Offline needs point-in-time correctness — the feature value as of the label's timestamp, or you leak future information into training. Online needs the freshest value and sub-millisecond latency. By unifying them I made point-in-time correctness an option rather than the default, and we shipped two models with leakage before we caught it. Both looked great offline and were mediocre in production, which is exactly the signature.

I'd now build them as two explicitly different APIs with a shared feature definition but separate read paths, where the offline read simply cannot be called without a timestamp — make the correct thing the only thing.

The generalizable lesson: I unified on the noun and I should have split on the verb. Two things that operate on the same data but have different correctness requirements are two things. Shared vocabulary is not shared implementation."

Why it works: the thing he built was genuinely good and liked, which makes the critique credible · the flaw is subtle and real and had a measurable consequence · the fix is an API-design principle ("make the correct thing the only thing") · the closing lesson is compact and portable.

Probes:

• "How did you catch the leakage?"
• "What would have prevented it in the original design?"
• "Have you seen the same mistake elsewhere?"

Chapter 3: The Probe Playbook

Every story needs three written probes. These are the seven that recur, and what each is actually testing.

The first probe is the discriminating one. If you cannot state the opposing case well enough that its holder would recognize it, the whole story becomes suspect — because it means either you never engaged with it, or you are editing it now.

Pre-empting probes is a strength, not padding. Notice how the outage answer (F4) answers "why didn't monitoring catch it" before being asked. That reads as someone who has genuinely thought about the failure rather than someone recalling it.

Chapter 4: The Forward-Looking Answers

Written out, rehearsed weekly, kept fresh. Company-specific material lives in ../../research/company-brief.md.

"Where do you think AI is headed?" — 90 seconds

Required structure: a specific falsifiable claim → evidence → a falsifier → what you would build.

Weak: "AI is going to transform every industry. Agents are the next big thing and I'm excited to be part of it." Zero information content.

Median: an accurate list of current trends — reasoning models, agents, multimodality, falling costs. Correct, unmemorable, indistinguishable from a newsletter.

Strong — a worked example, which you should match in specificity rather than copy:

"My claim is that over the next two years the binding constraint on useful AI is inference cost and latency under agentic workloads, not model capability.

The reasoning is arithmetic. One user action in an agentic system becomes tens of model calls — plan, call a tool, read the result, revise. So token volume per unit of user value goes up by an order of magnitude or more. Meanwhile decode is memory-bandwidth-bound, not compute-bound: the H200 has identical compute to the H100 and 43% more bandwidth, and it's materially faster at decode. That means the cost curve is tied to HBM bandwidth, which improves far more slowly than compute does. So cost per useful outcome falls more slowly than capability rises.

The second-order effect is the one I find more interesting: agentic traffic is burstier and more correlated than chat traffic — one user action produces a correlated burst — which breaks the autoscaling signals everyone built for request-response.

What would change my mind: if speculative decoding acceptance rates hold up at high ratios on real agentic traffic, or if a genuinely different serving architecture lands, the cost curve moves faster than I'm assuming and the constraint shifts back to capability. I'd also update if a large fraction of agent steps turn out to be cacheable — prefix caching does a lot of work here and I might be under-weighting it.

Which is why the work I want to do is on the serving side: scheduling, admission control, and the cache and routing layer. I've spent a decade on retrieval systems where the constraint was 'make this sub-100ms and cheap at scale', and this is that problem with a harder cost structure."

Why it works: a specific claim that could be wrong · arithmetic and a citable hardware comparison · a second-order observation showing you have thought past the headline · two explicit falsifiers, one of which weakens your own case · a connection to what you would build, grounded in what you have done.

Then stop and let them push. The push is where the points are.

"Why this company?" — 30 seconds

Ground it in the work, not the brand.

"Honestly, continuity rather than a pivot. I've spent ten years on retrieval, ranking and serving systems where the constraint was always 'sub-100 ms and cheap at scale'. The serving layer around a frontier model is the same problem with a harder cost structure and a memory-bandwidth wall instead of an I/O wall. And the retrieval side — chunking, embedding, index freshness — is literally what I've been doing. I'd be useful in month one, which isn't true of most places I could go."

"What would you work on?" — 30 seconds

"Inference serving and the retrieval systems around it. Concretely: scheduler policy — continuous batching, priority classes, preemption — plus KV cache and prefix reuse, plus admission control and fairness under non-stationary load. Those are queueing and scheduling problems with an unusual cost model, and I've shipped queueing and scheduling systems."

"What's our hardest unsolved engineering problem?" — 60 seconds

"Serving cost per useful token under adversarial, non-stationary, multi-tenant load, with a latency SLO users can feel.

The reason it's hard rather than just expensive: decode is memory-bandwidth-bound, so throughput comes from batching, and batching fights latency, and latency is the product. Every technique — continuous batching, prefix caching, speculative decoding, chunked prefill — is a different point on that curve, not a free win. And it isn't one curve: an interactive turn, a long agentic loop and a batch job want genuinely different scheduler policies, which forces a choice between separate pools and one priority-aware scheduler with preemption.

I'd be interested to be told I'm wrong about that, because I'm reasoning from public systems — vLLM, Orca, Sarathi — and I don't know where your reality diverges."

That last sentence is deliberate: it invites correction, which turns a monologue into a conversation and demonstrates you know the boundary of your knowledge.

"Your read on the mission and safety posture" — 30 seconds, honest

"I've read the Charter. The structurally interesting thing about it is that it's a constraint document with a stopping condition — the merge-and-assist clause pre-commits to abandoning a competitive position under a specified trigger, which is unusual and checkable.

The tension I notice is between pillars two and three: capability is argued as a prerequisite for safety. I find that argument mostly persuasive — you can't steer what you can't build — and I think the non-concentration commitment is the hardest one to keep, because it's the one most in tension with a commercial deployment business. I'd rather say that than perform either enthusiasm or skepticism about it."

Interviewers at these companies have finely tuned detectors for both performances. An honest partial disagreement is stronger than either.

Chapter 5: The Career Narrative

90 seconds, cold, no notes. The structure is through-line, not chronology.

The failure mode is a résumé read aloud: "I started at X, then I moved to Y, then I did Z." It is chronologically true and tells the listener nothing.

The fix is to name one thread and hang the jobs on it:

"The thread through everything I've done is systems that have to answer fast, at scale, and be right.

I started in networking and enterprise infrastructure, which is where I learned that the interesting problems are almost always about what happens when something fails rather than about the happy path. Then media streaming, where the constraint was delivering under genuinely unpredictable load. Then cloud infrastructure. For the last several years I've been on multilingual search and recommendation — retrieval, ranking, embeddings, index serving — which is where those two things converge: an unbounded corpus, a hard latency budget, and quality you have to measure rather than assert.

I'm finishing an MSCS with an AI specialization alongside that, mostly because I wanted the foundations underneath what I'd been building empirically.

What I'm looking for now is the same problem class one level harder — serving systems where the cost model is dominated by the accelerator rather than by I/O. Which is why I'm here."

Also prepare a 3-minute version for when they say "tell me more", with one specific project per era rather than a category.

Do not over-rehearse. If a recording sounds recited, cut it to bullet points and re-derive it live next session. It must sound like something you think, not something you memorized.

Chapter 6: What Not To Do

And the meta-rule: these are your stories. This file will not invent them, embellish them, or let a Senior-scope story be presented as Staff-scope. If a required category is genuinely absent from your history, that is a finding — the fix is to go get the experience, or to use the closest real analogue and be straight about its scope. Not to inflate.

References

• README.md — Track F drills, categories, rubric
• ../../research/company-brief.md — the mission material behind Chapter 4
• ../../diagnostics/d4-behavioral.md — the diagnostic prompts
• ../../diagnostics/ANSWER-KEY.md — the grading standard
• ../../mocks/README.md — the weekly scored behavioral mock
• Larson, W. Staff Engineer: Leadership Beyond the Management Track. — the archetypes and what scope means at this level
• Reilly, T. The Staff Engineer's Path. O'Reilly, 2022 — the best single book on operating at this altitude
• Fournier, C. The Manager's Path — the influence-without-authority chapters
• Google. Postmortem Culture: Learning from Failure. SRE Book Ch. 15 — for F4
• OpenAI. Charter. https://openai.com/charter/ · Anthropic. Core Views on AI Safety. https://www.anthropic.com/news/core-views-on-ai-safety