The questions you ask, and the red flags in your answers
Two things get scored that most candidates never prepare: the questions you ask at the end, and the patterns your own answers fall into. The story structure lives in What was the most challenging part of a recent project?; what the interviewer is reading lives in The six signals an interviewer is actually reading. This note is the other half — the diagnostics you run on yourself.
The questions are a technical answer
“Any questions for us?” is not politeness. A senior candidate’s questions reveal what they think matters, and a question with no follow-up in it reveals that they stopped preparing at the job ad.
Ask questions whose answers would actually change your decision. Four that work, and what each is really probing:
- “How do you evaluate LLM features before shipping?” — whether they have eval discipline or ship on vibes.
- “What was your last incident, and what’s the process?” — blameless post-mortems, or a hunt for who broke it.
- “How much of the codebase would you rewrite, given the chance?” — how honest they are about their own debt.
- “What does the path from this role to the next look like?” — whether levelling is a real process or a conversation that never happens.
The first one is the highest-value question you can ask an AI-adjacent team. There are only three possible answers: they have an eval suite and can describe it, they have vibes and know it, or they have vibes and don’t. The third is the one worth walking away from, and you cannot detect it from the outside.
Follow up on the answer. A question you don’t build on reads as a list you memorised. If they say they run evals in CI, ask what breaks the build. If they say they had an incident last month, ask what changed afterwards — the answer “we added an alert” and the answer “we changed how we deploy migrations” are different organisations.
Questions that cost you
- Anything on the careers page. It says you didn’t read it.
- Salary and holiday in a technical round. Right question, wrong room.
- “What’s the tech stack?” You are three rounds in. You know.
- “Do you have work-life balance?” Asked this way it invites a scripted yes. Ask instead what the on-call rotation looks like and who carries the pager.
The red flags in your own answers
These are self-diagnostics. Record yourself answering three questions and listen for them; they are much easier to hear than to notice live.
Naming tools instead of explaining trade-offs. “We used Kafka” is not an answer to “how did you handle the event volume”. The tool is the conclusion; the interviewer wants the reasoning that arrived at it. The repair is to state the constraint first: “we needed replay after a consumer bug, which ruled out a plain queue, so Kafka” is the same sentence with the thinking left in.
No numbers anywhere. “It got much faster” is unfalsifiable and reads as unmeasured. p95 went from 1.2s to 240ms, the query count went from 340 to 6, the bill went from $4k to $1.1k a month. If you genuinely don’t have the number, say so and give the magnitude: “I don’t have the figure to hand — it was roughly an order of magnitude.” That is still an answer with a shape.
Never disagreeing with anything. Total agreement reads as either no opinions or no experience. Every real system has a decision you would now reverse. Have one ready, with the reason it looked right at the time — that second half is what separates judgement from hindsight.
Claiming a technology you can’t explain the failure modes of. This is the expensive one. Interviewers probe exactly at the edge of a claim, so a CV line you cannot defend is worse than an absent one. The rule: if you cannot name how it breaks in production, do not claim it — say “I’ve used it, not deeply” and move to something you can defend. Nobody is penalised for a bounded claim.
Answering a “why” question with a “what”. “Why did you choose Postgres for the vector store?” answered with a description of pgvector is a what. The why is “we already ran Postgres, the corpus was under 10M chunks, and one datastore with transactional consistency between chunks and metadata beat a second system to operate.”
Narrating instead of concluding. A long story with no stated outcome makes the interviewer do the scoring work. End every story with the result and the one thing you’d change; see the weighting in What was the most challenging part of a recent project?.
The self-audit before an interview
Pick three claims from your CV. For each, write down in one line:
- How it breaks in production.
- What you’d use instead, and when.
- A number from your own use of it.
Any claim where all three are blank is the one they will find. Either study it or soften the claim before the conversation, not during it.
Related
Interview angle 3
- “Any questions for us?” - ask about eval discipline, the last incident and what changed after it, and how much of the codebase they would rewrite. Then follow up on the answer; the follow-up is the part that scores.
- “What would you change about your last project?” - this is the disagreement red flag in disguise. A candidate with nothing to change has either not shipped or is not reflecting. Name one decision, why it was reasonable then, and what new information made it wrong.
- “Tell me about a technology you used.” - the follow-up will be “how does it fail”. Answer the failure mode before you are asked; it converts a claim into evidence and removes the probe.