Teaching the interview, not the answer

Context

Career switchers coming out of a nonprofit software engineering school face a brutal asymmetry: system design interviews assume years of production scar tissue they haven’t had time to earn. I taught software development there, and kept coaching students and alumni through the interviews standing between them and their first (and next) engineering roles.

Problem

Students knew the vocabulary (load balancers, caches, queues) but froze when handed an open prompt. Nerves drove the session instead of structure. The instinct was to memorize canonical architectures, which collapses the moment an interviewer steps half a degree off the rehearsed path.

The decision

Coach a framework, not answers. Open every prompt breadth first: think out loud through the entities in the system and how they relate, put the full map on the table, then offer directions (validation, constraints, sync versus async, live versus stale data) and let the interviewer choose where to go deep. Two rules made it senior: only introduce what you actually know well, and treat “I don’t know, here’s how I’d find out” as a legitimate answer that builds credibility.

REJECTED: cramming canonical designs for mock interviews. Memorized answers interview like memorized answers; a framework survives contact with a curveball.

Execution

In one representative engagement, a student and I drilled the fundamentals as decisions with tradeoffs rather than vocabulary: load balancing as a stability story (health checks, least outstanding requests, autoscaling tied to the balancer); databases as a read/write split story with an explicit question: are we okay serving stale data, per endpoint?; caching as a cost: “when does the cache make our lives harder?”; queues as the rule of thumb do the minimum to respond, push everything else async; and partitioning as the art of not crossing the boundary. Each session ended with communication reps: state the problem, walk one solution you know well, acknowledge the alternatives you’d need to research. The result is an engineer who controls the opening ten minutes of any design interview, because the opening is the part that’s always the same.

Outcome

1:1

Prep built around each engineer, not a syllabus

Breadth first

A repeatable opening for any design prompt

"I don't know"

Taught as a valid, senior answer

Takeaway

An interview isn't a recall test. It's a demonstration of how you think when you don't know. So that's the skill we practice.