On this page
01Why projects decide offers
DSA gets you through the door. The project round decides your level.
In almost every loop — SDE-2, Senior, Staff, Hiring Manager, Bar Raiser — someone says the same sentence: "Walk me through a project you're proud of." It sounds like the easiest question in the loop. It's actually the one where the interviewer learns the most about you, because it's the only question where you pick the topic and they get to watch how deep you can go.
Most candidates lose this round for one of three reasons. None of them is "lack of skill".
They only know their slice
You fixed a race condition in one consumer. The interviewer asks "how does the message get to that consumer in the first place?" — and you go quiet. Knowing only your diff makes a real contribution sound small.
They have no structure
The story comes out in the order they remember it, not the order a listener needs it. Two minutes in, the interviewer still doesn't know what the system does, why it mattered, or which part was yours.
They get ambushed by counter-questions
"Why not Kafka exactly-once?" "What happens if Redis is down?" "How did you measure that 40%?" Each of these is predictable from what you said — if you'd prepared for it.
If you can't explain the system around your change, the interviewer assumes you couldn't have designed the change either.
02You own the story
The interviewer asks the questions. You decide what they're about.
A project explanation isn't a test you sit — it's something you design. You choose which details go in, in what order, and which ones you leave half-open so the interviewer follows them into an area where you're strong. The same project can sound like a junior task or a senior design depending only on how you frame it.
No system, no cause, no why, no number, no hook. The interviewer has to pull every detail out of you, and nothing invites a follow-up you're ready for.
Same work. But now the system, root cause, mechanism and impact are all there, and every highlighted phrase is a hook that leads to a question you've already prepared.
To keep things concrete, this playbook uses one made-up project throughout: "Fixed duplicate order-confirmation emails in a Kafka-based Notification Service using Redis idempotency keys." It's small on purpose — a bug fix, not a platform rewrite — because that's exactly the kind of project most people under-sell. Swap in your own project everywhere you see it.
03From bug fix to end-to-end
You don't need to have built the whole system. You need to understand it.
Most real work is a slice of something bigger: a bug, an enhancement, one module in a large product. That's fine — and it's honest to say so. What isn't fine is not knowing what's around your slice. Prepare in four concentric rings and label each one clearly so you never over-claim:
Four concentric rings of project knowledge
| Ring | Depth you need | Typical question that tests it |
|---|---|---|
| Owned Change | Line-by-line, every alternative considered | "Why SETNX and not a DB unique constraint?" |
| Contributed Component | Every class/API/table on your path | "What happens to the message after your check passes?" |
| Context System | Whiteboard-level: boxes, arrows, protocols | "Where does the event come from? Who else consumes it?" |
| Context Business | Users, cost, metrics, before/after | "How did you know this was worth fixing?" |
Saying "The consumer framework already existed — my part was making it idempotent, but here's how the whole pipeline works" scores higher than claiming you built everything. Clear ownership + broad understanding is exactly what senior engineers sound like. Over-claiming collapses on the third follow-up.
04Steering the interview with hooks
If you say this, they will ask that. Plan both.
Interviewers follow the most interesting noun in your last sentence. That makes the conversation predictable. A hook is a specific, slightly-open term you deliberately place in your pitch because you've prepared a strong answer for the question it triggers. Good hooks pull the interview toward your strengths; accidental hooks pull it toward your gaps.
Try it: click each highlighted hook in the pitch below to see the question it triggers and the prepared answer behind it.
← Click a hook to see the question it plants.
Rules for planting hooks
- Plant 4–6 hooks in your 2-minute pitch. Fewer and the interviewer picks topics at random; more and it sounds like buzzword soup.
- Every hook needs a prepared answer that's 60–90 seconds long and itself contains one deeper hook. This is how you chain two or three levels deep on your terms.
- Remove accidental hooks. If you say "we used Cassandra" but can't explain partition keys, either learn it or don't say it.
- Hook your tradeoffs. Phrases like "we chose X over Y" or "we deliberately didn't…" are the strongest hooks, because they invite a design discussion — the senior-level signal.
05The workflow, end to end
One project, one handbook, one rehearsed story.
Project-to-interview workflow
06Collect raw material first
AI can structure and explain. It cannot remember what you did.
The quality of the handbook is capped by the quality of what you feed in. Spend 60–90 minutes gathering this before you open any AI tool. Paste it as rough notes — it doesn't need to be tidy.
- 1The ask and the whyTicket / epic / PRD text, customer complaint, incident report, or the Slack thread that started it. What hurt, and for whom?
- 2Your actual diffsPR titles + descriptions, the class/method names you touched, key snippets (sanitized), review comments that changed your design.
- 3The surrounding systemArchitecture docs, READMEs, runbooks, config files, API contracts, table schemas — anything that explains the components around yours.
- 4NumbersBefore/after metrics, dashboards, load numbers, latency, error rate, cost, customer count, time saved. Even rough ranges ("~2%", "40+ customers") are fine — mark which are exact.
- 5Decisions and rejected optionsWhat else did you or the team consider? What did a reviewer push back on? Rejected options are where the best interview answers come from.
- 6What went wrongBugs you hit, rollbacks, wrong first hypotheses, production surprises. These become your war stories.
- 7Tests, rollout, monitoringHow you tested, feature flags, canary/rollout plan, alerts and dashboards you added.
- 8Target interviewCompany, level, round type (project deep dive, LLD, HLD, HM, behavioral). The handbook emphasis changes with this.
Never paste proprietary source code, customer names, credentials, internal URLs or unreleased product details into a public AI tool. Use your company's approved AI tooling, or sanitize first: rename internal services to generic roles ("Ingestion Service"), round numbers, and describe code in pseudocode. The sanitizer prompt in Part III helps. In the interview itself, the same rule applies — describe patterns, not secrets.
07The 18-section handbook blueprint
Every project handbook follows the same skeleton, so every story has the same strong shape.
The order matters: the first six sections are what you say; the rest are what you defend with. Sections marked Must are non-negotiable for any project; Depth sections scale with how technical your round is.
Elevator pitch ladder
30-second, 2-minute and 5-minute versions, written as spoken first-person text with hooks marked.
Problem context & before/after
Who was hurting, how badly, why now, what the world looked like before and after. Include a before/after diagram.
Glossary & domain primer
Every term you'll use, explained in one line, plus the 3–5 domain concepts an outsider needs to follow the story.
Exact scope — owned vs context
The honesty matrix: what you built, what you contributed to, what existed. Pre-written "I vs we" phrasing.
System architecture (big picture)
Every component, arrow and protocol in the surrounding system. Your piece highlighted. Drawable in 60 seconds.
End-to-end flow + sequence diagrams
Happy path and at least one failure path, request by request. Animated sequence diagram with numbered steps.
Component deep dive (your area)
Classes, methods, algorithms, key code paths in pseudocode, config knobs, with "why it's written this way" notes.
Data model, storage & APIs
Schemas, keys, indexes, TTLs, retention, message formats, API contracts — and why each was shaped that way.
Design decisions & tradeoffs
Decision → alternatives → why chosen → cost accepted → when you'd revisit. The single highest-signal section.
Failure modes, scale & concurrency
What breaks, what happens at 10× load, race conditions, retries, idempotency, back-pressure, consistency model.
Testing, rollout & observability
Test strategy, flags, canary, rollback plan, metrics, alerts, dashboards, on-call runbook.
Impact & metrics
Before/after numbers, how each was measured, and which are exact vs estimated. Metric cards.
War stories (STAR-L)
2–3 stories: hardest bug, a disagreement, a mistake. Situation, Task, Action, Result, Learning.
Steering map (hooks → questions)
Every hook in your pitch, the question it triggers, the prepared answer and the next-level hook.
Interview Q&A — 7 levels
30+ questions from clarifying to trap to behavioral, each with spoken answer, why they ask, follow-up and trap.
Retrospective & what's next
What you'd do differently, known limitations, next version of the design, how it scales to the company's problem.
One-liners & soundbites
8–12 memorable sentences you can drop anywhere. The lines the interviewer writes down.
Tech stack & cheat sheet
Every technology with "what it does here" and "why this one". Plus a 1-screen revision sheet for the morning of the interview.
A good handbook is 40–120 KB of HTML: long enough to hold every answer, organized so you can find any one of them in five seconds. If you're preparing a deep-dive round, depth wins. If it's one bullet among many on your resume, sections 01–06, 09, 12, 14 and 15 are the minimum.
08Pitch engineering
One story, three lengths, same skeleton.
Every version of the pitch follows the same seven beats. The 30-second version gives each beat one clause; the 5-minute version gives each one a paragraph and a diagram. Because the skeleton is the same, you can stretch or shrink depending on how much time the interviewer gives you.
"I worked on the Notification Service in our e-commerce platform. Customers were getting duplicate order-confirmation emails — about 2% of sends — because our Kafka pipeline is at-least-once. I traced it to consumer rebalances and made the consumer idempotent using Redis keys with a TTL. Duplicates dropped to near zero with no added latency, and the pattern was reused by two other teams."
[Context] "Our checkout publishes an OrderPlaced event to Kafka, and a Notification Service consumes it to send confirmation emails — around 1.2 million a day. [Problem] Support was seeing complaints about duplicate emails; when I measured, about 2% of orders got two or more. [Role] I owned the investigation and the fix inside the Notification Service; the Kafka setup and email provider integration already existed. [Approach] I correlated duplicates with consumer-group rebalances during deploys — offsets weren't committed before partitions moved, so another instance re-processed them. Rather than chase exactly-once, I made the consumer idempotent: before sending, it does a Redis SET-NX on a key derived from orderId and template, with a 24-hour TTL. [Hard part] The tricky bit was what happens if the send fails after we've claimed the key — so the key has a state and failed sends release it. [Impact] Duplicates went from ~2% to under 0.01%, p99 latency added was about 1ms, and two other teams adopted the same helper. [Hook] The interesting decision was choosing to fail open when Redis is down — happy to go into why."
- Business context (30s) — what the platform does, scale, who uses notifications.
- Architecture (60s) — draw §05: Checkout → Order Service → Kafka → Notification consumers → Template service → Email provider.
- Problem & diagnosis (60s) — symptoms, how you measured 2%, the wrong first hypothesis (provider retries), the real cause (rebalance before offset commit).
- Options considered (45s) — Kafka exactly-once, DB unique constraint, Redis idempotency key, provider-side dedup. Why Redis won.
- Design (60s) — draw §06 sequence diagram: key format, SETNX + TTL, claim/sent state, release on failure.
- Edge cases (30s) — Redis down → fail open; TTL vs late redelivery; hot keys.
- Rollout & impact (30s) — flag, shadow mode counting would-be duplicates, then enforce; metrics.
- Reflection (15s) — what you'd do differently; open the floor with a hook.
The problem was [symptom + who it hurt + number].
My part was [exact scope]; [what already existed / what the team did].
I [diagnosed / designed / built] [approach], choosing [X] over [Y] because [reason].
The hard part was [edge case / constraint], which I handled by [mechanism].
As a result [metric before → after], and [secondary impact].
The most interesting part was [hook] — happy to go deeper."
Time yourself. Most people's "2-minute" pitch is 4 minutes long and front-loads context. If the interviewer doesn't know what you did by the 45-second mark, cut context.
09The scope honesty matrix
Pre-decide your "I" and "we" so you never have to improvise them.
Interviewers are trained to probe "what did you do?". Ambiguity reads as over-claiming. Build this table for every project and rehearse the phrasing in the last column.
| Piece of work | Label | How you say it |
|---|---|---|
| Root-cause analysis of duplicates | Owned | "I traced it to rebalances by correlating duplicate timestamps with deploy events." |
| Idempotency helper + state handling | Owned | "I designed and built the helper, including the failure-release path." |
| Fail-open decision | Contributed | "I proposed it; we agreed on it with the team lead and product after looking at the tradeoff." |
| Kafka cluster, consumer framework | Context | "That already existed — but here's how it works and why it was at-least-once." |
| Email provider integration | Context | "Another team owns it; I worked against its API contract." |
Interviewer can't tell if you led it or watched it. Expect "what exactly did you do?" — now you're on the back foot.
Three ownership levels in one sentence. Honest, specific, and it still sounds like leadership.
10Diagrams that win interviews
If you can draw it from memory, you understand it. If you can't, you don't — yet.
Every handbook needs a small set of diagrams, each answering one question an interviewer will ask. Generate them as inline SVG in the handbook, then practice redrawing each one on a whiteboard in under 60 seconds.
| Diagram | Answers the question | Required? |
|---|---|---|
| System architecture | "What are the moving parts and where are you?" | Must |
| Before / after | "What changed because of your work?" | Must |
| Sequence diagram (happy + failure) | "Walk me through one request." | Must |
| State machine | "What states can this entity be in? What about failures?" | If stateful |
| Decision tree / flowchart | "How does the logic decide X?" | If logic-heavy |
| Data model / ERD | "How is it stored? What are the keys?" | If data-heavy |
| Deployment / infra | "How is it deployed, scaled, observed?" | If infra-heavy |
| Timeline | "How did the project unfold? What went wrong?" | For HM rounds |
Example: animated sequence diagram (happy path + redelivery)
This is the standard to aim for: numbered steps, request vs response arrows, the failure moment highlighted, and a replay button so you can watch the flow while rehearsing your narration.
Sequence: duplicate delivery suppressed by idempotency key
Example: state machine for a non-obvious edge case
The sequence diagram shows the happy path. A state diagram is how you answer the inevitable "but what if the send fails after you've set the key?"
Idempotency key state machine
For each diagram in your handbook: close the file, set a 60-second timer, and redraw it on paper. Anything you couldn't reproduce is something you'll stumble on when explaining. Ask AI to simplify the diagram until you can draw it — the interviewer wants the shape, not every box.
11Tradeoffs & "why not X?"
The difference between "I implemented" and "I designed" is one table.
For every significant decision, fill this in. If you genuinely didn't make the decision, still fill it in — then say "the team chose X; here's my understanding of why, and here's where I'd push back."
| Decision | Alternatives | Why chosen | Cost accepted | Revisit when |
|---|---|---|---|---|
| Consumer-side idempotency in Redis | Kafka exactly-once (EOS); DB unique constraint; provider dedup header | EOS doesn't cover the external email side-effect; DB adds write latency on hot path; provider dedup not supported | New dependency on Redis on the hot path | If provider adds idempotency keys natively |
| Fail open if Redis is down | Fail closed (drop / retry later) | A rare duplicate is far cheaper than a missing order confirmation | Duplicates possible during a Redis outage | For payment/OTP messages — there we'd fail closed |
| 24h TTL on sent keys | No TTL; 1h; 7d | Covers max observed redelivery lag (~40 min) with big margin; bounded memory (~1.2M keys) | Redelivery after 24h would duplicate | If retention / replay jobs change |
"We chose X over Y because Z, and we accepted W as the cost." Every tradeoff answer that includes the cost you accepted sounds two levels more senior than one that doesn't.
12The question ladder — 7 levels deep
Interviewers drill. Prepare at every depth, not just the top.
Questions about a project come in predictable levels. A good handbook has at least 4 questions per level — 30+ total — each with a spoken answer, why they're asking, the follow-up you'll get next, and the trap to avoid.
Clarifying — "what is it?"
Checks that you can explain the system to an outsider.
Design — "how does it work?"
Architecture, data flow, components, APIs.
Deep dive — "why exactly like this?"
Algorithms, data structures, key formats, concurrency, code-level detail.
Counter / trap — "why not X?"
Challenges your choices, often with a "better" alternative to see if you defend or fold.
What-if / scale — "what breaks?"
10× load, component failure, multi-region, data growth.
Behavioral — "how did you work?"
Conflict, ambiguity, mistakes, influence, ownership.
Reflection — "what now?"
Retrospective, limitations, how you'd redo it, how it applies to their company.
What a complete answer entry looks like
Each Q&A in your handbook should follow this format. Expand one to see it:
L4Why not just enable Kafka exactly-once semantics?
Spoken answer: "Kafka's exactly-once covers reading from and writing to Kafka within a transaction — it doesn't cover side-effects outside Kafka, like calling an email provider over HTTP. The send can succeed and the consumer can still crash before committing, so we'd still re-send. The only place to guarantee 'once' for an external side-effect is to make the side-effect itself idempotent, which is what the key does. EOS would also have added transactional overhead on every message for no real gain here."
Why they ask: To check if you understand delivery semantics, or just picked the first tool that worked.
Next follow-up: "So how would you get exactly-once end-to-end?" → outbox pattern / idempotent receivers / provider-side idempotency keys.
Trap to avoid: Saying "EOS is slow" without explaining why it doesn't solve the problem. Performance is a secondary argument; correctness is the primary one.
L5What happens if Redis is down?
Spoken answer: "We fail open: if the Redis call times out (we set 50ms), we send the email anyway and emit a metric. The reasoning is asymmetric cost — a missing order confirmation causes support tickets and anxiety, an occasional duplicate is an annoyance. We alert if the fail-open rate goes above a threshold. For an OTP or payment notification I'd flip that and fail closed with a retry queue."
Why they ask: Every new dependency is a new failure mode. They want to see you thought about it before they asked.
Next follow-up: "How is Redis deployed? What about failover losing keys?" → replica promotion can lose recent writes → small duplicate window, acceptable by the same cost logic.
Trap to avoid: "Redis never goes down." Never claim a dependency is perfectly reliable.
L6Tell me about a time something went wrong on this project.
Spoken answer (STAR-L): "My first hypothesis was wrong — I spent two days assuming the provider was retrying on timeouts. When I finally correlated duplicate timestamps with our deploy log, 90% clustered within 2 minutes of a rollout, which pointed to rebalances. The learning I took was: correlate with change events first before diving into a component. I now do that as step one in every incident."
Why they ask: Self-awareness and learning speed, not perfection.
Trap to avoid: A "mistake" that's actually a humble-brag, or blaming someone else.
Universal question bank — every project must answer these
Context & scope
- What problem did this solve, and for whom?
- How did you know it was a problem? What data?
- What exactly was your contribution?
- Who else was involved and what did they do?
- How long did it take? Why that long?
- What would have happened if no one fixed it?
Design & depth
- Draw the architecture. Where is your part?
- Walk me through one request end to end.
- What alternatives did you consider?
- What's the data model? Why those keys?
- Which part was hardest technically?
- Show me the core logic in pseudocode.
Failure & scale
- What happens when dependency X fails?
- What breaks at 10× traffic? 100×?
- Any race conditions? How did you handle them?
- How is it tested? What isn't tested?
- How did you roll it out safely?
- How would you know it's broken in production?
Impact & reflection
- How did you measure impact? Before vs after?
- What would you do differently now?
- Did anyone disagree? How was it resolved?
- What did you learn that you still use?
- What's the next improvement you'd make?
- How would you build this at our company?
13The counter-question playbook
You will get a question you didn't prepare. Prepare for that too.
Handling an unexpected question
| Trap pattern | What they're testing | How to respond |
|---|---|---|
| "Wouldn't X have been better?" | Do you fold or reason? | Acknowledge X's strength, state the constraint that ruled it out, name when X would be right. |
| "That number seems high." | Did you really measure it? | Explain how it was measured, the baseline, and the confidence ("±, from 2 weeks of logs"). |
| "So your manager designed it?" | Ownership | Restate the scope matrix calmly. Don't inflate, don't shrink. |
| "What if I told you this fails when…?" | Composure + debugging | Take it seriously, think aloud, agree if right: "Good catch — here's how I'd fix it." |
| Long silence after your answer | Do you over-talk? | Stop. Ask: "Want me to go deeper on any part?" |
| Question about a component you didn't touch | Breadth | Answer from Ring 3 knowledge, then: "I didn't own that part, but here's how it interacts with mine." |
"I didn't work on that layer directly, so I don't want to guess at the specifics. My understanding is [principle-level answer]. If I needed to confirm, I'd check [where]." — This is a positive signal. Bluffing, then getting caught, is the single fastest way to fail a project round.
14STAR-L war stories
The technical round and the behavioral round use the same project.
Pull 2–3 stories from every project so you can answer behavioral questions with the same material. Add an L (Learning) to STAR — it's what turns a story into a signal of growth.
| Story type | Behavioral questions it answers |
|---|---|
| Hardest technical problem | Biggest challenge · deep debugging · going beyond scope |
| Disagreement | Conflict · influence without authority · disagree and commit |
| Mistake or wrong hypothesis | Failure · learning · self-awareness |
| Ambiguity / tight deadline | Prioritization · bias for action · tradeoffs under pressure |
| Helping others | Mentoring · reusable work · raising the bar ("two teams adopted it") |
15The Master Prompt
Copy it, fill the brackets, paste your raw material underneath.
This prompt turns any capable LLM (or coding agent with file access) into a principal engineer + interview coach + technical writer. It runs in two phases on purpose: first an outline and steering map you can correct, then the full HTML handbook. Skipping phase 1 is the most common reason AI output ends up generic.
- Replace every
[[…]]in the INPUTS block. Leave "unknown" rather than deleting a field. - Paste raw material (§06) at the end, after
=== RAW MATERIAL ===. Messy is fine; sanitized is mandatory. - Use the strongest model available, ideally one with a large context window. If it truncates, reply
continue from <section id>. - If you're using a coding agent with repo access, add: "Explore the codebase to trace the flow yourself; cite file paths."
ROLE You are three people at once: 1. A principal engineer who has built and operated systems like this one. 2. A senior interview coach who has run 500+ project deep-dive rounds at top tech companies. 3. A technical writer who produces Confluence-quality, visually excellent documentation. GOAL Help me build a single, self-contained HTML "Project Interview Handbook" for ONE project on my resume, so that I can (a) explain it end-to-end, (b) defend every decision, (c) answer every follow-up, and (d) deliberately steer the interview toward my strengths. INPUTS - Project name: [[project name]] - Company / domain (sanitized ok): [[e.g. "large e-commerce platform"]] - My role and level at the time: [[e.g. SDE-2, backend]] - Duration and team size: [[e.g. 6 weeks, team of 5]] - Resume bullet(s) for this project: [[paste exact text]] - What I personally did (OWNED): [[bugs, features, PRs, designs]] - What I contributed to (CONTRIBUTED): [[...]] - What already existed / others did (CONTEXT): [[...]] - Known metrics (mark exact vs estimated): [[...]] - Target company, level and round type: [[e.g. Senior SWE, project deep dive + HM]] - Topics I feel weak on: [[e.g. Kafka internals, scaling numbers]] - Confidentiality: [[genericize internal names? yes/no]] NON-NEGOTIABLE RULES R1 TRUTH FIRST. Never invent metrics, dates, names or claims about what I did. If something is missing, write [[TODO: verify — suggested question to ask myself]]. Anything you infer about the surrounding system must be labeled "Inferred" so I can verify it. R2 OWNERSHIP LABELS. Tag every component/decision as OWNED, CONTRIBUTED or CONTEXT. Write my answers in first person with precise "I" vs "we". R3 END-TO-END DEPTH. Even if I only fixed one bug, explain the whole system around it in four rings: my change -> my component -> the full system -> the business impact. R4 SPOKEN, NOT WRITTEN. Pitches and answers must sound natural when said aloud: short sentences, no bullet-speak, 60-120 words per answer unless noted. R5 STEERING. Deliberately plant 4-6 "hooks" (specific terms, tradeoffs, numbers) in the pitch. For each hook, prepare the question it triggers, the answer, and the next-level hook. R6 TEACH THE FUNDAMENTALS. For every technology or concept I mention (e.g. Kafka offsets, Redis SETNX, B-tree indexes, consistent hashing), add a short "Fundamentals you must know" box with the 3-5 facts an interviewer will expect me to know. R7 NO SECRETS. If confidentiality = yes, replace internal service/team/customer names with generic role names and keep a mapping table only at the very end, marked PRIVATE. PHASE 1 — OUTLINE (reply with this first, then STOP and wait for me) 1. Up to 8 clarifying questions where missing info would materially weaken the handbook. 2. A one-paragraph story arc (context -> problem -> my role -> approach -> hard part -> impact). 3. The four-ring map (my change / component / system / business) in bullet form. 4. Draft steering map: 4-6 hooks -> predicted question -> 1-line answer gist. 5. The list of diagrams you will draw and what each one answers. 6. A list of every [[TODO]] you currently have. PHASE 2 — FULL HANDBOOK (only after I reply "go" or answer the questions) Produce ONE complete HTML file with these sections, in this order, each with an id and number: §01 Elevator Pitch Ladder - 30-second, 2-minute and 5-minute versions in tabs, written as spoken quotes. - In the 2-minute version, visibly mark beats [Context][Problem][Role][Approach][Hard part] [Impact][Hook] and highlight hooks (clicking a hook scrolls to its steering-map entry). §02 Problem Context - Who hurt, how much, why now. Before vs After comparison (two-column card + SVG diagram). §03 Glossary & Domain Primer - Table of every term (term | one-line meaning | why it matters in this project). - "Fundamentals you must know" boxes per key technology (rule R6). §04 Exact Scope — Ownership Matrix - Table: piece of work | OWNED/CONTRIBUTED/CONTEXT | exact sentence I say in the interview. §05 System Architecture - Inline SVG of the full system; my component visually highlighted; protocols on arrows. - Component table: name | responsibility | tech | owned by. - "Draw this in 60 seconds" simplified version. §06 End-to-End Flow - Numbered step list of the happy path. - ANIMATED SVG sequence diagram (happy path) with replay button and numbered messages. - A second sequence diagram for the most important failure / edge path. §07 Component Deep Dive (my area) - Classes/modules/functions involved, responsibilities, key logic as pseudocode blocks. - State machine or decision tree SVG if there is any stateful or branching logic. - Config knobs and defaults with the reasoning. §08 Data Model, Storage & APIs - Schemas / keys / indexes / TTLs / message formats / API contracts with "why shaped this way". §09 Design Decisions & Tradeoffs - Table: decision | alternatives | why chosen | cost accepted | when I'd revisit. - At least 5 decisions. Then one "Why not X?" card per serious alternative. §10 Failure Modes, Scale & Concurrency - Table: failure | detection | behavior | mitigation. - "At 10x / 100x" section with what breaks first and how I'd fix it. - Race conditions, idempotency, retries, ordering, consistency model. §11 Testing, Rollout & Observability - Test pyramid for this change, rollout plan (flags/canary/shadow), metrics, alerts, runbook. §12 Impact & Metrics - Metric cards (before -> after), each with "how measured" and EXACT/ESTIMATED badge. §13 War Stories (STAR-L) - 3 stories: hardest technical problem, disagreement, mistake/wrong hypothesis. - Each mapped to the behavioral questions it answers. §14 Steering Map - Table: hook phrase | triggered question | prepared answer (60-90s) | next-level hook. - Also list "accidental hooks" I must avoid or prepare for. §15 Interview Q&A — 7 Levels (minimum 32 questions) - L1 Clarifying (4+), L2 Design (5+), L3 Deep dive (6+), L4 Counter/trap (6+), L5 What-if/scale (5+), L6 Behavioral (4+), L7 Reflection (2+). - Each as a collapsible item with: level badge, spoken answer, "Why they ask", "Likely follow-up", "Trap to avoid". Add a filter bar to show one level at a time. §16 Retrospective & What's Next - What I'd do differently, known limitations, v2 design, how I'd apply this at the target company. §17 One-Liners & Soundbites - 10-12 memorable, quotable sentences. §18 Tech Stack & Morning-of Cheat Sheet - Table: technology | what it does here | why this one | alternative. - A one-screen revision card: key numbers, key names, the 3 diagrams, top 5 hooks. Appendix: Open TODOs (all [[TODO]] items collected), and PRIVATE name mapping if applicable. DESIGN SPEC (follow exactly) Theme: "editorial field guide" — warm paper background, dark hero, serif body, grotesk headings. Fonts (Google Fonts): Space Grotesk (headings/UI), Source Serif 4 (body), IBM Plex Mono (code). CSS tokens: --paper:#F4F5F0; --paper-2:#ECEEE7; --ink:#181C22; --ink-soft:#565F6B; --line:#D8DBD1; --panel:#171B22; --panel-text:#E9EBEE; --red:#C7454A; --red-bg:#F7E4E3; --amber:#C8862B; --amber-bg:#F6E9D3; --green:#2F8F63; --green-bg:#DDEFE4; --blue:#2C5FD1; --blue-bg:#DFE6F9; --violet:#6B4FC8; --violet-bg:#E9E4F8; --radius:10px; Layout: - Sticky top nav with red/amber/green "signal" dots + project name. - Dark hero: eyebrow ("Interview Handbook / <domain>"), large H1 with one accent-colored phrase, a dek paragraph, byline chips (role, duration, stack), and 4 stat tiles (key metrics). - Two-column body: sticky left TOC (scroll-spy highlights the active section) + article max 800px. - Section headings "NN Title" with a muted number; a one-line italic-ish section intro under each. Components to use: callouts (blue=info, green=tip, amber=warning, red=danger), bad-vs-good "autopsy" comparison, ownership tags (OWNED green, CONTRIBUTED blue, CONTEXT grey), metric cards, tables in rounded white containers, dark "spoken pitch" quote boxes, collapsible Q&A with level badges, tabs, timeline, cheat-sheet grid, copy buttons on code/pseudocode blocks. Diagrams: - Inline SVG only (no images, no Mermaid, no external JS libraries). - Rounded rects, 1.3-1.6px strokes, token colors, Space Grotesk labels, arrow markers. - My owned component always green; failure paths red; responses dashed. - Each diagram in a white figure card with a caption that says what to say while drawing it. - Sequence diagrams animate message-by-message via CSS (staggered animation-delay) with a "Replay" button. Flow arrows may use a subtle moving dash animation. Interactivity (vanilla JS, inline, no dependencies): scroll-spy TOC, reading-progress bar, tabs, Q&A level filter, copy-to-clipboard, replay buttons, hook click -> scroll to steering map, reveal-on-scroll. Quality: - Responsive (TOC hides under 980px), print stylesheet, prefers-reduced-motion respected, semantic HTML, accessible SVG titles, no lorem ipsum, no "...and so on", no truncation. - If output is too long for one reply, stop at a section boundary and say "Reply 'continue' for §NN onward" — then continue in the same file structure. === RAW MATERIAL === [[paste tickets, PR descriptions, design doc excerpts, code snippets (sanitized), configs, metrics, incident notes, review comments — anything you have]]
16Follow-up prompts
The first draft is the start. These turn it into something you can defend.
I'm attaching an older project-prep document I wrote. Keep ALL of its factual content (names, numbers, flows, decisions) — do not drop anything. Re-structure and re-design it into the 18-section Project Interview Handbook format and design spec from the Master Prompt. Then: 1. List every section that was missing or thin in the original, and fill it (mark inferred content). 2. Convert ASCII/text diagrams into proper inline SVG; add an animated sequence diagram. 3. Upgrade the Q&A to the 7-level format with "why they ask / follow-up / trap" for each. 4. Add a steering map built from the hooks already present in my pitch. 5. End with a diff summary: what was kept, what was added, what needs my verification.
Section [[§NN name]] is too shallow for a [[Senior/Staff]] deep-dive round. Go 2 levels deeper: add the internals an expert interviewer would probe, the fundamentals I must know, one more diagram if it helps, and 5 new L3-L5 questions specific to this section. Keep the same HTML structure and design; return only the replacement section.
Act as a tough but fair [[company]] interviewer running a 45-minute project deep-dive for a [[level]] role. Use the handbook above only as your private notes — never reveal answers. Rules: - Start with "Walk me through the project." Then ask ONE question at a time and wait. - Follow the most interesting thing in my last answer (like a real interviewer would). - Drill at least 3 levels deep on one topic. Include at least two "why not X?" challenges, one "what if X fails?", one scale question, and one behavioral question. - If I bluff, call it out politely and push once more. After 12-15 questions, or when I say "end", give me a scorecard: clarity, depth, ownership, tradeoff reasoning, composure (1-5 each, with evidence), the 3 weakest answers rewritten as model answers, and the 5 topics to study next.
Read my 2-minute pitch below. For EVERY noun, number, technology and claim in it, list the
toughest follow-up question an interviewer could ask. Mark each as:
PREPARED (the handbook already answers it), WEAK (partially), or MISSING.
For WEAK and MISSING ones, write the answer I should give. Finally, tell me which phrases are
"accidental hooks" I should remove or rephrase.
Pitch: [[paste]]
Here is my pitch as I actually say it (transcribed). Time it at 150 words/minute. Rewrite it to hit [[30s / 2min]] exactly, keep my voice, make my ownership clear by the 45-second mark, and keep 4-6 hooks. Show the hooks in [brackets] and explain what each one baits. Transcript: [[paste]]
From this handbook, write 3 alternative resume bullets for this project using the "Accomplished X, measured by Y, by doing Z" formula. Max 2 lines each, lead with a strong verb, include one technology and one number, no JD-speak. For each bullet, list the 3 questions it will trigger and confirm the handbook answers them.
Rewrite the text below so it is safe to share outside my company: replace internal product,
service, team, customer and person names with generic role names (e.g. "Ingestion Service",
"Enterprise Customer A"); remove URLs, hostnames, IPs, credentials, ticket IDs; round exact
business numbers to safe ranges; convert code to language-neutral pseudocode.
Return the sanitized text plus a mapping table I keep privately.
Text: [[paste]]
I worked on [[feature / bug / PR]] in this repository. Explore the codebase and:
1. Find the entry points and trace the full request/data flow through my change, end to end.
2. List every class/function on the path with file paths and one-line responsibilities.
3. Identify the upstream producers and downstream consumers of the data I touched.
4. Note config flags, retries, error handling, and tests covering this path.
5. Produce sanitized raw material I can paste into the Master Prompt (no secrets, no internal URLs).
I contributed a small piece ([[my change]]) to a large system ([[system]]). Teach me the system as if I'm about to be interviewed on it tomorrow: - the 5-minute mental model, the main components and data flow, the 3 hardest problems it solves, - the fundamentals I must know for each technology used, - 15 questions an interviewer might ask about parts I did NOT build, with answers, - and the exact sentences I should use to be honest about scope while showing understanding.
17Design spec for the generated HTML
Consistent design across all your handbooks makes them easier to revise — and easier to share.
The Master Prompt already embeds this spec. It's repeated here visually so you can check the AI's output against it — and so mentors can keep every mentee's handbooks consistent.
Palette
Typography
Space Grotesk — headings
Source Serif 4 — body text you read
IBM Plex Mono — code & keys
| Element | Rule |
|---|---|
| Color meaning | Green = what you own / good outcome. Red = failure path / before state. Amber = hooks, warnings. Blue = info / context. Violet = deep internals. Never use color only for decoration. |
| Diagrams | Inline SVG, accessible <title>, caption that tells you what to say while drawing it. Owned component always green-outlined. |
| Animation | Purposeful only: sequence diagrams step in, flow arrows move, sections reveal. Always a replay button; always disabled under prefers-reduced-motion. |
| Spoken text | Pitches and answers are styled as quotes so you can tell at a glance what's "say this" vs "know this". |
| Navigation | Sticky scroll-spy TOC, numbered sections, every section has an id so you can deep-link mentees to it. |
| Self-contained | One .html file, no build step, opens offline (except Google Fonts), prints cleanly to PDF. |
18The quality rubric
Score your handbook before you trust it. Your ticks are saved in this browser.
19The 7-day rehearsal plan
Per project. Roughly 60–90 minutes a day.
Day 1Collect & outline
Gather raw material (§06), sanitize it, run Master Prompt Phase 1. Answer the clarifying questions honestly.
Day 2Generate & verify
Run Phase 2. Read every line. Resolve every [[TODO]] and verify every "Inferred" claim with docs, code or a colleague.
Day 3Learn the rings
Study §03 fundamentals and §05 architecture. Redraw all diagrams from memory until each takes under 60 seconds.
Day 4Pitch ladder
Record yourself giving the 30s and 2-min pitch. Run the Pitch Tightener prompt on the transcript. Repeat until it flows.
Day 5Defend
Run the Counter-question Stress Test. Rehearse every L4 and L5 answer out loud. Fill MISSING answers into the handbook.
Day 6Mock interview
Two AI mock interviews with different "interviewer personalities" (friendly HM, skeptical Staff engineer). Fix the 3 weakest answers each time.
Day 7Human mock + cheat sheet
Do one mock with a friend or mentor. Then reduce everything to the §18 one-screen cheat sheet you'll read the morning of the interview.
20For mentors: reviewing a mentee's handbook
If you're sharing this guide with people you coach, this is your review checklist.
Run the session like this
- Minute 0–5: they pitch with the handbook closed. You only listen.
- 5–25: you drill one hook 3 levels deep, then pick a topic they didn't hook.
- 25–35: they whiteboard the architecture and sequence diagram from memory.
- 35–45: one behavioral question from the same project.
- 45–60: walk through the rubric together; agree on 3 fixes.
Signals you're looking for
- Ownership is crisp and consistent across answers.
- They reason through unknowns instead of bluffing.
- Tradeoff answers name the cost accepted.
- Numbers survive "how did you measure that?"
- They stop talking when the answer is done.
Red flags to send back
- ✕AI voice, not their voiceAnswers they can't say naturally, or words they can't define. If they can't explain a term in the handbook, it shouldn't be there.
- ✕Invented or unverified numbersA metric with no "how measured" note. This is the fastest way to lose an interviewer's trust.
- ✕Only Ring 1Deep on their diff, blank on the system around it. Send them to prompt ⑨.
- ✕Only happy pathNo failure modes, no "what if X is down", no scale story.
- ✕Confidential contentReal internal names, customer names, URLs or code in a document they might share.
21FAQ
I only fixed a few bugs. Is that really a "project"?
Yes — if you can explain the system the bug lived in, why it happened, how you found it, why your fix was the right one, and what it changed. A well-understood bug fix beats a poorly-understood "platform rewrite" every time. Use the four rings (§03) to build the context around it.
Is it honest to prepare deeply on parts I didn't build?
Completely — as long as you label them honestly in the interview. Understanding your surrounding system is part of being a good engineer. The dishonest version is claiming you built it. The ownership matrix (§09) exists to keep you on the right side of that line.
Can I put a project on my resume I haven't worked on?
Don't claim work you didn't do. But you can (a) build it yourself as a personal project and present it as such, or (b) present a part you genuinely contributed to, with honest scope. Either way, this playbook works the same: prepare it end-to-end, label ownership truthfully. Interviewers detect fabricated projects quickly, usually at the L3 level.
Which AI model should I use?
The strongest one you have access to, ideally with a large context window, and one your company allows for anything work-derived. Coding agents with repository access (and permission to use them) produce the most accurate Ring 1–2 detail because they can trace the actual code with prompt ⑧.
The AI made up details. What do I do?
That's why rule R1 forces [[TODO]] and "Inferred" labels. Treat the first output as a draft you must verify. Delete anything you can't confirm. A smaller true handbook is worth far more than a bigger fictional one.
How many projects should I prepare like this?
Every project on your resume should survive at least L1–L3. Pick your top 2 for the full 18-section treatment — those are the ones you'll steer interviewers toward.
Should I memorize the answers?
Memorize the structure and the key facts (numbers, names, decisions) — not the sentences. Recited answers sound recited. Rehearse out loud until the content is automatic and the wording is fresh each time.
→Next steps
Fix the resume line first, then build the handbook that defends it.
The Resume Building Guide
Write bullets that read like your work, not the JD — using the X-Y-Z formula. Every bullet becomes the input to this playbook.
Copy the Master Prompt
Pick your strongest project, collect the raw material, and generate your first handbook today.