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 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 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 honest 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.

[
  {
    "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
  }
]

← Phase 2: The Coding Round Without the Panic · Guide overview