Architecture of a Project You're Proud Of
Prompt
Walk me through a system you owned end to end. Pick something real — the parts you designed, the calls you made — and tell me how it fits together.
How this round runs
I'll follow your story and drill: I'll pick one component and ask how it actually works inside, then push on which decisions were yours and what you'd change now. Pick a project where you owned the hard part, not one you watched from the next desk over.
Model answer
This round is won or lost on project selection before you say anything technical. Pick a system where you owned a genuinely hard decision — the data model under load, the consistency boundary, the failure mode that kept you up — not a CRUD screen or a migration someone else drove. Lead with one sentence on what it had to do and the constraint that made it hard (latency budget, scale, a correctness guarantee), then sketch the components and how data flows between them.
The drill lands when the interviewer picks one box and asks how it works inside. Be ready to go four or five levels down on your own component: not "we used a cache" but which cache, the key scheme, eviction policy, what happens on a miss, how you keep it from serving stale data, and why you sized it the way you did. Keep ownership in the first person — say "I chose", "I traded", not the team-history "we" that makes it impossible to tell what was actually your call. When the zoom-in comes, the strong move is to volunteer the alternative you rejected and the property you gave up, then end on a specific thing you'd redesign now — an architectural change, not "better docs" or "more tests".
- Chose a system where they owned a hard design decision, not a CRUD feature or someone else's migration
- Sketched the components and data flow before diving, so the zoom-in had a map
- Went four to five levels deep on their own component when one box was picked apart
- Kept ownership in first person — 'I chose', 'I traded' — so their decision was isolable
- Named a concrete architectural change they'd make now, not a process wish
- Pick one box — 'how does that component actually work internally?' → the strong answer keeps descending: data structure, key scheme, eviction, miss path, staleness, sizing rationale
- 'What did you consider here and reject?' → a named alternative and the property it would have cost (consistency, latency, cost, operational load)
- 'If you rebuilt it today, what changes?' → a specific architectural counterfactual with the reason, not 'more docs'