Why Should We Hire You: You're Answering the Wrong Question

You've been in the interview for 45 minutes. You've explained your architecture decisions, survived the behavioral questions, maybe even impressed yourself a little. You're in the home stretch. Then the interviewer asks: "So, why should we hire you?"

And you watch yourself recite your resume. Out loud. To the person who has been staring at it for the last 45 minutes.

This is the trap. Almost every candidate falls in, and almost none of them notice until they're in the elevator wondering why they just summarized their own LinkedIn page to someone who already read it.

The interviewer already has your resume. They've heard your answers. When they ask this question, they're not asking for a sixth STAR story or a list of your technical skills. They're asking whether you can, under pressure, construct a persuasive argument for yourself. That's a completely different skill.

Three Questions the Interviewer Is Actually Asking

"Why should we hire you?" is three questions wearing one trench coat.

First: Can you do this job? Skills, experience, specific technical background. This is the only question most candidates actually answer. Usually delivered as a full read-back of the resume, in case the interviewer missed anything the first six times.

Second: Will you fit here? Culture, working style, values. They're running a mental simulation: would this person be functional and pleasant to work alongside? A lot of technically strong candidates lose offers here because nothing in their answer suggested they had thought about what this team is actually like.

Third: Do you actually want this specifically? Not a job in general. Not "a software engineering role at a well-funded company." This team, this problem, this company. Candidates who've done real research stand out immediately from candidates who just want any offer. Interviewers notice within about thirty seconds. The tell is when someone could swap in any other company name and the answer wouldn't change.

Most answers hit the first question, gesture vaguely at the second, and skip the third entirely. A strong answer covers all three, in under 90 seconds.

The Best Answers Use What You Just Heard

The best answers reference what you actually heard during the interview, not what you memorized from the job post.

That gap matters. A job description is what someone finalized six months ago, reviewed by three committees, and stripped of anything remotely specific. What the interviewer told you during the last 45 minutes is what the team actually cares about right now. The two are not always the same.

When a hiring manager says "we're scaling out the data pipeline and the team has been stretched thin," that's live signal. When someone mentions "we've been trying to improve p99 latency," you can use that. When they say "we're looking for people who can operate with ambiguity," they mean it, and they're watching to see if your answer matches.

Prepare a generic baseline answer. Then replace as much of it as possible with what you just heard.

Something like: "You mentioned earlier that the backend team is understaffed on the observability side while you scale to new regions. That's basically where I've spent the last three years, specifically instrumenting distributed services at a similar scale and debugging the kinds of tail latency issues you described. I'd be able to contribute on that problem from day one."

That answer proves you were paying attention. It shows you process information and adapt. Both are things the interviewer is going to write down.

Treat It Like a Closing Argument

A lawyer's closing argument doesn't introduce new evidence. It takes everything already established and organizes it to create conviction. Your answer to this question works the same way.

You're not presenting new credentials. You're taking the best material from the last 45 minutes and assembling it into a direct case for why the fit is real.

Instead of scrambling to invent something new, you're recalling the conversation. What did the interviewer say they need? What did you say that landed? Which of your examples maps closest to their actual problem? That's your argument. It's also why candidates who weren't really listening tend to give worse answers here. They have no material to work with.

How to Answer: Three Parts, 90 Seconds

1. Qualifications claim. One or two sentences. Not "I'm a strong engineer." Something specific: "I've spent four years building backend infrastructure for real-time data pipelines at a company at about your current scale."

2. One proof point. A brief STAR example, not a full story. Thirty seconds: situation, what you did, result. Pick the one that maps closest to what the interviewer described as the actual problem.

3. Forward projection. What you'll do for them, not just what you've done before. "Based on what you described with the scaling work, I'd expect to be useful there from day one. I work well in environments where the platform is still being built."

That last piece answers the third hidden question. You're not just qualified. You want this specific thing.

Here's what this looks like assembled for a backend SWE role:

"Based on what we've discussed, there are three things that seem like a close fit. One is the distributed systems work: I've spent the last three years building and debugging distributed tracing infrastructure at a company scaling through a very similar growth stage. I specifically led the effort to reduce p95 and p99 alerting noise by about 40%, which you mentioned has been an ongoing issue. Two is team dynamics: I'm comfortable in a smaller team where engineers own systems end-to-end, which matches what you described. Three is pace: I don't need a lot of process to move fast, and the fact that you're still building the platform is exactly the kind of environment I've thrived in. I want to be here specifically because the observability problem is genuinely hard and the domain is one I find interesting."

If you want to practice an answer like this out loud and get rubric feedback on whether it actually lands, SpaceComplexity runs voice-based behavioral interview practice for exactly this.

Resume versus interview: polished suited man labeled THE RESUME, Kevin Hart looking caught off-guard labeled THE INTERVIEW

Your carefully prepared pitch on paper. What actually comes out after 45 minutes of live questions.

Five Ways to Waste the Question

This is where interviews go to die quietly.

1. The resume recap. "I have five years of backend experience, strong Python and Go skills, and I've worked on distributed systems at scale." They have your resume. They've read it. This tells them nothing new and signals you didn't understand what was being asked. It's the interview equivalent of responding to an email by forwarding the email back.

2. The humility spiral. "I think I'd be a great fit... I mean, I'm a hard worker and I really care about the work... I'm always willing to learn..." This reads as extreme modesty or a complete lack of preparation. The question is an explicit invitation to advocate for yourself. If you decline the invitation, the interviewer notices, and not in a good way.

3. Generic company praise. "I've always admired this company's culture of innovation." If you can swap in any company name and the sentence still works, it's not an answer. It wastes 15 seconds and makes it obvious you didn't do your homework.

4. No connection to what was discussed. If your answer could have been delivered before the interview started, you weren't listening. Every answer to this question should reference at least one specific thing the interviewer said that day. If you can't do that, you either weren't paying attention or you prepared something so rigid it couldn't absorb anything you actually heard.

5. Trailing off without conviction. "So yeah, that's basically why... I hope that answers the question." A closing argument doesn't end with a shrug. End with a declarative sentence: "That's why I think this is a strong fit." Then stop talking. Actually stop. The interviewer is not waiting for one more qualification.

Job interview truth table: "I'm a team player" translates to "I promise not to kill other employees", "I love a challenge" translates to "I hope this job is mostly routine", "I'm well qualified" translates to "I got the useless degree you require"

The polished generic phrases every interviewer has heard a thousand times, and what they actually signal. This is what waste reasons one through three look like in the wild.

What the Interviewer Does With Your Answer

There's a reason this question comes at the end. By that point, the interviewer has a preliminary verdict. Your answer isn't building a case from scratch. It's either confirming what they already think or introducing a conflicting signal they now have to reconcile with everything else they heard.

Research on interview decision-making shows that primacy effects are powerful. First impressions color what follows. But the end of the conversation is the last thing written down, and the last thing the interviewer recalls when they open the feedback form an hour later.

A strong closing doesn't rescue a bad interview, but it absolutely cements a good one. A weak answer after 45 minutes of solid performance is a quiet, preventable mistake. The kind where feedback comes back as "strong technically, seemed a little unfocused toward the end" and you never know why.

Don't let that happen.

If the question you're actually dreading is tell me about yourself, that one has its own traps. Same goes for what is your greatest strength, which trips people up in a slightly different way. And if you're preparing for the full loop, why do you want to work here is worth reading back-to-back with this one.