Being drilled on your own work

There is a round where someone takes a project off your CV and asks about it until you run out of answers, and it goes about three levels deeper than most people prepare for: what you built, why that way, and what you considered and rejected. This section prepares the third question, which is the one that decides the round, because it asks about paths you did not take and so cannot be answered out of familiarity with the code. It also covers choosing which project to present, and how to describe a failure without either minimising it or performing remorse.

The round people most underestimate#

Near-universal at frontier labs and big tech, and reliably underprepared, because candidates assume that familiarity with their own work is preparation. It is not. You know what you built; the round asks why, what you rejected, and what you would change, and those are different memories.

The formats vary. Some organisations ask for a written statement of your best work submitted up front and question you on it. Some ask for a slide presentation to several people. Some run it as an hour with a hiring manager and no artefact at all. The mechanic underneath is identical: three levels deeper than you expect, on anything your CV claims.

Level 1   What did you build?            everyone prepares this
Level 2   Why that way?                  most people manage this
Level 3   What did you reject, and why?  this is where it decides

Choosing the project#

Pick the one where you made real decisions, not the one with the biggest name attached. A minor feature you owned end to end beats a famous system you were adjacent to, every time, because the questions are about decisions and you only have answers for decisions you made.

• Did you choose the approach, or implement someone else's choice? Only the first survives three questions.
• Can you name something you considered and rejected? If not, you were executing rather than deciding.
• Do you know a number about it? Latency, cost, volume, error rate, or how long it took.
• Do you know what went wrong? A project with no problems is a project you did not run.
• Can you explain it to someone outside your team in two minutes? If not, you will spend the round on context.

Scale is not the criterion. Interviewers at this level have seen large systems described by people who could not say why a queue was there. A small project with real decisions in it reads as stronger than a large one you can only narrate.

The chain that always comes#

1. 1.What did you do, as opposed to what the team did?
2. 2.Why that approach?
3. 3.What did you consider and reject, and what would have changed your mind?
4. 4.What went wrong?
5. 5.What would you change if you did it again?

Prepare the chain, not the story. Written out, each project should have five answers rather than one narrative, because you will be asked them in this order and interrupted between them.

The same answer, shallow and properly#

The difference is not length. A shallow answer describes what exists; a deep one describes the decision, including the thing it was chosen over and the evidence that settled it.

Shallow:

"We built a retrieval system for our support docs. I used a
vector database and chunked the documents, and it worked well.
Users were happy with it."

Nothing here can be followed up except by asking the same
question again. There is no decision, no alternative and no
number.

At depth:

"Support answers were citing archived articles. I owned
retrieval; a colleague owned the answer generation.

I started with fixed-size chunks because it was an afternoon's
work and I wanted a baseline. It scored 10 of 24 on a held-out
set of real questions I had labelled.

I considered fine-tuning, and rejected it: the failures were
wrong facts, not wrong form, and fine-tuning does not reliably
install facts. The cheap fix was metadata filtering on the
archived flag, which took two hours and moved us to 17 of 24.
Cost went up 8% because the filter reduced cache hits.

What went wrong: I labelled the held-out set myself, so it
encoded my idea of a good answer. Two of the remaining failures
were questions support staff would not have marked wrong.

If I did it again I would have someone from support label the
set before I started tuning anything."

Talking about a failure#

There are two failure modes and interviewers see both weekly. Minimising turns the failure into a success with an obstacle in it. Performing contrition turns it into a display of how seriously you take things, which reads as avoiding the technical content.

The shape that works is flat and factual: what happened, what it cost, how you found out, what you did, and what changed so it cannot recur. Deliver it in the same tone you would use for a design decision, because to an interviewer that is what it is.

Minimising     "There was a small issue but we caught it quickly
                and it was mostly a process problem."

Performing     "I still think about it. It taught me how much
                responsibility I carry and I have never stopped
                being careful since."

Flat           "I shipped a change that dropped retrieval quality
                for a fifth of queries. Nobody noticed for nine
                days because we had no eval running in CI. A
                support lead reported it. I reverted it that
                afternoon, then spent two days building the eval
                gate that should have existed first."

Note what the third version does not contain: an adjective about how the candidate felt. The regret is carried by the facts, and the interviewer can see the judgement without being told it is there.

'Why didn't you just...'#

Sometimes the honest answer is that you did not think of it. That answer is safe, and every alternative to it is not. An invented justification is detectable in one follow-up because you are reasoning about a design you never considered, and the interviewer has usually watched several people try it.

"I didn't consider that. Thinking about it now: it would have
avoided the filtering step entirely, and the cost would have
been re-indexing whenever the archive flag changed. Given how
often that happened, it would probably have been the better
call."

The other case is that you did consider it and had a reason. Then give the reason and the evidence, and be willing to concede if the interviewer's version is better. Defending a decision past the point where it has been shown to be wrong scores far worse than changing your mind out loud.