# System Design and the Human Round

The rounds that don't involve a code editor feel like they don't "count" - like they're only checking if
you're a pleasant enough person to sit near. They count. They're evaluating skills that are harder to teach
than syntax and matter more once you're actually hired.

## System design is still a test of reasoning

A system design conversation - "design a URL shortener," "design a notification system" - has no single
correct answer, which throws people who expect interviews to have one. The interviewer is watching whether
you can take a vague requirement and turn it into a concrete plan: what are the pieces, how do they talk to
each other, where does it break under load, what did you deliberately leave out and why.

Treat it like a conversation, not a presentation. State assumptions out loud ("I'll assume we need this to
handle about a million requests a day - tell me if that's off"), start with a rough version, then add
complexity only where the interviewer pushes. Beginners often reach for buzzwords - microservices,
sharding, a message queue - before establishing that the problem needs them. Naming a database and
explaining why it fits beats naming five technologies you can't justify.

## "Tell me about a time" is not small talk

Behavioral questions feel like filler before the real interview, but they're measuring something coding
rounds can't: how you behave when something went wrong, how you handle disagreement, whether you take
ownership or point fingers. A vague answer ("we had a bug once and I fixed it") gives the interviewer
nothing. A specific one - what the situation was, what you specifically did, what happened, what you'd do
differently - gives them a real data point.

This is also where the earlier phases of working-as-a-developer skills show up in interview form. "Tell me
about a disagreement with a teammate" is really asking about the code-review instincts of staying curious
instead of defensive. "Tell me about a time you had to understand code you didn't write" is asking about
legacy-code instincts. Prepare two or three real stories ahead of time so you're not improvising under
pressure.

## Good questions to ask them

The interview runs both directions. Asking sharp questions signals you're evaluating the job seriously, and
it gets you real information before you commit a year of your life to a team. Worth asking:

- **Team structure**: "How big is the team, and how is work split up?" Tells you if you'd be one of two
  backend engineers or one of thirty.
- **Code review norms**: "What does code review look like here - fast and light, or slow and thorough?"
  Ties directly to what makes review painful or pleasant day to day - see
  [Code Review Etiquette](/guides/code-review-etiquette) for what good review culture looks like from the
  inside.
- **On-call load**: "Is there an on-call rotation, and what's a typical week like?" A vague or uncomfortable
  answer here is worth noticing - see [Your First On-Call](/guides/your-first-on-call) for what a healthy
  rotation looks like versus a burnout machine.
- **How decisions get made**: "When there's a technical disagreement, how does the team resolve it?"

Asking these isn't adversarial. A good interviewer will answer them plainly, because they want the fit to
work too.

## Negotiating: the real version

Negotiating offers feels like a confrontation. It's usually a short, low-drama conversation, and skipping it
almost always costs money for no benefit to anyone. A few grounded facts:

- **Most initial offers have room.** Not infinite room, but companies rarely open with their absolute
  ceiling.
- **You don't need a competing offer to ask.** "Is there flexibility on the base salary?" is a normal
  sentence that recruiters hear constantly and don't take personally.
- **Silence and a plain ask both work.** You can say "I was hoping for something closer to X" and then stop
  talking. You don't need to justify it with a speech.
- **Know your floor before the call**, not during it. Deciding your minimum acceptable number under
  pressure, live, on the phone, produces worse decisions than deciding it the night before.
- **The worst realistic outcome is "no."** Offers do not get pulled for asking politely. That fear is far
  more common than the actual event.

You don't have to negotiate hard, or at all, if the offer already feels fair. But making the ask costs one
slightly uncomfortable sentence, and the alternative is wondering later if you left money on the table.

## Looking back

This is the last guide in this category, so it's worth naming the through-line. Reading legacy code,
asking good questions, giving and receiving code review, surviving on-call, and now interviewing well - none
of these are things a computer science degree teaches, and none of them show up on a resume as a bullet
point. They're the difference between someone who can write correct code alone in a room and someone who's
actually good to work with.

Technical interviews try, imperfectly, to catch a glimpse of that second thing in a few hours with a
stranger. It's a rough proxy. But the instincts underneath it - staying calm under uncertainty, communicating
while you think, asking instead of assuming - are the same instincts that make the job itself easier once
you're through the door. That part isn't a performance for an interviewer. It's the work itself.

```quiz
[
  {
    "q": "What is a system design interview mainly evaluating?",
    "choices": ["Whether you know the single correct architecture", "Whether you can turn a vague requirement into a reasoned, concrete plan", "How many technologies you can name"],
    "answer": 1
  },
  {
    "q": "Why is asking about on-call and code review norms a good move in an interview?",
    "choices": ["It makes you look difficult", "It gives you real information about daily work life before you commit, and signals you're evaluating the job seriously", "It's required small talk"],
    "answer": 1
  },
  {
    "q": "What's a realistic view of salary negotiation?",
    "choices": ["You need a competing offer or it's not worth trying", "A short, plain ask is normal, most offers have some room, and offers rarely get pulled for asking politely", "Negotiating is confrontational and best avoided"],
    "answer": 1
  }
]
```