The fastest way to lose a hiring manager is to answer “Why do you want to work here?” with a sentence that would fit any company on earth. “I love your culture, the mission speaks to me, and I want to grow” applies equally to Google, a Series A startup, and a regional bank, which is why it lands as nothing. Your interviewer has heard it forty times this quarter and already knows it tells them zero about you.
The question looks soft, almost like small talk, so people prep hard for the system-design round and wing this one. That’s backwards. This is one of the few moments in a loop where the interviewer is measuring something you fully control: whether you did the work.
What the question is actually checking
Two things, mostly. First, did you spend even thirty minutes learning what this company does past the homepage. A recruiter can tell inside one sentence whether you read the job description and the engineering blog, or whether you fired off two hundred applications and this is number 147. Second, and this weighs more for the hiring manager, is your reason durable. They’re trying to predict whether you’re still here in eighteen months or whether you bounce the day a recruiter dangles ten percent more. “The comp is good” is a fair answer, but it’s also one that evaporates the moment someone offers better comp.
There’s a version of this question at every stage, and they aren’t the same question. The recruiter screen (“So what drew you to us?”) filters for basic effort and fit. The hiring-manager version (“Why this team, and why now?”) wants your reason to connect to what their team specifically builds. A senior interviewer sometimes sharpens it: “You’re at a company most people would love to work at. Why leave?” That one is really asking what you’re running from, and whether it will follow you to their team.
The wording you’ll hear is worth recognizing, because each variant is fishing for something slightly different:
- “Why us, and why now?”
- “What made you apply to this team specifically?”
- “You’ve got other options. Why would you pick us?”
- “What do you already know about what we do here?”
Research that takes an hour and beats everyone winging it
Most candidates read the About page and stop. Clearing that bar is cheap. Open the company’s engineering blog and read the two most recent technical posts. Look at their public GitHub, their changelog, their status page history if it’s public. If they raised a round or shipped something real in the last quarter, know what it was and have a take on it. If you know who’s interviewing you, spend five minutes on what they’ve built or written.
The point isn’t to recite trivia. It’s to find one real thing you can point at and explain why it matters to you specifically. Here’s where I’d actually spend the hour.
| Where to look | What to pull from it | How it shows up in your answer |
|---|---|---|
| Engineering blog | A recent technical decision, migration, or outage writeup | Name the specific post and the problem it solves that you care about |
| The job description, the real duties rather than the boilerplate | The actual stack, scope, and what this role owns | Mirror the real work back and tie it to something you’ve done |
| Changelog, release notes, or the product itself | What shipped recently and how fast they move | Prove you tried the product and noticed a specific detail |
| Funding and news from the last six months | Stage, direction, and what the money is for | Signal that you understand the company’s trajectory and what’s coming next |
| The interviewer or team leads | Talks, papers, or open source they maintain | One specific, non-creepy reference to their work |
| levels.fyi, Blind, Glassdoor | Comp bands and culture signals | Calibration for you, not material to quote in the answer |
The shape of an answer that holds up
A strong answer has three moving parts and runs about sixty to ninety seconds. Open with the specific hook, the one real thing you found. Connect it to evidence from your own background so it’s clearly yours and not lifted off the careers page. Close on what you’d contribute, framed as the work rather than as a favor they’d be doing you.
“I’ve been following how your platform team rebuilt the deploy pipeline. That writeup on cutting build times from twelve minutes to under two hit a problem I lived at my last job, where slow CI was quietly killing our velocity and I ended up owning the fix. Doing developer-experience work at your scale, where shaving a minute pays off across a few hundred engineers, is the work I want to be doing. I shipped internal tooling that three other teams picked up, and I want more of that, not less.”
Look at what that does. It names a real artifact, the deploy writeup. It backs the interest with a specific past experience. It ends on contribution. Swap in your own thread and it survives the follow-up, which is the real test. Interviewers often poke: “What did you make of the approach they took?” A scripted answer dies there. A real one keeps talking.
New grads worry they have no experience to anchor to. You don’t need a war story. A class project, an open-source contribution, or a specific reason the problem space caught you works fine, as long as it’s real and yours.
“I built a small distributed key-value store for my systems course, and debugging the replication was the most fun I’d had all year. Your team works on the storage engine, and that post on how you handle rebalancing is exactly the kind of problem I want to spend the next few years getting good at. I’d rather learn it from people who’ve solved it at a scale I’ve only read about.”
When you don’t have a clean reason
Sometimes the true answer is “I got laid off and I need a job,” or “I’ve never used your product,” or “you’re famous and it’ll look good on my resume.” None of those belong in your spoken answer, but you don’t have to fake enthusiasm you don’t feel either. Find the part that’s real. If you were laid off, the durable reason is usually a specific kind of problem you want to work on next, so anchor on the problem, not the layoff. If you’ve never touched the product because it’s B2B infrastructure no consumer would use, talk about what’s technically interesting in the problem domain. Interviewers can smell manufactured passion, and it reads worse than plain, specific interest.
For a big prestigious company, skip the mission recital. Everyone in that interview loop has read the same mission statement, and repeating it back signals nothing. The candidate who says “I want to work on ranking because it’s one of the few places a single model change moves a number a billion people see, and I’ve done ranking at smaller scale and want the harder version” beats the one quoting the founder’s blog post.
Why a generic answer costs more in 2026
A couple of years ago you could get away with a polished, vague answer, because the bar was low and the interviewer was tired. That’s changed. A lot of candidates now paste the question into an AI tool and read back the result, and those answers share the same shape and the same vocabulary. Interviewers have started clocking the pattern the way a teacher clocks a bought essay. The tell is an answer that’s fluent and totally non-specific, stuffed with “technical depth” and “engineering culture” and “hard problems” with nothing concrete underneath.
The counter is the thing that always worked, except now it’s the only thing that works: one concrete, checkable detail a generator wouldn’t have known to include, tied to something real you did. Follow-up questions are where scripted answers come apart, and good interviewers ask them on purpose. If you actually read the engineering post, “what did you make of their approach” turns into a conversation. If you didn’t, it’s a cliff you walk off.
Prep this the same night you prep the coding round. Pick your one real hook, write the two sentences of your own experience that back it up, and know it well enough to defend under a follow-up. That’s fifteen minutes of work most of your competition skips, which is exactly why it’s one of the cheapest edges in the whole loop.
Practice the behavioral round:
