# What Interviews Are Actually Testing For

A coding interview looks like a test of what you know. It's mostly a test of how you think. Those are
different skills, and confusing them is why so much interview prep goes to waste on the wrong thing.

Here's the gap: you can memorize the solution to "reverse a linked list" and still fail the interview,
because the interviewer wasn't scoring whether you produced the right answer. They were watching how you
got there - did you understand the problem before touching the keyboard, did you notice the edge case with
an empty list, did you explain your reasoning or type in silence until something worked. A memorized
answer delivered silently often scores worse than a struggled-through answer delivered out loud.

## Signal versus noise

Most interviewers - not all, but most - are checking for a short list of things:

- **Can you break a problem into steps?** Not "do you know the trick," but do you have a process when you
  don't immediately see the trick.
- **Can you communicate while thinking?** A teammate who mutters "I'm stuck" is more useful than one who
  goes silent for ten minutes.
- **Do you know when you're wrong?** Catching your own bug beats never introducing one, because it proves
  you check your work.
- **Can you take a hint?** If the interviewer nudges you and you adjust, that's a good sign. Interviews
  aren't solo exams - real work involves someone pointing things out.

None of this requires you to have seen the exact problem before. That's the part that gets lost: the
question is a vehicle, not the point. Two candidates who both eventually solve the same array problem can
get very different scores based on process alone.

## Why "know literally everything" is the wrong strategy

The instinct to grind hundreds of problems until you've "seen it all" comes from a reasonable fear - what if
they ask something I've never touched? But interview problems are drawn from a fairly small set of patterns
(two pointers, sliding window, BFS/DFS, basic DP, that kind of thing), and once you understand a pattern,
recognizing a new problem that fits it matters more than having solved that exact problem before.

Grinding five hundred problems without understanding the patterns underneath produces someone who
recognizes problems they've memorized and freezes on anything slightly different - which is precisely the
failure mode interviewers are trying to filter for. Depth on twenty to thirty problems, done slowly enough
to understand why each solution works, beats shallow exposure to five hundred.

There's also a ceiling on how much "knowing everything" helps. Interviewers calibrate difficulty to the
role. A mid-level backend interview is not trying to find out if you know a rare graph algorithm - it's
trying to find out if you can write correct, reasonably clean code under mild pressure. Overpreparing for
obscure algorithms while underpreparing for "explain your thinking clearly" is optimizing for the wrong
axis.

## What a good process looks like

Calibration helps with nerves - knowing what's normal means you can tell whether a bad experience was you or
the process. Signs of a healthy interview:

- The interviewer tells you the format ahead of time (how many rounds, what each covers).
- Questions are relevant to the actual job, not a flex of how clever the interviewer is.
- You're allowed to ask clarifying questions without it counting against you.
- Feedback, even a rejection, gives you something - "we went with someone with more X experience," not
  silence.
- The people you talk to seem like people you'd want to work with, not adversaries.

Signs of a bad one: trick questions with no real-world basis, interviewers who seem to be enjoying watching
you struggle, take-home assignments that would take a paid contractor a full week, or a black-box rejection
after five rounds with zero explanation. A bad interview process is weak evidence about your skill and
decent evidence about that company's engineering culture - it's data in both directions.

```quiz
[
  {
    "q": "What are most interviewers primarily evaluating during a coding round?",
    "choices": ["Whether you've memorized the exact problem before", "How you think through and communicate about a problem", "Typing speed"],
    "answer": 1,
    "explain": "Process and communication are usually weighted more heavily than a perfect, silent first answer."
  },
  {
    "q": "Why does grinding hundreds of problems without understanding patterns backfire?",
    "choices": ["It takes too much disk space", "It produces recognition of memorized problems but freezing on new ones - the opposite of what's being tested", "Companies penalize over-preparation"],
    "answer": 1
  },
  {
    "q": "Which is a sign of a healthy interview process?",
    "choices": ["You're marked down for asking clarifying questions", "The format and rounds are explained to you ahead of time", "Feedback is never given, win or lose"],
    "answer": 1
  }
]
```