Behavioral interview prep for software engineers, grounded in your real work

"Tell me about a time you disagreed with a technical decision." There's a version of preparing for that question that consists of finding a template answer online and adapting it, and I want to talk you out of it, because the person across the table has heard the template. Engineers put weeks into coding practice and then improvise the behavioral rounds, which gets the difficulty exactly backwards. The coding interview tests whether you can do the work. The behavioral interview tests whether you can produce evidence about work you've already done, and evidence is the one thing you can't generate on the spot.

So treat prep as an inventory problem. Before any specific interview, go through your last several years and write down the stories that actually happened: the migration that slipped, the design you argued against and lost, the incident where you were on call, the project that got cancelled under you. For each one, record the scope, which parts were yours versus the team's, the numbers you could defend if pressed, and how it ended, including badly. The awkward endings are worth keeping. A story that resolves too cleanly reads as rehearsed, and the cancelled project is often where the honest answer about judgment lives.

Then match the inventory to who's asking, because the same question means different things from different people. When we wrote the instructions for jobhunt.coach's interview-prep dossiers, we made them drive everything off the interviewer's role in the loop: a hiring manager probes ownership and judgment, a peer engineer probes hands-on depth, a skip-level probes scope and impact, a recruiter probes motivation and logistics. That mapping is nothing exotic, but doing it deliberately changes which stories you reach for. Your incident story has a version for the peer (what you found in the logs) and a version for the hiring manager (how you decided what to roll back), and picking the wrong version wastes the slot.

The part of our prep instructions I'd most recommend stealing is the section on verbs. It exists because sharp interviewers probe claims, and the verb is usually the claim. The dossier is explicitly forbidden from saying a project "shipped," "deployed," or "launched" unless the person's record actually says so; if something was built but never released, the language is "built and evaluated." That distinction sounds pedantic until you're two follow-up questions deep. Say "we shipped the pipeline" about a prototype and a good interviewer will ask about production traffic, and now you're renegotiating your own claim mid-answer, which costs more credibility than the modest verb ever would have. The same discipline applies to "led": if you contributed to a design someone else owned, "led the design" is a loan against the follow-up question, and the interest rate is bad.

What about the question your inventory genuinely can't answer? Say so. The dossier instructions handle this case explicitly: when the record doesn't support a strong answer, say so plainly and suggest the honest thing to say instead of inventing material. In practice the honest thing is usually your nearest real experience, not a story stretched to fit. A stretched anecdote has to survive follow-ups it wasn't built for. "I haven't run a migration at that scale; the closest I've come is X, and here's what I'd expect to be different" survives every follow-up, because all of it is true. Whether it wins the interview, I can't promise. It does keep you off the worst path, which is defending an exaggeration in real time.

I'll be plain about what jobhunt.coach does here, and what it doesn't. It builds your profile through an interview about your actual work, then writes per-interviewer prep: likely questions for that role in the loop, suggested answers in your own voice drawn only from facts you gave it, and framing notes on what to emphasize and what to own honestly. I've written elsewhere about how it researches a named interviewer without inventing one. What it is not is a coding-drill platform; nothing in it will make you faster at algorithm questions, and if that's the round you're worried about, practice there is the answer.

None of this is fast. Building the inventory is an evening or two of honest memory work, some of it uncomfortable, and re-cutting stories per interviewer adds prep time to every loop. The trade you're making is preparation you can stand behind under pressure. Knowing every claim is defensible changes how you sit in the room, and that tends to carry into the other rounds too.