Gendi Notes

Interview Tips and Tricks

The same knowledge scores a rejection or a staff offer depending on how it is framed — and framing is a skill you can practise in an afternoon.

Level 4 interview interviewsdevopspreparation

What is it?#

The part of interview preparation that is not knowledge. How to structure an answer, what to say when you do not know, how to be levelled correctly rather than generously, and the specific sentences that move you up a band.

None of this substitutes for knowing the material. It changes how much credit you get for the material you already know — which, for most people preparing, is the larger gap.

Why it exists#

Two candidates with identical knowledge routinely get different outcomes, and the difference is legible in the transcript.

Candidate ACandidate B
"I'd check the logs.""First I'd ask what changed — 70% of incidents end there."
"It depends.""It depends on team size. Under five services, I'd say…"
"I don't know.""I don't know that. Here's how I'd find out in ten minutes."
"We used Kubernetes.""We moved to Kubernetes for bin-packing; it cost us a platform hire."

B is not smarter. B is answering the question the interviewer is actually asking, which in every row above is "how do you think?"

What it is made of#

Four things are being scored, in every round, whatever the stated topic:

SignalHow it shows upHow to feed it
JudgementDo you pick sensibly under ambiguity?State the trade-off you are optimising for
MethodIs there a system, or are you guessing fast?Narrow out loud, one layer at a time
OwnershipDo you say "we should have" or "they didn't"?Blame the missing guardrail, never a person
CalibrationDo you know what you do not know?Say the boundary of your knowledge, precisely

How to use it#

The four sentences that move you up a band#

Memorise these shapes, not the words. Each one converts a fact you already know into a signal you were not otherwise sending.

1. "What's the scale?" → before any design answer turns a guess into a requirements conversation 2. "I'm optimising for X over Y, because…" → names the trade-off explicitly the single strongest seniority signal 3. "This design is bad at…" → volunteered, unprompted nobody expects it and everybody scores it 4. "I don't know that. Here's how I'd find out." → turns a gap into a method scores higher than a confident wrong answer

The debugging round: narrate, do not just do#

The commands matter less than the sentence before each command. Say what you are ruling out, then run it.

WeakStrong
(runs kubectl get pods)"First, is it even scheduled? get pods tells me Pending versus Running versus CrashLoop."
(runs kubectl logs)"It's crash-looping, so the live container's logs are empty — I want --previous."
"Let me check Grafana.""I want to know if this is one pod or all of them, because that splits the problem in half."

Rehearsal that actually works#

DoNot
Answer out loud, on a timerRead answers and feel prepared
Record yourself once. Watch it onceSkip this because it is uncomfortable
Write your three stories before the interviewImprovise a postmortem story live
Practise the worst question you can imagineOnly revise what you enjoy

Write three stories in advance, because they cover most behavioural questions between them:

  1. An outage you caused — with the guardrail you added afterwards.
  2. A disagreement you lost — and what you did once the decision was made.
  3. Something you built that mattered — with the number that shows it did.

Each one: under two minutes, blast radius in user terms, and what changed structurally afterwards.

What goes wrong#

MistakeWhy it costs youInstead
Answering the question you wish they askedReads as not listening, or not knowingOne sentence of framing, then answer what was asked
"It depends" with no follow-upTrue but emptyName the condition that decides it
Padding a thin answerDilutes the strong part and invites a harder follow-upFinish and stop. Silence is fine
Bluffing a tool you used onceThe follow-up always comes, and it is specific"I've read about it, not run it in production"
Criticising a former employerReads as the problem travelling with youDescribe the constraint neutrally, then your response
Accepting an impossible premise"100% uptime" — agreeing fails a maturity testPush back with numbers, then reframe
Not asking anything at the endReads as indifferenceHave three questions, and one should be uncomfortable

Questions worth asking them#

The end of the interview is still the interview. These also tell you whether you want the job.

QuestionWhat the answer reveals
"Who is on call, and how many pages last month?"Whether reliability is real or aspirational
"How long from merge to production, and who can deploy?"Actual engineering maturity, in one number
"What broke most recently, and what changed after?"Whether postmortems produce action or documents
"What does this team spend time on that it wishes it did not?"The toil you would inherit
"What would make you regret hiring me in six months?"The honest version of the job description

Key takeaways#

  • The question is a pretext. Every senior question is really "how do you decide?" Answer that.
  • Say the trade-off out loud. "I'm optimising for X over Y, because…" is the strongest single sentence available to you.
  • Volunteer your design's weakness. Unprompted, every time.
  • Calibration scores higher than confidence. "I don't know, here's how I'd find out" beats a smooth wrong answer.
  • Narrate the debugging round. Say what each command rules out before you run it, and never fix the first thing you find.
  • Write your three stories before the interview, and keep each under two minutes.
  • Ask them something uncomfortable. It scores well, and the answer tells you whether to accept.

Last updated 2026-09-08