Why Panic Sets In the Moment I Ask About Their Project

THE BUG QUESTION — READ AS AN INTERVIEWER:

Interviewer: "Tell me about the hardest bug
you debugged on this project."

Candidate: "Um... there was a bug... it was
in the... the service, I think. We fixed it."

What I notice:
- The candidate's pace changes. They speed
  up, then stop.
- The answer is vague: "a bug," "the
  service," "we fixed it."
- There's no moment, no root cause, no fix.
- They're reaching for a memory that isn't
  there.

What the panic reveals:
❌ They didn't debug it — someone else did
❌ They were a passenger on the project
❌ They can't describe the failure modes
❌ They prepared the summary, not the depth

What I do next:
- I ask a simpler version: "What's a bug
  you personally fixed?"
- If they still can't answer, I move on.
- The project score drops, and the
  interview is now uphill.

Why the question matters:
- Debugging is where engineering judgment
  lives
- A candidate who can't tell a bug story
  hasn't owned code in production
- The panic is the tell: the story isn't
  there

THE DECISION QUESTION — READ AS AN INTERVIEWER:

Interviewer: "Why did you choose Kafka over
RabbitMQ?"

Candidate: "I'm not sure, actually. The team
decided. I just built the consumers."

What I notice:
- The candidate defers: "the team decided."
- There's no trade-off, no reasoning.
- They built the consumers but didn't own
  the choice.
- The pause before the answer is the tell.

What the panic reveals:
❌ They were an executor, not a decision-maker
❌ They can't explain the trade-off
❌ They didn't own the architecture
❌ They can't be trusted with architecture
  decisions in the next role

What I do next:
- I ask: "What would you have chosen?"
- If they can reason through it, they
  recover.
- If they can't, the architecture score
  drops.

Why the question matters:
- Every architecture choice has a trade-off
- A candidate who can't explain the choice
  didn't make it
- The panic is the tell: the reasoning isn't
  there

The recovery:
"I wasn't the one who chose Kafka — the
staff engineer did. But I'd guess it was
because of throughput: we needed 8K
events/sec, and RabbitMQ's throughput is
lower per node. The trade-off is operational
complexity — Kafka needs Zookeeper or KRaft
and more tuning. If I were choosing for a
lower-throughput system, I'd pick RabbitMQ
for the simpler ops."

PASSENGER — READ AS AN INTERVIEWER:

Interviewer: "Walk me through the
architecture."

Candidate: "Sure. We used microservices with
Kafka, Kubernetes, and PostgreSQL. The
services communicated via REST and events.
We deployed on EKS."

Interviewer: "Why microservices instead of a
monolith?"

Candidate: "I'm not sure. That was decided
before I joined."

Interviewer: "Why Kafka over RabbitMQ?"

Candidate: "The team chose it."

Interviewer: "Why PostgreSQL over DynamoDB?"

Candidate: "I think it was already there."

What I notice:
- Every decision was made by someone else.
- The candidate can describe the
  architecture, but not the reasoning.
- "The team chose it" is the phrase that
  tells me they were a passenger.

What it reveals:
❌ They executed tickets, not decisions
❌ They can't reason about architecture
❌ They'd be a passenger in my team too

What I do next:
- I ask: "What would you have decided, and
  why?"
- If they can reason through it, they
  recover a point.
- If they can't, the architecture score
  drops hard.

NO DEPTH — READ AS AN INTERVIEWER:

Interviewer: "What happened when the
pipeline broke?"

Candidate: "I'm not sure. I think someone
else handled it. I wasn't on-call."

Interviewer: "What monitoring did you add?"

Candidate: "The team had monitoring. I didn't
set it up."

Interviewer: "What was the hardest bug?"

Candidate: "I don't remember a specific one."

What I notice:
- No incident, no monitoring, no bug.
- Every answer defers to someone else.
- The candidate built features and left.

What it reveals:
❌ They've never owned production
❌ They've never been on-call
❌ They've never debugged under pressure
❌ They can build, but they can't own

What I do next:
- I ask: "Have you ever been on-call for
  anything?"
- If the answer is no, I weight the
  interview toward junior roles.
- If the answer is yes but they can't tell a
  story, the gap is bigger than the
  experience.

THE RECOVERY — IN 30 SECONDS:

Interviewer: "Why did you choose Kafka over
RabbitMQ?"

Candidate: "I wasn't the one who chose Kafka
— the staff engineer did. But let me reason
about it, because I worked with the system
for 18 months.

We needed 8K events/sec with ordering
guarantees per key. Kafka is built for that:
it's a log, so ordering per partition is
free, and throughput is much higher per node
than RabbitMQ. RabbitMQ is better for
complex routing and lower throughput, and the
ops are simpler.

The trade-off was operational complexity:
Kafka needs Zookeeper or KRaft, plus more
tuning. If I were choosing for a
lower-throughput system, I'd pick RabbitMQ
for the simpler ops.

So: I wasn't the decision-maker, but I
understand why the decision was made."

What the interviewer thinks:
- "They admitted they weren't the
  decision-maker." ✅
- "They reasoned about the trade-off." ✅
- "They named when the other choice
  wins." ✅
- "They understand the system, even if
  they didn't choose it." ✅
Signal: recovered. Strong hire.

Why it works:
✅ Honest: "I wasn't the decision-maker"
✅ Judgment: throughput vs. routing vs. ops
✅ Nuance: "if I were choosing..."
✅ Ownership mindset: reasoning about
  the future, not just the past

THE BUG RECOVERY — IN 30 SECONDS:

Interviewer: "What was the hardest bug you
debugged?"

Candidate: "I can't remember one specific
bug that was 'hardest' — but I can tell you
about a bug that taught me the most.

We had a memory leak in a Kafka consumer. The
consumer would OOM every 3–4 days. The heap
dump showed the leak was in the consumer's
offset tracking — we were holding references
to processed records in a static map.

I found it by taking a heap dump with
jmap and comparing retained sizes over time.
The static map grew by about 200MB per day.

The fix was to remove the static map and use
Kafka's built-in offset management. After
that, the consumer ran for 90 days without an
OOM.

What I learned: static state in a long-running
consumer is a leak waiting to happen. I've
since added a heap-dump check to our
post-deploy checklist."

What the interviewer thinks:
- "They didn't have a 'hardest' bug, but
  they had a real one." ✅
- "They named the symptom: OOM every 3–4
  days." ✅
- "They named the method: heap dump, jmap,
  retained size." ✅
- "They named the fix and the outcome:
  90 days without OOM." ✅
- "They reflected: heap-dump check in the
  checklist." ✅
Signal: recovered. Strong hire.

Why it works:
✅ Honest: no "hardest" bug, but a real one
✅ Symptom: OOM every 3–4 days
✅ Method: jmap, heap dump, retained size
✅ Fix and outcome: 90 days without OOM
✅ Reflection: post-deploy checklist

Project Interview Checklist:

LAYER 1 — THE PROJECT:
☐ Architecture in 60 seconds
☐ Scale: requests, data, users
☐ SLA: what time, what success rate
☐ Team: how many, what roles

LAYER 2 — THE DECISION:
☐ One decision you made, and why
☐ The trade-off you accepted
☐ When the alternative would win
☐ What you'd do differently

LAYER 3 — THE INCIDENT:
☐ One bug story: symptom → method → fix
☐ The monitoring you built
☐ The MTTR before and after
☐ What you learned

RED FLAGS IN YOUR OWN ANSWERS:
❌ "The team chose it" with no reasoning
❌ "I don't remember a specific bug"
❌ "Someone else handled it"
❌ No numbers anywhere
❌ No trade-off
❌ No reflection

THE PANIC TEST:
For each project, ask yourself:
1. "What was the hardest bug?" — can you
   answer in 30 seconds?
2. "Why that decision?" — can you answer in
   30 seconds?
3. "What happened when it broke?" — can
   you answer in 30 seconds?

If any answer is no, the panic will set in.
Prepare that layer before the interview.