Interview Questions: What Gets Asked, and What a Strong Answer Sounds Like

The useful part of an interview question is rarely the answer. It is what the answer reveals about how you think — whether you have operated systems or only built them, whether you can say "it depends" and then say what it depends on, and whether you know the limits of your own claim.

For each question below: what is being tested, what a weak answer sounds like, and what a strong one contains. Use them to prepare, or to interview better.

AI and retrieval#

"When would you use RAG instead of fine-tuning?"

Testing: whether you understand facts versus behaviour, or have memorised a comparison table.

Weak: "RAG is cheaper and easier to update."

Strong: facts belong in documents, behaviour belongs in weights. Retrieval when the answer changes when someone edits a file, when you need citations, when permissions must be respected per user. Fine-tuning for format, tone or a task shape the model keeps getting wrong. Mentions that they are not exclusive. (RAG)

"Your RAG system is inaccurate. How do you debug it?"

Testing: whether you separate retrieval from generation. This is the question that most reliably sorts practitioners from readers.

Weak: prompt changes, a bigger model, more context.

Strong: measure retrieval first — was the correct passage even retrieved? If hit rate is 60%, that is the ceiling and no prompt work raises it. Then check chunking, then hybrid retrieval, then generation. Names a specific metric.

"How do you stop an agent from doing something destructive?"

Testing: whether you think in blast radius or in prompts.

Weak: "instruct it carefully and test thoroughly."

Strong: sort tools by reversibility; irreversible actions require confirmation; caps enforced outside the agent because it can reason past its own instructions; untrusted content must not trigger tools directly; test the cap by hitting it. (AI agents)

Engineering#

"How much test coverage should a project have?"

Testing: whether you treat metrics as targets.

Weak: a number.

Strong: coverage is a diagnostic, not a target — it shows what is untouched, not what is verified. Better question: if this broke, which test fails? Concentrate on expensive-to-get-wrong logic, error paths and boundaries. (testing)

"Walk me through how you would review a 2,000-line pull request."

Testing: whether you will tell a colleague something unwelcome.

Weak: a methodical description of reviewing all 2,000 lines.

Strong: ask for it to be split, and explain why — an hour on 2,000 lines produces approval, not review. If it genuinely cannot be split, review in passes and say clearly what was and was not examined.

"You need to rename a database column in a live system. How?"

Testing: whether you have deployed anything with users on it.

Weak: a migration script.

Strong: expand then contract — add the new column, write to both, backfill, switch reads, remove the old one, across several deploys. Every migration backward compatible with the running code, or rollback becomes an outage.

Cloud and operations#

"Is the cloud cheaper?"

Testing: whether you repeat marketing.

Weak: "yes, no capital expenditure."

Strong: not automatically, and often not for steady predictable load on hardware you already own. What you buy is elasticity and time. A machine at 8% utilisation costs the same in the cloud and now bills visibly. Savings come from what the move enables. (cloud)

"A pod is restarting every few minutes and the application logs show nothing. What do you check?"

Testing: real operational experience.

Weak: "check the logs."

Strong: memory limit first — the kernel kills the process so nothing is logged. Then whether the runtime knows its container limit; then liveness probe timing against startup time; then whether a dependency is missing at boot. Names where to look. (Kubernetes)

"How do you know your backups work?"

Testing: the difference between a control and a belief.

Weak: "the backup job succeeds."

Strong: by restoring, on a schedule, and recording how long it took. Backup success measures that a job ran. Also: backups in the same account as the thing they protect do not survive an account compromise.

Data#

"A nightly job reports success but the dashboard shows zeroes. What happened?"

Testing: whether you have run a pipeline in production.

Weak: "check the logs for errors."

Strong: the job caught its own errors, wrote an empty result and exited zero — fresh but empty, the classic silent failure. Fix: fail closed below a minimum row count, keep the last good output, exit non-zero, and check values rather than exit codes. (data engineering)

Delivery and analysis#

"How do you handle a stakeholder who keeps adding scope?"

Testing: whether you can say no with evidence rather than with friction.

Weak: "push back" or "escalate."

Strong: one route in; assess each change including what it displaces; report the cumulative position rather than individual requests. Fifteen approvals, eleven weeks, here is what will not be delivered. Sponsors approve individually reasonable things; the aggregate is rarely what they intended. (Change Management)

"Your UAT finished in three days with no defects. Are you happy?"

Testing: scepticism about good news.

Weak: "yes, that means quality was high."

Strong: almost certainly not done properly. Ask whether participants had released time, whether they tested real end-to-end scenarios or feature checklists, and whether the data was realistic. Absence of findings is not evidence of quality. (UAT)

Questions worth asking them#

The reverse direction matters, and these produce unusually informative answers:

• "What happened in your last incident, and what changed afterwards?" Tells you whether reviews are blameless and whether anything follows them.
• "How long from a merged commit to production?" One number that describes the whole delivery system.
• "What does on-call look like, and how often does it fire?"
• "What is the oldest thing in the codebase nobody wants to touch?" People answer this one honestly, and it is revealing.
• "How is technical debt funded?" If the answer is "in spare time", you know the shape of the next two years.

How to answer well generally#

Say what it depends on. Almost every good technical question has "it depends" as the honest opening — but only if you immediately say on what.

Use a real example. "We had this at a previous job and here is what we found" outperforms any amount of theory.

Give the number. Specifics — hit rate, rollback time, cost per answer — signal that you measured rather than assumed.

Admit the boundary. "I have not run that at scale, but here is how I would approach it" is a strong answer. Confident invention is the fastest way to lose an experienced interviewer.

FAQ#

Should I memorise these answers?#

No — memorised answers are audible, and the follow-up question exposes them immediately. Understand the reasoning; the linked guides carry it.

What if I do not know the answer?#

Say so, then reason aloud about how you would find out. Interviewers are usually more interested in that than in the answer, because it is what you will actually do at work.

How technical should I get?#

Match the interviewer, and offer depth rather than imposing it: give a clear two-sentence answer, then ask if they want the detail. That itself demonstrates communication judgement.

Are take-home tests worth doing?#

A few hours, yes. Multi-day projects for a first-round screen are a poor sign about how the organisation values people's time, and it is reasonable to ask about scope before starting.

How do I interview well without much experience?#

Bring something you built and can discuss in depth — see Projects. Specific knowledge of one real system beats general familiarity with ten.

What is the most common mistake candidates make?#

Answering the question they prepared for rather than the one asked, and inventing certainty. Both are more visible from the other side of the table than people expect.

Do these questions work for interviewing candidates?#

Yes, and the "what is being tested" line is the useful part. Ask the question, then ask why — the reasoning separates candidates far more reliably than the answer.

Related Articles#

Prepare the underlying material in Courses, build evidence with Projects, check recall with Practice Tests, and see what each level requires in Career Paths.

What else is coming for Interview Questions