Interview Prep — Senior Engineer, Platform Engineering & Architecture
Four chapters — the battle plan, a 150-question rapid-fire bank, six architecture-review drills with the red flags planted, and the behavioural round — plus the orientation below.
| Chapter | For |
|---|---|
| 01 — The Battle Plan | this JD line by line, with the sentence that answers each |
| 02 — Rapid-Fire Bank | 150 questions with model answers, drilled out loud |
| 03 — Architecture-Review Drills | six designs to critique, and how to deliver a review |
| 04 — Behavioural & Staff Signal | two-in-a-box, disagreement, incidents, regulators, mentorship |
What this loop actually tests
This is not a generic "AI engineer" interview. Read the JD closely and the shape is specific: a two-in-a-box senior technical authority for a regulated bank's agent platform. That produces five distinct assessments, usually across four or five conversations.
| # | Assessment | What they are really asking | Where the material is |
|---|---|---|---|
| 1 | Platform architecture | Can you own a five-layer stack and defend an SLO with arithmetic? | Phase 00 · System Design |
| 2 | Agentic depth | Do you understand runtimes and protocols at mechanism level, or have you only used a framework? | Phases 01–03 |
| 3 | Model & serving economics | Can you make a capacity and routing decision with numbers? | Phases 04–05 |
| 4 | Identity, security & governance | The hardest part of the JD, and the one most candidates hand-wave | Phases 08–11, 15 |
| 5 | Run-state & operating model | Have you carried a regulated pager, and can you work two-in-a-box? | Phases 14, 16 |
The six sentences that carry the loop
Memorize these. Each is defended at length in the phase it comes from, and each one, said unprompted, moves the conversation.
- "The model proposes, the platform disposes." — the whole architecture in five words.
- "Composed, that's 99.10%; here are the two changes that get it to 99.66%." — you compute rather than assert (Phase 00).
- "
retryableandfall_overare different flags — a content filter is neither, because otherwise you're shopping for a compliant model." (Phase 04) - "Checkpointing gives me resumability, not exactly-once. Effects are the action gateway's problem." (Phase 01 → 10)
- "The delegation chain is derived from a verified credential, never asserted in the request." (Phases 03, 08)
- "If you can't produce the evidence, you didn't build the control." (Phase 15)
The numbers to have cold
From the Cheat Sheet, the ones most likely to be needed live:
| Thing | Number |
|---|---|
| 99.9% error budget | 43.2 min / month |
| 0.999⁵ | 0.995 — five "three-nines" layers |
| Page burn rate | 14.4, derived as 0.02 × 720 |
| 20 steps at p = 0.95 | 36% task success |
| 10-step scratchpad (b=1k, a=2k) | 100 000 input tokens |
| KV bytes/token | 2·L·H_kv·d·b — 320 KiB for a 70B GQA model |
| 70B fp16 weights | ~130 GiB — does not fit one 80 GiB card |
| Batch-1 decode intensity | ~1 vs a ridge point of ~300 |
| PTU break-even, 10% → 50% output mix | 77% → 40% utilization |
| Consistent hashing, 3 → 4 nodes | ~25% move, vs ~75% for modulo |
Preparation plan
Six weeks, if you have the time. One phase per three days for 00, 04, 08, 09, 10, 14 — the
minimum set for a credible architecture conversation on this JD — then two
system designs written out end to end, then a pass over every
STAFF-NOTES.md interview-signal section.
One week, if you don't. Read Phase 00's WARMUP
properly and do its lab. Then read the six HITCHHIKERS-GUIDE.md files back to back — they are
written to be read in that order and they carry the numbers. Then write out, from memory, the
five-layer stack with what each layer denies.
The night before. The Cheat Sheet, and the six sentences above.
Questions to ask them
Interviews are two-way, and for this role the right questions are diagnostic — each one tells you whether the platform is real, and signals that you know which question to ask:
- "Does the platform publish an error budget, and has a freeze ever actually triggered?" — whether the operating model is real or aspirational.
- "Where does session state live, and what happens to in-flight runs during a deploy?" — platform maturity in one sentence.
- "When a tool's schema changes, how do you find out who breaks?" — whether the estate is governed.
- "What's your measured input-to-output token ratio, and how much capacity sits idle?" — whether cost is managed or assumed.
- "When an agent delegates to another team's agent and the outcome is wrong, who owns it?" — whether there is a topology or a diagram.
- "How does two-in-a-box resolve a genuine disagreement?" — whether the operating model has been tested.
Anti-signals to avoid
Collected from every phase's STAFF-NOTES.md, in rough order of how badly they land:
- Quoting an SLO without composing it.
- "We use LangGraph" as an answer to "how does your runtime work?"
- Failing over on any error, including a safety refusal.
- Session state in process memory, unremarked.
- Treating checkpointing as exactly-once.
- Cost per token as the optimization target.
- Concurrency estimated from FLOPs.
- Enthusiasm for multi-agent with no mention of depth or cycles.
- Describing two-in-a-box as a reporting line.
- No answer to "what happens when the control plane is unreachable?"
Where the rest of the material is
The four chapters above are the concentrated version. The full depth lives in the phases, and two sections in particular are written in the voice you would actually use out loud:
- every phase's
WARMUP.md§ Interview questions, answered — model answers at length; - every phase's
STAFF-NOTES.md§ review signal — what a strong answer sounds like, and what a weak one does.
And the System Design Walkthroughs are the other half of the loop: five worked designs at exactly the altitude this role is interviewed at.