Walk Through a System You Built: Key Technical Decisions and the Hardest Part

In a 30-minute software engineer phone screen that is mostly behavioral and experience questions, the interviewer asks you to talk about something technical you implemented at a previous company, including the technical decisions you made, and then asks what the hardest part of it was. ### Clarifying Questions - Should the example be the most complex project, or the one most relevant to this role? - Is a team project acceptable if you make clear which parts were yours? - How deep should the answer go: architecture and trade-offs, or down to code-level details? ### Part 1 — What you implemented and the decisions you made Describe a technical thing you implemented at a previous company. Explain what it did, why it was needed, and the technical decisions you made along the way. ```hint Decisions, not a feature list For each major decision, be ready to name the alternative you rejected and the constraint that ruled it out. ``` #### What This Part Should Cover - The problem, its constraints (scale, latency, deadlines, existing systems) and the candidate's own role - A short architecture overview a listener can follow without a diagram - Two or three key decisions, with the alternatives considered and the trade-offs accepted - The outcome, measured where possible ### Part 2 — The hardest part What was the hardest part of that work? ```hint Hard for a specific reason Pick the difficulty that actually cost the most effort or carried the most risk, and be ready to explain why it was hard and how you got through it. ``` #### What This Part Should Cover - A specific difficulty, technical or organizational, rather than general time pressure - What the candidate tried, including approaches that did not work - How it was resolved, and what the candidate learned or would do differently ### What a Strong Answer Covers - Clear ownership: what the candidate personally designed, built or decided - Decisions explained through constraints and trade-offs rather than preference - Technical depth that holds up when the interviewer probes any component - Honest reflection, including what did not go well - A coherent story that fits the time available in a short screen ### Follow-up Questions - If you rebuilt it today, which decision would you change, and why? - How did you know it was working in production, and what did you measure? - What would break first if the load grew tenfold? - Who disagreed with one of your decisions, and how was it settled?