The last round of the day is with a senior manager. No whiteboard. The first question sounds easy: tell me about a time you disagreed with a designer. You tell a good story about a bug you found. Halfway through, the manager asks what did the designer say? and what would you do differently?, and you realise you told a technical story with no people in it. Senior DV is half judgement, and this round is where it is measured.
This lesson gives a structure for behavioural answers and five model answers, one per theme interviewers ask about most: ownership, conflict, prioritisation, failure and mentoring. The stories are built from things that really happened while building the course bench, written in the first person so you can hear the shape. Use your own stories in the interview; use these to check that yours have the same parts.
A good answer is like a good bug report. It says what the situation was in two sentences, what you decided (not "we"), what evidence you used, what happened with a number in it, and what changed afterwards so it would not happen again. The last part is what separates senior from mid-level: a mid-level engineer fixes the problem, a senior engineer fixes the process that let it happen.
Theme | What the interviewer writes down | The red flag |
|---|---|---|
Ownership | Did you drive it end to end without being asked? | "I was assigned…" and nothing beyond the assignment |
Conflict | Did you use data, and did you stay respectful when wrong? | The other person is the villain; you were never wrong |
Prioritisation | Can you rank by risk and say no visibly? | Doing everything in arrival order, or heroics |
Failure | Do you own a real mistake and the systemic fix? | A humble-brag ("I work too hard") or blame |
Mentoring | Do you teach method, or type the fix? | "I just fixed it for them" |
Weak: "I owned the scoreboard for our DMA. I wrote it, it worked, and we taped out." There is no decision and no evidence.
Model answer: "On a DMA block I owned end-of-test. We had tests that passed with words still inside the design, because each test decided for itself when to stop. I proposed one rule: the scoreboard owns the end, through phase_ready_to_end, and holds the phase open while it still owes output words. My first version took the owed count from the words the monitor had seen go in, and a review run showed a test passing with one word missing, because a word the DUT never accepted was never owed. I changed it to count from what the DUT was programmed to do, the LEN register, and added a check that fails if nothing was compared at all. After that, every test on the block used the same end-of-test component, and early-end failures stopped appearing in triage. I also wrote the rule into our testbench guidelines so new tests got it by default."
Why it works: one decision, a mistake you caught yourself, the fix tied to the design's contract, and a process change. The owed-count mistake is real (war story 3 in this course), and it is exactly what makes the answer believable.
Weak: "The designer said the RTL was right and I proved them wrong." Interviewers have heard this a thousand times, and it signals that you need to win.
Model answer: "A scratch test that wrote the key register in the middle of a job gave five data mismatches, and I filed it as a design bug. The designer said the DMA ignores KEY and LEN writes while it is busy, by design. I was sure the spec allowed the write, so I went back to it and found the busy rule in a table I had skimmed. They were right: my reference model and my scoreboard both took the new key at once. I said so in the bug thread the same day and moved the bug to the testbench. Then we agreed two things: the rule went into the model as a predictor callback, and a directed test now writes KEY while busy and expects the old key to stay in force. The real lesson for me was that no test had ever written a register mid-job, so a whole class of DUT rules was untested on both sides."
Why it works: you were wrong, you said so quickly, you used the spec rather than opinion, and you turned the disagreement into a test. Interviewers score how you handle being wrong far above being right.
Weak: "I worked late and got it all done." Heroics are not a method, and they do not scale to a team.
Model answer: "The night before a milestone we had forty-one failing tests and three people. I spent the first half hour on nothing but bucketing: I grouped failures by first-error signature, which gave four distinct problems. Two buckets were one testbench bug, a driver that forgot to complete an item on a rarely used path, so one fix cleared thirty tests. One bucket was a real design bug on an error path. The last was a single intermittent failure. I put one person on the design bug with the designer, fixed the driver myself, and parked the intermittent with a seed and a ticket, telling the lead explicitly that it would not be root-caused by the milestone. We met the milestone with one known, documented open issue instead of forty-one unknowns."
Why it works: ranking by impact, a visible "not now" with a ticket, and the lead informed before the deadline, not after. Regression Triage by Signature is the technique behind it.
Weak: a mistake that was really someone else's, or a trivial one. The interviewer wants to see you own something that cost the team.
Model answer: "I wrote a coverage model for a DMA's status register and marked 'DONE and ERR both set' as an illegal bin, because in every test I had seen, the DMA never reported both. A colleague's run later read STATUS as 0x6: ERR from a previous job survives a new GO unless software clears it, and the spec allows that. My illegal bin was encoding a habit of our tests as a rule of the design, and if that combination had been hit in a long regression it would have failed for no reason, or worse, someone would have 'fixed' the RTL. I changed it to a regular bin, and I proposed a review rule we still use: every illegal bin needs a spec citation in a comment, and the designer signs it off. We found two more like it in the first review."
Why it works: the mistake is real and specific, you explain the reasoning that led to it, and the process change outlives you. This is war story 10 in this course.
Weak: "I'm always available. When they're stuck I sit down and fix it with them." That trains dependence.
Model answer: "When a junior on my team was stuck on a hung simulation, I didn't open the waveform. I asked three questions: did it end on a timeout or a fatal, who is holding the objection, and what was the last transaction on each bus. They found the holder with display_objections and a driver missing item_done within twenty minutes. Then I asked them to write the triage steps down as a one-page note for the team wiki, and to present their bug at our weekly meeting. Over a quarter, the number of 'can you look at my hang' messages to me went from several a week to almost none, and that note became part of onboarding."
Why it works: you taught a method, measured the effect, and made the knowledge survive you. The method itself is in the Hang Playbook.
This one is asked in almost every senior loop, and it needs its own preparation: symptom, hypotheses, the instrument that split them, the root cause, and the guard you left behind. Telling Your Bug Story builds that answer step by step. Prepare two stories: one design bug and one testbench bug, because interviewers often ask for the second.
"We" all the way through. The interviewer cannot hire your team. Say "I" for your decisions and "they" for others, and be precise about which was which.
No number. "It went much better" is not a result. Thirty tests cleared, three weeks saved, two escapes found: anything measurable.
The story never ends. Ninety seconds, then stop and let them probe. Long answers leave no time for the follow-ups that score.
Blaming the design team. Even when they were wrong, describe what you did, not what they failed to do.
One story for every question. Prepare six to eight stories and map each to two or three themes before the loop.
The process change and any sign that you would handle being wrong. Add what you agreed together afterwards (a test, a spec clarification, a review rule), and if you have one, a story where you were the one who was wrong.
It is not a failure; it is a disguised strength, and interviewers recognise it. They want a real mistake with a cost, your reasoning at the time, and the systemic fix. A specific coverage, checker or schedule mistake is far stronger.
Next: the question index points every common question, behavioural ones included, at its home lesson. High-Frequency Question Index.