Making engineering judgment observable in interviews
- YT :: https://www.youtube.com/watch?v=tV-6fCLEbVA
- Original title :: Why Great Engineers Fail Software Interviews
Capable engineers who handle incidents, migrations, and risk reviews freeze on a whiteboard puzzle. The framing offered: an interview is not a verdict on your career, it is a constraint system trying to extract a few signals, and failing it usually means you walked into a system with terrible observability and gave it nothing to observe. Three moves — map the signal, narrate decisions, assess the company while it assesses you.
Two failure modes
Refusing to prepare ("I build real systems, I shouldn't have to") and over-preparing into a polished generic candidate who collapses the moment someone asks what you actually decided, what mattered, and what broke. Coding, design, past work, language knowledge, and behavioral evidence are genuinely different skills, not one skill in different hats.
Read the loop as a specification
Match evidence to what the role is actually assessing. A reliability role wants an incident, monitoring, migration, or capacity story. Product delivery wants a scope trade-off and a stakeholder story. Platform work wants internal customers, adoption, operational boundaries.
Build an evidence library rather than a new biography per application. Each story should carry: what happened, what you owned, which constraint mattered, what you chose, what changed afterward. "We had a big incident and I helped fix it" is fog. "We built a reversible path and a dashboard before a risky migration, so we reduced the unknowns" is evidence.
Live coding and system design
In live coding, do not do mysterious silent typing. Clarify what would change the solution, state a simple approach before optimizing, explain the data structure, test deliberately, state the complexity. When stuck, say where you are stuck — "I want to check whether this invariant holds on duplicates" beats ten minutes of silent keyboard archeology.
System design follows the same rule: requirements before components. Start from workload, requirements, priorities, and what failure the system can tolerate, then add each component because a requirement forces it — a cache because latency or cost matters, a queue because you need decoupling or retries, a replica because of availability or read scale, idempotency because duplicates happen. A diagram full of vendor names is a scavenger hunt, not a design.
Practice and AI
Practice in short simulations: code out loud under a timer, take a vague design prompt and ask for requirements first, record a behavioral answer and cut the filler. Fix one failure mode afterward, not your whole personality.
AI is fine as a coach — let it challenge an assumption or point out where a story has no evidence. Letting it invent your experience or help you evade interview rules is not preparation, it is an integrity failure.
Interview them back
Ask what each round assesses, what this hire owns in the first 6–12 months, how technical decisions get made when deadlines fight reliability, and what would make a capable engineer fail in the role. A vague process does not automatically mean a bad job, but it is risk information — if the company cannot explain what it is measuring, let that reveal its own risk.