Communicating while you work
By the end: Interviewers can see your reasoning, which is what they are actually assessing.
- Thinking out loud
- Clarifying before solving
- Handling being stuck
- Talking about your own work
New to interviewing well? Interviewing well is a separate skill from the engineering being tested, and it is made of specific, practisable habits: narrating your reasoning aloud instead of going quiet, asking what the constraints are before designing anything, checking your own answer before declaring it finished, and arriving with about eight short true stories ready, covering a conflict, a failure, an ambiguous brief and something you would now do differently. Why it matters
Interviewers cannot assess reasoning they cannot hear, and a silent candidate solving the problem correctly still scores badly. This section is about working out loud: stating what you think the question is before answering it, narrating the approach as you go, and saying where you are stuck instead of freezing. It also covers talking about work you have already done, which is a different skill and is tested just as often.
Silence is scored as absence#
An interviewer cannot see you thinking. Careful consideration and having no idea look identical from the outside. Strong engineers fail loops for this reason more often than for gaps in knowledge.
Instead of a pause, say what the pause is:
"I'm weighing two approaches. A hash map is O(n) time and O(n)
space. Sorting first is O(n log n) but constant space. Given the
input sizes you mentioned, I'll take the hash map."The useful reframing is that the interviewer is not scoring your answer, they are filling in a form about how you work, and they can only write down what reaches them. Every second of silence is a second in which nothing is being written. This is why a candidate who gets two thirds of the way with continuous commentary routinely scores above one who arrives at the full answer in silence: the first produced evidence and the second produced a result.
Twelve minutes, annotated#
Read this as a script and then as a clock. The times are what a good pace looks like; the lines in brackets are what the interviewer is writing on the form. It is the opening of an ordinary design round, and it deliberately contains a thing the candidate does not know.
00:00 INT We want to add semantic search over our help centre.
Maybe eight thousand articles. How would you build it?
00:12 YOU Let me make sure I have the shape of it before I design
anything. Who is searching -- customers, or support
agents? And is this replacing the existing keyword
search or sitting next to it?
[two questions, both of which change the answer]
00:25 INT Customers. Replacing it.
00:30 YOU Then the failure I care most about is returning nothing
useful for a common question, because that is a support
ticket. How often do the articles change, and is there
a latency number I should be designing to?
00:45 INT Articles change a few times a week. Under 300ms.
00:52 YOU Good, that rules some things out. Eight thousand articles
is small -- that is the main thing shaping this. I am
going to say the sizes out loud because they decide the
design: chunked at a few hundred tokens, that is maybe
fifty thousand vectors, which is tens of megabytes. It
fits in memory on one machine. So I do not need a
distributed vector database, and I would push back on
one if it were proposed.
[does arithmetic unprompted, and states what it rules out]
01:30 INT Go on.
01:35 YOU Embed the chunks offline, keep them in a single index,
embed the query at request time and take the nearest
twenty. I would run keyword search alongside it rather
than instead of it, because exact terms -- error codes,
product names -- are where embeddings are weakest and
where help centre queries actually live. Then combine
the two lists.
02:20 INT How would you combine them?
02:24 YOU The standard answer is reciprocal rank fusion. I know
the shape of it -- you score each document by one over
its rank in each list and add them, so a document that
is fifth in both beats one that is first in one and
absent from the other. What I do not remember is the
constant that goes in the denominator, and I would not
guess it in a design round. I would look it up, and I
would also try the dumbest version first, which is a
weighted sum of the two scores, and see whether fusion
beats it on our own queries.
[the strongest thirty seconds in the transcript: knows
the mechanism, names the gap precisely, says what they
would do about it, and proposes a baseline]
03:10 INT Most people just say "reciprocal rank fusion" and stop.
03:14 YOU It is the kind of thing that is easy to name and easy to
get subtly wrong. I would rather tell you where my
knowledge ends than have you find out at line forty.
03:25 INT Fair. What about re-ranking? I would put a cross-encoder
in front of this.
03:32 YOU I would not start there, and I want to say why rather
than just disagreeing. A cross-encoder scores every
candidate against the query, so twenty candidates is
twenty forward passes inside a 300ms budget, and it adds
a second model to operate. The reason to pay that is
when retrieval is returning the right document outside
the top few, and I do not know yet whether it is. So I
would ship without it, measure recall at twenty against
a set of real queries, and add the re-ranker if the
document is being found but ranked badly. If you have
seen it be necessary at this scale, though, I would
want to hear that -- it would change my order.
[disagrees with a cost, a condition and a measurement,
then leaves the door open. Scored as senior, not as
difficult]
04:30 INT No, that is reasonable. Where does this break?
04:35 YOU Two places. Articles change a few times a week, so
something has to re-embed them, and the version I just
described has no story for that -- I would want a job
that re-embeds changed articles and an index that can be
rebuilt from scratch in minutes, because at eight
thousand documents rebuilding is cheaper than being
clever about updates. The second is that I have no way
to tell whether it is working. Before any of this I
would want fifty real queries with the article that
should come back, so that every change after today
produces a number.Clarify first, always#
Questions are deliberately underspecified. Asking is not a stall, it is part of the assessment, and candidates who start coding immediately lose marks before they write anything. The test for whether a question is worth asking is whether the two possible answers lead to different designs. If they do not, you are performing curiosity rather than reducing uncertainty, and experienced interviewers can tell the difference.
question what it changes
who is the user? tolerance for a wrong answer
how much data? whether one machine is enough
how often does it change? batch or streaming, cache or not
what is the latency budget? how many model calls you can afford
what happens when it is wrong? whether you need a human in the loop
is this replacing something? what the baseline to beat is
what does success look like? what you are allowed to measureOne habit doubles the value of the answers: repeat back what you heard in the form of a constraint. Saying that eight thousand articles fits in memory so a distributed store is not needed turns a fact you were given into a decision you made, and the second is what gets written down.
Saying you do not know#
Every loop contains at least one question you cannot answer, by design. It is there to see what you do. The failure is not the gap, it is the bluff, and interviewers detect bluffing with unpleasant reliability because they ask a second question and the answer stops being specific.
The shape that works, in four parts:
1. name the boundary precisely "I know how it works, not the
exact formula"
2. give what you do have "it scores by one over the rank
in each list"
3. say what you would do "I'd look it up before using it"
4. offer the baseline "and I'd check the simple version
beats nothing first"
Bad Why it fails
"I'm not sure" stops there. Nothing to score.
"I think it's probably..." a guess wearing a hedge. The
follow-up exposes it in one turn.
"I haven't used that" true and useless. Say what you
would do instead.
confident invention the worst outcome available. It
converts a small gap into a
question about trustworthiness.There is a real asymmetry here worth internalising. An admitted gap costs you a fraction of one question. An invention that is caught costs you the interviewer's trust in everything you said before it, including the parts that were true, because they now have no way to tell which those were. The expected value is not close.
Disagreeing well#
Interviewers propose things they do not believe in, to see whether you will agree with a senior person for social reasons. Agreeing to something you think is wrong is scored as a failure, and so is digging in. What is being looked for is whether you can hold a position with a reason and update it with evidence.
A disagreement that scores well has four parts:
acknowledge the reason it was proposed "a cross-encoder would
improve ranking, yes"
name the cost concretely "twenty forward passes
inside 300ms, plus a
second model to run"
give the condition that would change "if recall at twenty is
your mind fine and ranking is bad,
it becomes the right call"
propose how to find out "I'd measure that first"
And then actually update if they give you evidence. Changing your
mind when given a reason is a separate positive signal from having
had the position, and you only get it by having had the position.Say the words that mark it as a disagreement rather than leaving it implicit. Something as small as saying you want to push back on that, and here is why, tells the interviewer you know you are disagreeing and have chosen to, which is a different thing from not having understood the suggestion.
Being stuck is normal#
What is being assessed is how you behave when stuck, not whether it happens. Say where you are, state what you have ruled out, and propose the next thing to try.
"I'm stuck on the update step. I know the brute force is O(n²)
and I need better. I don't think sorting helps because the order
changes. Let me try working backwards from the end and see if
that gives me something incremental."Three sentences: where I am, what I eliminated and why, what I will try next. It also makes it possible for the interviewer to help you, which they usually want to do and cannot do for someone who has gone quiet. Take the hint when it comes, say what it unlocked, and carry on. Taking a hint well is scored positively; arguing with one is the most expensive thirty seconds available in an interview.
Talking about your own projects#
Deep-dive rounds reward specifics. Vague ownership claims collapse under two follow-up questions, and interviewers ask exactly two follow-up questions.
- Name the actual problem and why it mattered, not the technology used.
- Name a decision you made, the alternative, and why you chose as you did.
- Give a number: latency, cost, volume, error rate. Numbers signal you measured.
- Say what you would do differently. This reads as seniority, not weakness.
- Be exact about what you personally did when the work was shared.
what you say what it is heard as
"we built a RAG pipeline" you were in the room
"I owned retrieval; someone you did the retrieval work
else built the ingestion"
"it was much faster" you did not measure it
"p95 went from 4.1s to 900ms" you measured it
"we chose Postgres" someone chose Postgres
"I chose Postgres over a you made a decision and can
vector database because 50k defend it
vectors fit in one table"
"it worked well" no failures, therefore no
learning, therefore junior
"it worked until the index you ran it in production
went stale on a Friday"Prepare eight stories, not one
Conflict, failure, ambiguity, influencing without authority, a hard technical decision, a time you were wrong, a time you disagreed with a manager, something you shipped that mattered. The same underlying project can supply several, but rehearse them separately.
Where people go wrong
Claiming broad ownership of team work. Two follow-up questions expose it, and the recovery is much worse than having been precise in the first place.
If this comes up in an interview
Tell me about a technically difficult project.
Lead with the problem and why it mattered, not the stack. Name one hard decision, the alternative you rejected and why. Include a number that shows you measured. Finish with what you would do differently, which reads as judgement rather than doubt.
Tell me about a time you were wrong.
Pick something genuinely wrong with a real consequence, say how you found out, what you did immediately, and what changed afterwards so it could not recur. Avoid the disguised strength, which every interviewer recognises instantly.
What do you do when you are stuck in an interview?
Say so, state what has been ruled out and why, and propose the next thing to try. Interviewers expect candidates to get stuck; they are assessing how you behave when it happens.
Build this: Record yourself solving a problem out loud for thirty minutes. Watch it back and mark every silence longer than ten seconds. Those are the moments an interviewer had nothing to assess.
Watch it explained
This is one section of Interviewing well, 20 hours across 5 sections. Read it in full to get the whole topic in order.
Stop 50 of 50 on the AI Engineer route
0 of 50 topics done · 0h behind you, 603h to go
That is the last stop on this route. What remains is the part no syllabus can do for you: build the projects, and apply.
What you have marked done is stored in this browser only. It does not reach a server, and clearing site data will clear it.