How Interviewers Know You Actually Built Your Code

STRONG OPENER — FIRST 90 SECONDS:

Interviewer: "Build a function that finds
the user with the highest score."

Candidate: "Sure. Let me clarify the shape of
the data before I write anything.

The input: an array of users with an id and a
score, or a map? And how many users — 100 or
100K? Does it need to handle ties — two users
with the same score?

Assuming an array of 50K users with possible
ties, I'd do one pass, not a sort. A sort is
O(n log n); a single pass is O(n). I'd track
the max and the list of users who tie for it.

I'll also handle the empty array — the
function should return an empty list, not
null, because the caller iterates the result.

Let me write it and walk you through the
decisions as I go."

What the interviewer thinks in 90 seconds:
- "They clarified the input shape before
  coding." ✅
- "They named the complexity trade-off:
  one pass vs. sort." ✅
- "They named the tie case." ✅
- "They named the empty-array edge case." ✅
- "I want to see how they write this." ✅

Signal: strong. The rest of the interview
confirms it.

WEAK OPENER — FIRST 90 SECONDS:

Interviewer: "Build a function that finds
the user with the highest score."

Candidate: "OK, so I'd do a for loop, and
inside the loop I'd compare the scores, and
then return the max. I'd use a variable to
track the highest score."

Interviewer: "What if two users have the same
score?"

Candidate: "Um, it would return the first
one, I guess."

Interviewer: "What if the array is empty?"

Candidate: "It would... throw an error? I
didn't think about that."

What the interviewer thinks in 90 seconds:
- "They started with the loop, not the
  input." ❌
- "No complexity reasoning." ❌
- "No tie handling." ❌
- "No empty-array handling." ❌
- "I'll ask follow-ups and see if this is
  memorization or understanding." ⚠️

What happens next:
- The interviewer asks "How would you handle
  the empty array?"
- The candidate says "I'd add an if
  statement."
- The interviewer asks "What should it
  return?"
- The candidate pauses.

Signal: weak. The rest of the interview
is an uphill climb.

Why it failed:
❌ Loop before input shape
❌ No complexity reasoning
❌ No tie case
❌ No edge cases
❌ The first 90 seconds signaled tutorial,
  not build

DATA STRUCTURE ANSWER — WHAT DECIDES:

Interviewer: "Why did you choose a Map here?"

WHAT THE CANDIDATE SAYS:
"Three reasons, and one cost.

Reason one: the lookup pattern. We look up by
user ID on every request — about 10K lookups a
second at peak. With a list, each lookup is
O(n) — 50K comparisons. With a Map, it's O(1).

Reason two: the insert pattern. We build the
index once at startup, then read it. That's a
Map's best case: O(1) insert, O(1) lookup.

Reason three: readability. `users.get(id)` is
clearer than a linear search with a break.

The cost: a Map uses more memory — about 2MB
for 50K entries, versus 800KB for the list.
I accepted that because the lookups dominate
and 1.2MB is nothing on a server with 4GB.

The trade-off I'd revisit: if the list were
sorted and we could binary search, the list
would use less memory and still be O(log n).
But binary search needs a sorted input, and
the input isn't sorted — sorting it once is
O(n log n), which is worse than the Map's
O(n) build.

I can show you the benchmark — the Map is
about 40x faster for the lookup path."

What the interviewer thinks:
- "They named the lookup pattern with
  numbers." ✅
- "They named the complexity." ✅
- "They named the cost: 2MB vs. 800KB." ✅
- "They named the alternative: binary
  search." ✅
- "They have a benchmark." ✅

Signal: confirmed build.

Why it decides:
✅ Lookup pattern is quantified
✅ Complexity is named
✅ Memory cost is named
✅ The alternative is rejected with a
  reason
✅ Evidence is available

EDGE CASE ANSWER — WHAT DECIDES:

Interviewer: "What happens with an empty
input?"

WHAT THE CANDIDATE SAYS:
"Three cases, and each has a different
behavior.

Case one: an empty list. The function returns
an empty list, not null — the caller iterates
the result, so null would throw a
NullPointerException. That's a real bug I hit
once, and it took 20 minutes to trace.

Case two: a single element. The function
returns that element — no special case
needed, the loop handles it.

Case three: a null input. The function throws
an IllegalArgumentException with a message —
not a NullPointerException, because the message
tells the caller what went wrong.

The trade-off: throwing on null is stricter
than returning an empty list. I chose stricter
because a null input is a caller bug, not an
empty state — silently returning an empty list
would hide the bug.

The test: I wrote three tests, one per case.
The empty-list test is the one that would have
caught the NullPointerException I hit.

I can show you the tests and the exception
handling."

What the interviewer thinks:
- "They named three cases with distinct
  behavior." ✅
- "They named the real bug they hit." ✅
- "The trade-off is named: strict vs.
  lenient." ✅
- "The test covers the edge case." ✅
- "This is someone who has shipped." ✅

Signal: confirmed build.

Why it decides:
✅ Three cases with behavior
✅ A real bug is named
✅ The trade-off is named
✅ A test covers the case
✅ Evidence is available

DEBUGGING — STRONG VS. WEAK SIGNAL:

Scenario: "This function returns wrong
results intermittently. Find the bug."

WEAK SIGNAL:
"I'd add some print statements and see what
comes out. Or maybe restart and try again."
What the interviewer thinks:
- "That's not a hypothesis, that's a hope."
- "They're guessing at the fix, not reading
  the code."
- Signal: weak.

STRONG SIGNAL:
"Let me read the function and form a
hypothesis before touching it.

The input is a list, and the function mutates
it while iterating — it removes items from the
same list in the loop. That's the classic
intermittent bug: the iterator's index skips
an item after each removal, so some items are
never processed.

The fix: iterate over a copy, or collect the
items to remove and remove them after the
loop. I'd use the second — collect and remove
— because it's a single pass and doesn't copy
the list.

The test: I'd write a test with a list where
the bug reproduces — say, [1, 2, 3, 4, 5] with
a filter that removes 2 and 4. On the buggy
version, 4 is skipped; on the fixed version,
both are removed.

The prevention: I'd add a lint rule that flags
list mutation inside a for-each loop — that's
the class of bug.

I can show you the fix and the test."

What the interviewer thinks:
- "They read the code before guessing." ✅
- "They named the real cause: mutation
  during iteration." ✅
- "The fix is specific." ✅
- "The test reproduces the bug." ✅
- "The prevention catches the class." ✅
- Signal: confirmed build.

Why it decides:
✅ Hypothesis before action
✅ The root cause is named
✅ The fix is specific
✅ The test reproduces the bug
✅ The prevention catches the class

TAKE-HOME REVIEW — STRONG VS. WEAK SIGNAL:

Scenario: "Review this take-home. The
candidate built a REST API."

WEAK TAKE-HOME:
- One controller class with everything
- No tests
- No error handling
- Hard-coded database password
- No README

What the interviewer thinks:
- "It runs, but it's a demo."
- "No tests, no error handling, no
  structure."
- "I can't tell if they can work on a
  real codebase."
- Signal: no-hire for mid/senior.

STRONG TAKE-HOME:
- Layers: controller, service, repository
- Tests: 18 tests — service tests with
  mocks, controller tests with MockMvc,
  one integration test with Testcontainers
- Error handling: a @ControllerAdvice with
  typed error responses; a failed write
  rolls back the transaction
- Config: environment variables, a
  production profile, no secrets in the repo
- README: setup, the design decisions
  (chose Postgres over SQLite because of
  concurrent writes), the trade-offs (chose
  polling over websockets to keep the
  deploy simple), and a "what I'd do with
  more time" section

What the interviewer thinks:
- "Layers separate concerns." ✅
- "Tests cover service, controller, and
  integration." ✅
- "Error handling is thoughtful." ✅
- "Config is safe." ✅
- "The README explains decisions and
  trade-offs." ✅
- Signal: strong hire.

Why it decides:
✅ Layers, not one class
✅ Tests at three levels
✅ Error handling with rollback
✅ Safe config
✅ README with decisions and trade-offs
✅ A named next step

Code Build-Proof Checklist:

FIRST 90 SECONDS:
☐ Name the input shape and scale
☐ Name a data structure choice and its cost
☐ Name an edge case before coding
☐ Avoid "I'd use a for loop and then…"

WHAT DECIDES:
☐ Explain the complexity trade-off: O(n)
  vs. O(n log n)
☐ Name edge cases with behavior: empty
  returns [], null throws
☐ Name failure handling: retry, rollback,
  typed error
☐ Name the alternative you rejected and
  why

WHAT CONFIRMS:
☐ Show a test that reproduces a bug
☐ Show a benchmark or a profile
☐ Name the prevention: a lint rule, a
  test, an alert
☐ Answer "what breaks?" without pausing
☐ Explain what you'd do with more time

RED FLAGS:
❌ Loop before input shape
❌ No complexity reasoning
❌ No edge cases
❌ "I didn't think about that"
❌ No tests
❌ Hard-coded secrets
❌ No README
❌ "I restarted it and it worked"

Why this works:
- The first 90 seconds set the signal
- The rest of the interview confirms or
  overturns it
- Data structure reasoning, edge cases,
  and failure handling are the three
  things that can't be faked

30-DAY BUILD PLAN (FOR CANDIDATES):

Week 1 — Input drills
☐ Pick 3 functions you've written
☐ For each, write the input shape, the
  scale, and the output shape
☐ Record yourself explaining each in
  90 seconds
☐ Cut every sentence that starts with
  "I'd use a for loop"

Week 2 — Data structures
☐ For each function, name the data
  structure and the cost
☐ Write the complexity: O(n), O(log n),
  O(1)
☐ Write one alternative and why you
  rejected it
☐ Re-record with the reasoning included

Week 3 — Edge cases
☐ For each function, list 3 edge cases
☐ For each, write the behavior: empty
  returns [], null throws
☐ Write a test for each case
☐ Add the edge cases to your notes

Week 4 — Mock interviews
☐ Run 2 mock interviews with a peer
☐ Ask them to challenge: "What about the
  empty case?" and "Why this data
  structure?"
☐ Re-run with stronger edge cases and
  trade-offs
☐ Compare the two recordings

Signs it's working:
✅ You name the input shape before coding
✅ You name the data structure and its
  cost
✅ You name an edge case before coding
✅ You name a test that reproduces a
  bug
✅ You can answer "what breaks?" without
  pausing
✅ The interviewer asks "what else?" instead
  of "did you build this?"