Why Panic Sets In the Moment I Ask About Their Code

Panic Reaction:
Me: "Walk me through this function."

Candidate: "Uh... this one... it, um,
takes the data and... processes it."

Me: "What does 'processes' mean here?"

Candidate: "I think it... filters something?
I wrote this a while ago."

Me: "Okay. What happens if the input is
empty?"

Candidate: "I'm not sure. Probably it
handles it."

What it signals:
- They don't know their own code
- They copied without understanding
- They never considered edge cases

The interview is effectively over.

Ownership Reaction:
Me: "Walk me through this function."

Candidate: "This takes the raw transaction
list and groups it by category. I used a
reduce here because we needed a single
object, not a filtered array.

The tricky part was handling null categories
— I added a fallback to 'uncategorised'
after we saw that break in production.

If the input is empty, it returns an empty
object — that's the early return on line 4."

Me: "Why reduce and not a loop?"

Candidate: "Honestly, I considered a loop
first, but reduce made the grouping logic
easier to read. In hindsight, a loop might
have been clearer for the team — that's a
trade-off I'd reconsider."

What it signals:
- They understand every line
- They made deliberate choices
- They know the trade-offs

The interview continues.

Recall Example:
Me: "Why did you use a queue here?"

Candidate: "Because queues are FIFO. A queue
processes items in order. That's the
standard way to handle this."

Me: "Right. But why a queue instead of a
list in this specific case?"

Candidate: "That's... what the tutorial
used. It's the standard pattern."

What it signals:
- They know the textbook definition
- They can't connect it to their own
  decision
- There was no decision

It is memorisation, not understanding.

Ownership Example:
Me: "Why did you use a queue here?"

Candidate: "The incoming webhook events were
arriving faster than we could process them.
If I processed them inline, requests would
time out.

A queue let me acknowledge the webhook
immediately and process in the background.
I picked a queue over a list because I
needed FIFO ordering — events had to be
processed in arrival sequence.

The trade-off was added latency and a new
failure mode — if the worker dies, events
pile up. I added a dead-letter queue for
that."

What it signals:
- They understand the problem
- They made a deliberate trade-off
- They thought about failure

This is ownership.

Weak Answer:
Me: "Walk me through this code."

You: "So this function takes the data and
returns... something. I wrote it a while
ago. It should work."

Me: "What does it return?"

You: "I'd have to run it to be sure."

Me: "Okay. Let's move on."

The conversation ends here.

Strong Answer:
Me: "Walk me through this code."

You: "This groups the transaction list by
category and returns an object keyed by
category name. I used reduce because it
produced a single grouped object in one
pass.

The reason I didn't use a simple loop is
that the grouping logic was getting nested —
reduce read cleaner to me at the time.

The failure I handled: null categories. We
saw them break in production, so line 12
falls back to 'uncategorised'.

If I rewrote it, I'd probably use a plain
loop — reduce is clever, but clever isn't
always clear for the next person."

Me: "Good. Let's talk about the API layer."

The interview continues.