Personalize this lesson
Adapt explanations and teaching visuals to your background and preferred voice.
You have fifteen minutes to explain a system you built. The first slide could list internal class names, or show a 20-day onboarding wait and an 800 ms response target the migration couldn't break. Which opening gives a skeptical listener a reason to care about the architecture?
The last chapter practiced judgment with evidence: what you noticed, changed, measured, and owned. Now turn one of those projects into a talk that lets another engineer inspect those decisions. OpenAI's public interview guide says interviewers want to understand how you approach problems, make decisions, and communicate your reasoning, alongside well-designed solutions, high-quality code, performance, and test coverage.[1] Google DeepMind's candidate guide asks you to think out loud and use data to show impact.[2]
We'll follow one connector platform from user pressure to boundaries, tradeoffs, metrics, rollout, and questioning. A technical talk earns depth by making each detail answer a question the audience already has, not by exposing every internal name.
Pick a project that can be questioned
Choose work where a real user pressure crosses a nontrivial architecture boundary. In the talk, name a migration or rollout risk, show measurable impact, and describe at least one failure or hard tradeoff. The mechanisms should map naturally to AI systems: tools, retrieval, evals, data access, reliability, permissions, or serving.
Keep one running example in view: support engineers needed tenant-policy docs and partner runbooks. Each new source had its own HTTP client, credential store, and pagination quirks. Eight one-off paths existed. Onboarding a source took 20 days, and the migration had to stay under an 800 ms latency SLO. When a lookup failed, support had no request ID.
That project isn't a model paper, and it doesn't need to be. It still maps to lab systems through scoped credentials, a contract boundary, golden tests, traces, and a later retrieval path for an internal assistant.
Avoid projects that are only demos, only personal heroics, or only implementation detail. A narrower system with real evidence beats a flashy prototype you can't defend two levels down.
Write the one-page outline first
Slides can make an empty story look complete. Write the proof arc before opening a deck tool. Read it aloud once: if a line can't explain a decision, an outcome, or evidence for the outcome, the packet needs work before its visual polish.
1Problem:
2 Support waited 20 days to onboard a partner runbook source.
3
4Constraints:
5 Tenant-scoped secrets, incompatible pagination, an 800 ms p95 SLO,
6 and support debugging during a live migration.
7
8Architecture:
9 Support UI -> gateway -> connector contract -> in-process adapter
10 -> tenant store, plus traces and golden tests. Seven boxes.
11
12Tradeoffs:
13 Keep adapters in-process for migration speed. Split to a service if
14 queue time or deploy coupling becomes the bottleneck.
15
16Impact:
17 Onboarding 20 days -> 6 days. One-off paths 8 -> 1.
18 Connector incidents 5/quarter -> 1/quarter. p95 720 ms -> 680 ms.
19
20Lessons:
21 Contract tests belong on the platform boundary, not in a cleanup sprint.
22
23Bridge:
24 Agent tools need the same scoped credentials, audit trail, retries,
25 and a human gate before irreversible writes.Keep these values as a fixed teaching fixture. Replace them with your own evidence when you rehearse, and don't borrow them as if they were yours. The important habit is the chain: pain creates constraints, constraints shape architecture, architecture creates tradeoffs, and metrics test whether the choice paid off.
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 systems.
Spend the 15 minutes on decisions, not files
Formats vary by role. If your process includes a 15 to 20 minute talk followed by Q&A, treat each minute as a proof obligation and rehearse a useful answer even when the panel interrupts before the next slide.
| Time | Section | What to prove |
|---|---|---|
| 1 min | Problem | why the system existed |
| 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 |
The eight-slide sequence mirrors that budget. Skip an "about me" slide unless the format asks for one; the project should provide the evidence of judgment. A listener should leave each early slide knowing why the next one exists.
| 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) and what would falsify each claim |
| 8 | Lessons, current limits, AI/backend bridge |
If a demo is part of the format, rehearse one request path instead of a feature tour. Show a support lookup with its request ID, one source adapter, and the resulting trace or answer. Tell the audience what to watch for before you run it, and keep a captured trace ready if a live dependency fails. A demo proves behavior; tests and metrics show whether that behavior holds beyond one request.
If eight minutes go to object-relational mapping (ORM) classes and two go to architecture, the audience learns implementation vocabulary before it knows what the connector changed. Give those minutes to the request path and the in-process versus service split, where the hard decisions live.
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.
Choose the proof arc that matches the evidence
Start with the evidence you can inspect, then choose a story that lets it do the teaching. The connector platform is an architecture talk with a migration inside it. If your strongest artifact is an outage, don't reshape it into a latency optimization to make the story sound cleaner.
| 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 a legacy system, changing an 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 a user-facing SLO |
| Security/privacy boundary | data access, credentials, compliance, redaction | threat model, permission boundary, audit | controls named but not enforced |
If several projects qualify, choose the one with the clearest mix of architecture, tradeoff, incident learning, and metrics. A smaller project with a traceable decision is easier to defend than a larger one whose evidence belongs to someone else.
Draw boundaries, not libraries
Trace one support lookup from caller to source and mark every place the request changes owners, gets normalized, tested, or observed. That is what an architecture diagram should expose. For AI lab interviews, useful role boxes are a product surface, a gateway or control plane, a planner or router, a connector/tool/execution boundary, a store or index, an evaluation or regression suite, and an observability path.
The connector talk uses all seven. Support UI is the caller. You owned the gateway, the connector contract, the in-process adapters, the golden tests, and trace emission. You didn't own the tenant store. Put that boundary on the slide so a later question about indexes has an honest owner.
Read the path left to right, then follow the two side paths. Requests cross an ownership boundary at the gateway, contract, adapter, and store. Golden tests protect the contract before rollout, while a request ID lets support inspect a live trace. Each box now answers either "who owns this?" or "how do we know it worked?"
Don't put helper packages, wrappers, or internal code names on this slide. If a library changes a decision, keep it for Q&A and explain the mechanism and failure mode it introduces.
Name the tradeoff and the reversal
A tradeoff is credible when it can become wrong. Give the audience four handles: the constraint, the chosen side, the cost you accepted, and the evidence that would make you switch.
Suppose a reviewer asks, "Why not make each adapter a service?" The connector team kept adapters in-process because the migration needed one deploy, one debugger, and one contract test suite. The rejected alternative offered independent scaling later, but it would have added a queue, a second deploy, and a new failure domain while eight callers were still moving.
The reversal signal was explicit: if queue time or deploy coupling became the bottleneck despite the contract tests, split the adapters into a service. Passing tests and a quieter incident rate aren't that signal; they're reasons to keep the current design. The answer stays conditional instead of pretending one topology wins forever.
Why does the tradeoff 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's stronger than claiming the first design was universally best.
Put system metrics and quality metrics on the same slide
Ask one uncomfortable question before building the impact slide: could latency improve while the system becomes less useful? Put operational metrics and AI-quality metrics together, with a falsifier for each claim.
After the connector contract existed, an internal assistant started retrieving runbooks through the same gateway. Latency staying green no longer proved the lookup was useful.
| Tier | Connector numbers | Falsifier |
|---|---|---|
| System | p95 latency 720 ms → 680 ms under an 800 ms SLO; connector incidents 5/quarter → 1/quarter | Canary p95 exceeds 800 ms, or incidents return to ≥3/quarter |
| Product | Source onboarding 20 days → 6 days; one-off paths 8 → 1 | A new source still takes >15 days, or a ninth custom path ships |
| AI quality | Runbook recall@5 0.74 → 0.81 on a frozen tenant-policy slice | The frozen slice drops while p95 still looks fine |
Adoption and incident counts don't prove retrieval quality. Read each row as a different decision: system safety, product payoff, or answer usefulness. Google Cloud's MLOps guidance describes online validation through a canary or A/B setup before a newly deployed model serves all traffic, not only an offline check.[3]
The connector canary uses that same separation: both the system tier and the quality tier have to pass. A metric becomes useful when you can name the observation that would make you hold or reverse the rollout.
Don't lead the impact slide with the 40 ms latency change. The larger story is onboarding days and incident count; latency shows you didn't break the SLO while improving them.
Put one limitation beside each result. A frozen tenant-policy slice may not represent every tenant, incident counts depend on the traffic window, and p95 latency says nothing about whether retrieval returned the right runbook. Naming those limits keeps a strong number from carrying a claim it can't support.
Prepare the answers before you polish slides
Q&A is where a polished story has to become inspectable. Google DeepMind's guide tells candidates to think out loud, say when they're unsure, and use data to show impact.[2] Write the answer shape before choosing fonts, then rehearse it against the connector's actual decisions.
| 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, locate the uncertainty instead of filling the silence with a guess:
I didn't own that subsystem directly. The part I can defend is
X. My best hypothesis isY, and I would verify it withZ.
Survive internals questions on anything you name
Any named tool can become the next question. For each one, rehearse two paths: what happens inside it, and what breaks when its assumption fails. If you can't defend both, cut the name or label it honestly as "we used it, I didn't own it."
Follow the recruiter's instructions for AI tools. DeepMind's public guide allows AI for preparation and says not to use AI tools during live interviews or interview tasks unless told otherwise.[2]
| 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 | PagedAttention's logical-to-physical KV blocks[4], continuous batching, the block pool | 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 |
The vLLM row models the standard. The next chapter opens that engine from its public API down through scheduling and KV-cache allocation. If you can't defend those two levels yet, leave the logo off slide 3 and keep the boundary in the appendix.
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.
Keep an appendix you may never show
Keep an appendix even if you never open it. It gives every deep question a place to land, so you can show evidence instead of inventing detail 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 the connector migration, the shadow path was the deep-dive. Live lookups still hit the old one-off clients while a copy of each request went to the new gateway with no user-visible effect. You compared p95 and runbook recall@5 against the old path, promoted only when both tiers cleared the gate, and kept an abort that returned 100% to the old path. That sequence gives the audience a concrete answer to "How did you know it was safe?"
Time to first token (TTFT) and inter-token latency (ITL) matter once the assistant is generating. For the connector lookup itself, p95 request latency and recall@5 are the two tiers. Don't promote because dashboards are green if the frozen tenant-policy slice got worse.
For every appendix page, write the one sentence you would say if interrupted:
This detail supports
claim, andartifactis the evidence.
Rehearse the proof at four lengths
A talk that works only at its full length is fragile. Practice the same project at four lengths, keeping the same thesis and evidence:
| 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 |
After each rehearsal, answer three questions out loud: what did I own personally, what would I change now, and which metric could make my chosen design wrong?
If those answers are weak, fix the packet before adding another slide.
The small checker below turns those promises into assertions. It can't judge whether your story is interesting, but it catches a packet with too many architecture boxes, implementation minutes crowding architecture, a metric with no falsifier, or a named technology marked owned without internals and a failure mode.
1from dataclasses import dataclass, field
2
3PLANNED_MIN = {
4 "problem": 1,
5 "constraints": 2,
6 "architecture": 4,
7 "tradeoffs": 3,
8 "impact": 2,
9 "lessons": 2,
10 "bridge": 1,
11}
12
13@dataclass(frozen=True)
14class Metric:
15 name: str
16 baseline: float
17 result: float
18 falsifier: str
19
20@dataclass(frozen=True)
21class Tradeoff:
22 choice: str
23 rejected: str
24 reversal: str
25
26@dataclass(frozen=True)
27class NamedTech:
28 name: str
29 owned: bool
30 internals: str = ""
31 failure_mode: str = ""
32
33@dataclass
34class Packet:
35 problem: str
36 constraints: list[str]
37 architecture_boxes: list[str]
38 tradeoffs: list[Tradeoff]
39 metrics: list[Metric]
40 named_tech: list[NamedTech]
41 minutes: dict[str, int] = field(default_factory=dict)
42
43def check(packet: Packet) -> list[str]:
44 issues: list[str] = []
45 if not packet.problem.strip():
46 issues.append("missing problem")
47 if len(packet.constraints) < 2:
48 issues.append("need at least 2 constraints")
49 n_boxes = len(packet.architecture_boxes)
50 if n_boxes > 7:
51 issues.append(f"architecture has {n_boxes} boxes; cap is 7")
52 total = sum(packet.minutes.values())
53 if total != 15:
54 issues.append(f"minutes sum to {total}, not 15")
55 impl = packet.minutes.get("implementation", 0)
56 arch = packet.minutes.get("architecture", 0)
57 if impl > arch:
58 issues.append(f"implementation {impl}m exceeds architecture {arch}m")
59 for item in packet.tradeoffs:
60 if not item.reversal.strip():
61 issues.append(f"tradeoff {item.choice!r} has no reversal signal")
62 for metric in packet.metrics:
63 if not metric.falsifier.strip():
64 issues.append(f"metric {metric.name!r} has no falsifier")
65 for tech in packet.named_tech:
66 if tech.owned and (not tech.internals.strip() or not tech.failure_mode.strip()):
67 issues.append(f"{tech.name} is owned but missing internals or failure mode")
68 return issues
69
70weak = Packet(
71 problem="We refactored the connector helpers.",
72 constraints=["latency"],
73 architecture_boxes=[
74 "ORM", "repo", "cache wrapper", "retry mixin", "metrics lib",
75 "flag client", "ticket parser", "admin UI", "pager", "wiki",
76 "helm chart", "log shipper",
77 ],
78 tradeoffs=[Tradeoff("in-process", "microservice", "")],
79 metrics=[Metric("p95_ms", 720, 680, "")],
80 named_tech=[NamedTech("Kubernetes", owned=True)],
81 minutes={"problem": 1, "architecture": 2, "implementation": 8, "metrics": 2, "wrap-up": 2},
82)
83strong = Packet(
84 problem="Support waited 20 days to onboard a partner runbook source.",
85 constraints=["tenant secrets", "pagination", "800 ms p95 SLO", "live migration"],
86 architecture_boxes=[
87 "Support UI", "gateway", "connector contract", "source adapter",
88 "tenant store", "golden tests", "traces",
89 ],
90 tradeoffs=[
91 Tradeoff(
92 "in-process adapters",
93 "connector microservice",
94 "split if queue time or deploy coupling becomes the bottleneck",
95 )
96 ],
97 metrics=[
98 Metric("onboarding_days", 20, 6, "new source still takes >15 days"),
99 Metric("p95_ms", 720, 680, "canary p95 > 800 ms"),
100 Metric("recall_at_5", 0.74, 0.81, "frozen tenant-policy slice drops"),
101 ],
102 named_tech=[
103 NamedTech(
104 "Kubernetes",
105 owned=False,
106 internals="not owned; platform team runs node pools",
107 failure_mode="not owned",
108 )
109 ],
110 minutes=dict(PLANNED_MIN),
111)
112
113weak_issues = check(weak)
114strong_issues = check(strong)
115print("weak:", "; ".join(weak_issues))
116print("strong issues:", len(strong_issues))
117assert any("12 boxes" in item for item in weak_issues)
118assert any("implementation 8m" in item for item in weak_issues)
119assert any("no falsifier" in item for item in weak_issues)
120assert any("Kubernetes" in item for item in weak_issues)
121assert strong_issues == []1weak: need at least 2 constraints; architecture has 12 boxes; cap is 7; implementation 8m exceeds architecture 2m; tradeoff 'in-process' has no reversal signal; metric 'p95_ms' has no falsifier; Kubernetes is owned but missing internals or failure mode
2strong issues: 0Swap in your own packet. If check still prints issues, another rehearsal on the current slides won't fix them.
Walk the connector talk once
Read this once as a spoken proof, not a slide inventory. Each block answers the question raised by the previous one: why the system existed, what constrained it, where you drew boundaries, what you traded, and what the evidence says now. The sentences are the talk, not speaker notes you invent later.
Problem (1 min). Support engineers were waiting 20 days to onboard a partner runbook source. Eight teams had written eight slightly different HTTP clients, each with its own credential store. Lookups failed silently. Support had no request ID.
Constraints (2 min). The work wasn't "write a cleaner client." Credentials were tenant-scoped. Pagination models differed by partner. We couldn't break an 800 ms p95 SLO during the move. Support had to debug the old and new paths at the same time.
Architecture (4 min). New lookups enter a gateway that stamps a request ID, hit a connector contract, run an in-process adapter, and read the tenant store. Golden tests sit on the contract. Traces sit on the gateway. I owned those five pieces. I didn't own the store's indexes.
Tradeoff (3 min). We kept adapters in-process so the migration had one deploy and one debugger. A service split was the honest alternative. We would do it if queue time or deploy coupling showed up despite the contract tests.
Impact (2 min). Onboarding fell from 20 days to 6. One-off paths fell from 8 to 1. Connector incidents fell from 5 per quarter to 1. p95 moved from 720 ms to 680 ms and stayed under 800 ms. Later, runbook recall@5 on a frozen tenant-policy slice moved from 0.74 to 0.81. If that slice dropped while p95 looked fine, we would abort the canary.
Lessons and bridge (3 min). Contract tests belong on the platform boundary, not in a cleanup sprint. Agent tools need the same scoped permissions, audit trails, retries, and support-visible traces. I would add eval cases for unauthorized actions, a canary, and a human gate before irreversible writes.
Notice where the AI connection appears: after the project has earned its evidence. The bridge reuses mechanisms you can defend and adds the AI-specific risks, instead of claiming that a connector project was secretly model research.
Common presentation failure modes
When a talk sounds polished but questions have nowhere to go, inspect the symptom rather than adding slides. Each row below connects an audience problem to a repair you can rehearse.
| 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. |
Mock presentation prompt
Test the last bridge after drafting the talk. Answer the prompt once before opening the solution guide, then check whether your answer names a mechanism, an AI-specific risk, and an added control.
Prompt: "How does this project map to AI systems?"
Keep the claim honest if the project was platform/backend work rather than model research. Bridge through concrete mechanisms, and mention only the AI surface that those mechanisms actually support: tools, retrieval, evals, permissions, serving, observability, or rollout.
Before you answer, choose whether the project maps most directly to agent systems, retrieval systems, or model-serving infrastructure. Then decide whether the audience needs a risk comparison or a reusable mechanism first.
Solution guide
Say these five sentences:
- Shared property: trusted data access, tool execution, reliability, debugging, or launch discipline.
- One project boundary maps to one AI boundary.
- One metric or test maps to one AI eval or rollout signal.
- One new risk AI adds.
- 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.
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.