Personalize this lesson
Adapt explanations and teaching visuals to your background and preferred voice.
The technical presentation is where senior candidates prove depth. A polished deck helps, but the core signal is whether you can explain a hard system, defend tradeoffs, name what broke, show metrics, and answer follow-up questions without hiding behind local acronyms.
Pick the right project
Choose a project with:
- A real user or product pressure.
- A nontrivial architecture boundary.
- Migration or rollout risk.
- Measurable impact.
- At least one production failure or hard tradeoff.
- A natural bridge to AI systems: tools, retrieval, evals, data access, reliability, permissions, or serving.
Good neutral domains include deployment reliability, incident-status support, evaluation tooling, tenant data access, internal search, or developer-support automation.
Avoid projects that are only demos, only personal heroics, or only implementation detail.
The 15-minute structure
| Time | Section | What to prove |
|---|---|---|
| 1 min | Problem | why the system mattered |
| 2 min | Constraints | load, correctness, migration, users, reliability |
| 4 min | Architecture | boundary, request path, data model, ownership |
| 3 min | Tradeoffs | what was controversial and why |
| 2 min | Impact | metrics, adoption, reliability, velocity |
| 2 min | Lessons | what you would repeat or change |
| 1 min | Bridge | why this maps to AI lab systems |
What is the fastest way to weaken a technical presentation?
Answer
Start with implementation detail before the problem and constraints. Interviewers need to know why the system existed, what made it hard, and which decisions mattered before they care about class names or internal APIs.
Presentation pattern taxonomy
Different projects need different proof arcs. Choose the pattern that matches your strongest evidence.
| Pattern | Best project type | Core proof | Deep-dive risk |
|---|---|---|---|
| Architecture section | platform, gateway, connector, serving path | boundaries, request path, data model, ownership | diagram too broad to defend |
| Migration story | replacing legacy system, changing API, moving data | compatibility, rollout, risk reduction, adoption | no rollback or dual-run plan |
| Incident-to-system story | outage, safety issue, reliability regression | diagnosis, customer impact, permanent mechanism | sounding heroic instead of systematic |
| Eval or quality loop | ranking, retrieval, model behavior, automation | metric design, failure slices, regression gates | metric not tied to product risk |
| Agent/tooling platform | code agents, internal assistants, workflow automation | permissions, sandbox, audit, human review | hand-wavy autonomy story |
| Performance/cost story | latency, throughput, GPU use, queueing | bottleneck, measurement, optimization, tradeoff | optimizing without user-facing SLO |
| Security/privacy boundary | data access, credentials, compliance, redaction | threat model, permission boundary, audit | controls named but not enforced |
If you have several possible projects, choose the one with the strongest combination of architecture, tradeoff, incident learning, and metrics. A narrower system with real evidence beats a flashy demo with weak ownership.
Slide inventory
Keep the deck small enough that questions can interrupt it.
| Slide | Content |
|---|---|
| 1 | One-sentence thesis and user/system stakes |
| 2 | Constraints: scale, correctness, privacy, migration, reliability |
| 3 | Architecture diagram with at most 7 boxes |
| 4 | Request path or data lifecycle |
| 5 | Hard tradeoff with rejected alternative |
| 6 | Rollout, eval, or incident-learning mechanism |
| 7 | Impact metrics (system + AI quality tiers) and what would falsify each claim |
| 8 | Lessons, current limitations, AI/backend bridge |
Don't add an "about me" slide unless asked. Let the project prove judgment.
Two-tier metrics slide
Lab deep-dives expect both operational metrics and AI-quality metrics. Put them on the same slide with a falsifier for each claim:
| Tier | Examples | Falsifier |
|---|---|---|
| System | TTFT, ITL, GPU/KV utilization, cost per request, error rate, p95 latency | Canary breaches dual SLOs or cost envelope |
| AI quality | recall@k, groundedness / citation support, safety refusal quality, judge-human correlation | Offline gate fails a frozen slice, or online quality regresses while system metrics look fine |
Adoption and incident counts alone don't prove model or retrieval quality. Say which metric would force you to reverse the design.
Q&A defense map
Prepare answers before making slides pretty.
| Question pattern | Answer shape |
|---|---|
| "Why this design?" | dominant constraint -> rejected option -> mitigation -> reversal signal |
| "What broke?" | symptom -> hypothesis -> evidence -> fix -> durable prevention |
| "How did you know it worked?" | metric -> baseline -> target -> result -> caveat |
| "What was your role?" | boundary owned -> decisions made -> artifacts shipped -> team interface |
| "What would you change now?" | current weakness -> new evidence -> next design -> migration risk |
| "How does this map to AI systems?" | shared mechanism -> AI-specific risk -> added eval/control |
| "What if scale grows 10x?" | bottleneck -> queue/cache/shard/control-plane change -> new SLO |
| "What did you simplify?" | scope cut -> reason -> risk accepted -> later trigger |
When you don't know an answer, say where the uncertainty lives:
I didn't own that subsystem directly. The part I can defend is
X. My best hypothesis isY, and I would verify it withZ.
Rehearsal ladder
Practice the same project at four lengths:
| Version | Goal |
|---|---|
| 30 seconds | thesis, user pain, why it mattered |
| 90 seconds | problem, architecture, hardest tradeoff, impact |
| 5 minutes | core talk without appendix |
| 15 minutes | full talk with one controlled technical section |
Interview formats vary by role. If your process includes a 15 to 20 minute talk followed by Q&A, budget the talk tightly and rehearse interruptions without needing the next slide. Prepare ownership boundaries, tradeoff reversals, and metric falsifiers for the discussion that follows.
After each rehearsal, answer three forced questions:
- What did I own personally?
- What would I change now?
- Which metric could make my chosen design wrong?
If those answers are weak, fix the packet before adding another slide.
Appendix and evidence pack
Prepare an appendix even if you never show it. It lets you answer depth questions without inventing details under pressure.
| Appendix item | What it should contain |
|---|---|
| Original problem statement | user pain, owner, success metric, why status quo failed |
| Architecture before and after | old request path, new request path, migration boundary |
| Data model | important entities, indexes, retention, versioning, isolation |
| API contract | request, response, errors, auth context, idempotency or retry semantics |
| Tradeoff table | chosen option, rejected option, downside, mitigation, reversal signal |
| Failure timeline | symptom, customer impact, hypothesis, fix, durable prevention |
| Metrics sheet | baseline, result, caveat, owner, date range; system tier and AI-quality tier |
| Rollout plan | beta, canary, kill switch, eval gate, rollback trigger |
| Shadow / dual-run path | shadow traffic, compare system + quality metrics, promote criteria, abort criteria |
| Security and privacy notes | permissions, credentials, audit, deletion, data minimization |
| AI-system bridge | tool, retrieval, eval, serving, or observability mapping |
For migrations, a shadow path is a common lab deep-dive: send production traffic to the new path without user-visible effect, compare TTFT/ITL and quality metrics against the old path, promote only when both tiers clear the gate, and keep an abort that returns 100% to the old path.
For every appendix page, write the one sentence you would say if interrupted:
The reason this detail matters is
claim, and the evidence isartifact.
Survive scale probing
Interviewers may switch from your narrative to the internals and failure modes of any tool, framework, or algorithm you name. That probing tests whether you understand the system beyond its surface API. Google DeepMind's public candidate guide asks applicants to think aloud, explain their reasoning, and use data to show impact.[1]
Follow the exact recruiter instructions for your process when using AI or external tools. For example, Google DeepMind's guide allows AI for preparation but says not to use AI tools during live interviews or interview tasks unless told otherwise.[1]
The defense is a rule you apply while building the deck, not a trick you use live: every piece of the stack you mention must survive both an internals question and a failure-mode question. If it can't, cut it, or label it plainly as "we used it, I didn't own it."
| If you cite... | Be ready to explain the internals | Be ready to explain the failure mode |
|---|---|---|
| Kubernetes | how pods land on GPU nodes, taints and tolerations, horizontal pod autoscaling | OOMKilled pods, node-pressure eviction, autoscaling that fights long-lived streaming connections |
| Kafka | partitions, consumer groups, offset commits | consumer-group rebalance storms, unbounded lag, poison messages |
| vLLM or another serving engine | paged attention, continuous batching, KV cache blocks | KV cache exhaustion, request preemption, tail latency under burst load |
| Vector index (HNSW, IVF-PQ) | graph layers or coarse quantization, the ef_search or nprobe knob | recall-versus-latency tradeoff, index rebuild cost, stale or deleted vectors |
| Ray | actors, tasks, the shared object store | object spilling to disk, head-node failure, scheduler backpressure |
Run a cut pass over your slides and appendix: for every named technology, write the two-level "why" and the one failure mode you've actually seen. Anything you can't answer twice goes on a "used, not owned" list so you can say so cleanly instead of getting exposed under questioning.
Your deck says "we deployed on Kubernetes." You configured the app but never touched cluster scheduling. How do you present that without getting caught overclaiming?
Answer
Name the boundary before the interviewer probes it: "We ran on Kubernetes; I owned the deployment manifests and readiness checks, but the platform team owned node pools and autoscaling." Then offer the part you can defend two levels deep. Volunteering the edge of your ownership is far stronger than being pushed off a claim you can't support.
One-page outline
Prepare this before making slides:
1Problem:
2 One sentence naming user pain and system risk.
3
4Constraints:
5 3 bullets: scale, correctness, migration, latency, privacy, or reliability.
6
7Architecture:
8 One diagram with no more than 7 boxes.
9
10Tradeoffs:
11 3 decisions where reasonable people could disagree.
12
13Impact:
14 4 numbers: adoption, latency, cost, incidents, velocity, or coverage.
15
16Lessons:
17 2 things you would repeat and 1 thing you would change.
18
19Bridge:
20 1 sentence connecting the work to AI/backend systems.Why should the one-page outline come before slides?
Answer
Slides can hide missing substance. The outline forces the proof arc first: problem, constraints, architecture, tradeoffs, impact, lessons, and a concrete bridge to AI/backend systems.
Build one outline slowly
Use one project all the way through rehearsal. Treat this as an illustrative skeleton: replace its numbers with your own evidence instead of borrowing claims.
| Layer | Connector-platform example | Why it belongs |
|---|---|---|
| Problem | Support engineers needed runbooks and tenant-policy data, but each new source required a custom integration path. | Names the user pain before implementation detail. |
| Constraints | Tenant-specific credentials, different pagination models, safe migration, support debugging, and an existing latency SLO. | Explains why a small-looking integration problem was hard. |
| Architecture | Gateway -> router -> connector contract -> source adapter -> store. The gateway emits request IDs and traces. | Shows the ownership boundary and request path. |
| Tradeoff | Keep connectors in-process for migration speed, with strict contract tests; split them into a service if queue time or deploy coupling becomes the bottleneck. | Defends a contextual choice and names its reversal signal. |
| Impact | Source onboarding fell from 20 days to 6 days; repeated integration paths fell from 8 to 1; connector-related incidents fell from 5 to 1 per quarter; p95 latency stayed below 800 ms. | Uses inspectable evidence instead of "it improved velocity." |
| Lesson | Make contract tests part of the platform boundary, not a cleanup task after migration. | Shows changed judgment. |
| AI bridge | Agent tools need the same scoped credentials, audit trails, retries, support-visible traces, and regression cases. | Transfers the mechanism without overclaiming model research. |
Why does the tradeoff row name a reversal signal?
Answer
A tradeoff is credible when it can become wrong. Queue time or deploy coupling would justify a service split later. That is stronger than claiming the first design was universally best.
Diagram discipline
Your architecture diagram should show boundaries, not every library. For AI lab interviews, strong boundaries include:
- Client or product surface.
- Gateway or control plane.
- Planning or routing layer.
- Connector, tool, or execution boundary.
- Data store or index.
- Evaluation or regression suite.
- Observability and support path.
In the connector example, every box earns its place. Requests cross ownership boundaries, external behavior gets normalized, evals protect correctness, and support engineers get evidence they can inspect.
Mock presentation prompts
Use this practice question after drafting the talk. Answer before opening the guide.
Prompt 1: "How does this project map to AI systems?"
Prompt details:
- Avoid claiming model research experience if the project was platform/backend work.
- Bridge through concrete mechanisms.
- Mention tools, retrieval, evals, permissions, serving, observability, or rollout.
Clarifying questions to ask:
- Should I map this to agent systems, retrieval systems, or model-serving infrastructure?
- Is it more useful to compare risks or reusable mechanisms?
Solution guide
Strong answer shape:
- Name the shared system property: trusted data access, tool execution, reliability, debugging, or launch discipline.
- Map one project boundary to an AI boundary.
- Map one metric or test to an AI eval or rollout signal.
- Name one new risk AI adds.
- Explain the mechanism you would add.
Example: "The project maps to AI agents through tool boundaries. We learned that integrations need scoped permissions, audit trails, retries, and support-visible traces. For an agent, I would add eval cases for unauthorized actions, a canary rollout, and a human gate before irreversible writes."
Follow-up guide
If asked for a concrete AI-specific extension, add one mechanism instead of adding buzzwords:
I would add an eval suite for unauthorized tool calls, a policy layer that decides which actions require review, and traces that show prompt, tool choice, permission decision, and final artifact.
If asked what changes at higher scale, mention queueing, tenant isolation, rate limits, cost controls, and support-visible request IDs.
What should you do when a deep-dive question exposes a weak spot in the project?
Answer
Answer directly, separate what was shipped from what you would change now, and name the evidence that would decide the next design. Don't invent impact or pretend the weak spot didn't matter.
Common presentation failure modes
| Symptom | Why it weakens the talk | Fix |
|---|---|---|
| Too many slides and no memorable thesis | The reviewer can't tell which decision mattered. | Write the one-sentence problem before making slides. |
| Local acronyms with no translation | The audience spends attention decoding names instead of following the system. | Replace internal names with roles: gateway, router, connector, store, eval suite. |
| Metrics without interpretation | Numbers become decoration. | Say which claim each metric supports and which metric could disprove it. |
| Tradeoffs with no credible alternative | The decision sounds preordained. | Steelman the rejected option, name the downside you accepted, and give a reversal signal. |
| Incident story with no durable lesson | Recovery can sound like personal heroics. | Explain the regression case, rollout change, or support signal that improved afterward. |
| Broad team impact with vague ownership | The audience can't inspect your contribution. | Name your boundary, design choice, test strategy, and migration responsibility. |
| AI bridge made of buzzwords | The mapping doesn't prove transferable judgment. | Connect one existing mechanism to tools, retrieval, evals, permissions, or serving. |
Interview preparation artifacts
Your portfolio should contain four inspectable artifacts: runnable Python systems, system-design answers with scale math and failure behavior, behavioral stories with evidence, and a technical talk with architecture, tradeoffs, metrics, and ownership boundaries. Use the LeetLLM roadmap to revisit any weak phase, then close the gap with code, tests, an eval report, a design document, a cost or latency model, or a failure analysis.