"Why Should We Hire You?" A Method for the Closing Screen

Answer "why should we hire you?" by naming the role's two or three real needs, matching each to a piece of your own backed evidence, then stating the one comparison the interviewer cannot make without you in the room. This is not a confidence contest and it is not a list of adjectives. It is the summary-close, where the interviewer checks whether you can argue your own fit better than they can.

Short answer: Extract the top needs from the job itself, back each with a measurable result, and lead with the highest-weight match. A strong reply runs 30 to 60 seconds, uses the employer's own words for the problem, and ends on the value you add rather than the job you want.

The trap is that the question sounds like an invitation to praise yourself, so most people reach for "I am hardworking, a fast learner, and a great team player." Every other candidate says the same three things. The interviewer already knows you want the job. What they do not yet know is whether you understand what the job is really for, and whether you can prove you match it.

What the interviewer is actually checking

Harvard Business Review frames this question as a shift in perspective. As Joel Schwartzberg puts it, unlike "why do you want to work here?", this one asks you to lead with the employer's needs, not your own hopes: it "isn't about what benefits you so much as what benefits them" (Harvard Business Review, 2024). That single reorientation separates a strong answer from a weak one.

There are three things the interviewer is quietly scoring while you talk:

• Do you know what this role is for? If your answer would fit any job at any company, you have told them you did not read the posting.
• Can you back the claim? "I am detail-oriented" is an assertion. "I cut our checkout error rate from 2.1% to 0.3% in a quarter by adding contract tests to the payment path" is evidence.
• Can you compress it? The Ladders 2018 eye-tracking study found recruiters skim a resume for an average of 7.4 seconds before forming a view (HR Dive). The verbal version of this question is not much more forgiving. If your strongest match is buried in sentence four, it may never land.

The question is not "are you good?" It is "are you the answer to the specific problem we are hiring to solve?" Those are different questions, and only the second one gets offers.

So the work happens before the interview, not during it. You cannot improvise a match you have not prepared.

The three-need method

Treat your answer as a small optimisation. The role has a handful of needs, each with a different weight. You have a handful of proof points, each either backed by evidence or merely asserted. Your job is to cover the highest-weight needs with backed proof and lead with those.

Step one is to pull the needs from the source. The job description, the recruiter's phrasing, and anything the hiring manager stressed earlier in the loop are your inputs. If a requirement appears in the first three bullets, is repeated, or is written in the present tense ("owns", "drives", "is responsible for") rather than the nice-to-have future tense, weight it higher. Reading the posting closely is its own skill; the guide on reading a job description walks through separating the load-bearing requirements from the wish list.

Step two is to attach evidence. For each high-weight need, write one sentence of proof with a number in it. If you cannot put a number or a concrete outcome behind a need, mark it as a gap, because saying it out loud will read as a claim, not a credential.

Here is that logic as a small model you can run. It ranks the role's needs by weight, checks which ones you can actually back, and hands you the lines to lead with plus the gaps to shore up.

// Score how well your backed proof covers the role's real needs.
// A need is "covered" only when the matching proof has hard evidence,
// not just an assertion.
function pitchFit(needs, proofs) {
  const byNeed = Object.fromEntries(proofs.map((p) => [p.need, p]));
  const ranked = needs
    .map((n) => {
      const p = byNeed[n.need];
      const backed = Boolean(p && p.evidence);
      return { need: n.need, weight: n.weight, backed, line: p ? p.claim : null };
    })
    .sort((a, b) => b.weight - a.weight);

  const total = needs.reduce((s, n) => s + n.weight, 0);
  const score = ranked.filter((r) => r.backed).reduce((s, r) => s + r.weight, 0);
  const gaps = ranked.filter((r) => !r.backed).map((r) => r.need);
  const lead = ranked.filter((r) => r.backed).slice(0, 3).map((r) => r.line);

  return { score, coverage: `${score}/${total}`, gaps, lead };
}

const needs = [
  { need: "ship-reliability", weight: 5 },
  { need: "payments-domain", weight: 4 },
  { need: "mentoring", weight: 3 },
  { need: "greenfield-speed", weight: 2 },
];
const proofs = [
  { need: "ship-reliability", claim: "cut checkout errors from 2.1% to 0.3% in a quarter", evidence: true },
  { need: "payments-domain", claim: "owned the refunds ledger for two years", evidence: true },
  { need: "mentoring", claim: "I really enjoy helping teammates", evidence: false },
];

pitchFit(needs, proofs);
// => {
//   score: 9,
//   coverage: "9/14",
//   gaps: ["mentoring", "greenfield-speed"],
//   lead: [
//     "cut checkout errors from 2.1% to 0.3% in a quarter",
//     "owned the refunds ledger for two years"
//   ]
// }

The output tells you two useful things. Your lead lines are the two highest-weight needs you can actually prove, so those go first in your spoken answer. Your gaps are the needs you can only assert. Mentoring here is a real requirement you cannot yet back with a number, so either find a concrete example before the interview or do not build your answer around it.

Read as a table, the same role looks like this:

Coverage of 9 out of 14 is enough to build a confident answer, because you own the two heaviest needs outright. You do not need to cover everything. You need to cover the things that matter most, with proof.

A worked close, played out

Here is Ravi, a backend engineer, near the end of a loop for a payments platform team. The interviewer, Dana, asks the question. Ravi has done the pitchFit work above.

Dana: So, why should we hire you?

Ravi: Two reasons that map straight to what you have said this role is about. The first is reliability on the payment path. In my last role I owned checkout, and I brought our error rate from 2.1% down to 0.3% over a quarter by adding contract tests between us and the payment provider and killing a retry loop that was double-charging on timeouts. Your posting leads with "keep the payment path boringly reliable", so that is the exact muscle I have been building.

Dana: That is relevant. What is the second?

Ravi: Domain. I owned the refunds ledger for two years, including the reconciliation job that has to balance to the cent every night. Most engineers treat refunds as an afterthought, and it is usually where the quiet money bugs live. You are hiring into a small team, so someone who already knows where those bugs hide is worth more than someone you have to walk through it. I would not need the two-month ramp on the payments mental model.

Dana: Fair. Anything else?

Ravi: Honestly, I would rather be specific about two things I can prove than list ten I cannot. If mentoring or greenfield speed is a bigger part of this role than the posting suggested, I am happy to talk about where I am strong and where I would be learning.

Notice what Ravi did not do. He did not claim to be the best candidate, because he cannot know the other candidates. He named the comparison only he could make: the team saves the payments ramp because he arrives already knowing the domain. And he closed by inviting the interviewer to correct his read of the role, which signals he is easy to work with rather than rehearsed.

Answers that quietly sink the pitch

Most weak answers are not disasters. They are forgettable, which in a competitive loop is the same thing. These are the failure modes worth naming so you can hear yourself doing them.

The Muse frames the strongest version as the opposite of the generic recite: organisations hire because they have a problem, so "offer immediate relief for a particular pain point" and show you can make the interviewer's life easier (The Muse). That is the whole game. You are not the smartest person available. You are the fastest path to their specific pain going away.

One more discipline: keep it short. Indeed recommends supporting each accomplishment with a number where you can, and keeping the whole answer to two minutes or less (Indeed). Two minutes is the ceiling, not the target. Thirty to sixty seconds of dense, backed matching beats two minutes of hedging every time.

When your evidence is thin

The method assumes you have backed proof for the role's top needs. Career switchers, new graduates, and anyone returning after a gap often do not, at least not from a job with the same title. The fix is not to inflate weak claims. It is to substitute a different class of evidence and be honest about the swap.

The move is to answer the need behind the requirement, not the requirement's job title. A posting that asks for "three years of production Go" is really asking "can you ship reliable services without hand-holding?" If you shipped reliable services in Python, you can speak to the underlying need and be candid that Go itself is a ramp, not a gap in judgment. Interviewers discount a claim you overreach on far more than they discount a gap you name plainly.

Concrete substitutions that carry real weight:

• A project instead of a job. A side project or open-source contribution with users, tests, and a real decision you had to defend is evidence, even without a paycheck attached.
• Transferable proof from an adjacent field. A former teacher moving into product can prove they can explain a hard idea to a resistant audience, which is half of stakeholder work. Name the transfer explicitly so the interviewer does not have to make the leap for you.
• Behavioural evidence for a technical gap. If you cannot yet prove the technical bar, prove the operating temperament that closes it fast: how you take feedback, how you ramp, a time you learned a stack under deadline. The STAR framework guide covers structuring those stories so they land as evidence rather than anecdote.

The honest version of a thin answer still wins when it is specific: "I have not shipped at your scale, but here is the reliability habit I built at smaller scale, and here is how I would close the gap in the first month." That is a candidate a manager can picture succeeding. A bluffed answer is one they picture unravelling in week three.

The same question in different rooms

The question wears different clothes, and the wording tells you what to emphasise.

• "Why should we hire you over the other candidates?" This is an explicit invitation to name your differentiator. Do not badmouth hypothetical rivals. Name the one thing you bring that the average qualified applicant does not, as Ravi did with the payments domain.
• "Why should I hire you?" The first-person version usually comes from the hiring manager, not a recruiter. It leans slightly more personal, so it is fair to add a line about how you would make their team specifically better, not just the company.
• A recruiter screen versus an onsite. Early in the loop, keep it to the one or two headline matches; the recruiter is filtering, not deep-diving. On the final round, you can afford one layer more depth because the decision-maker is in the room.

Phrasing also varies by region and interview culture, and the register you use should follow the room. In more understated hiring cultures, common across parts of the UK, the Nordics, and Japan, a flat "I am the best candidate" can read as arrogance, so let the evidence carry the confidence and keep the framing modest. In more direct markets, a crisper statement of your edge is expected and a too-soft answer can read as weak conviction. The underlying method does not change worldwide. Only the volume knob on how boldly you state the comparison does. When in doubt, match the tone the interviewer has used with you so far.

This question is also close kin to "why do you want this job?". Keep them separate in your prep: that one is about your motivation and fit, this one is about the value you deliver. Answer them the same way and both come out generic.

Frequently asked questions

How long should my answer be? Thirty to sixty seconds is the sweet spot. Indeed puts the hard ceiling at two minutes. If you are past a minute, you are almost certainly listing instead of matching. Pick your two strongest backed points and stop.

What if I do not know the other candidates? You never do, and you should not pretend to. Reframe "over other candidates" as "the specific value I bring". Name the comparison only you can make, such as arriving already knowing the domain, and leave the invented rivals out of it.

Should I mention salary or benefits? No. Even if pay is your real motivation, this question is about what the employer gains, not what you take home. Keep compensation for the negotiation stage, where it belongs.

Is it fine to sound rehearsed? Prepare the substance, not the script. Memorising a paragraph word for word tends to come out robotic and falls apart the moment the interviewer phrases the question slightly differently. Know your two matches cold and let the sentences form live.

What if I genuinely lack a key requirement? Answer the need behind it, be candid that the specific tool or title is a ramp, and show the habit that lets you close it fast. A named gap with a credible plan beats an overclaim that collapses under one follow-up question.

Can I turn the question back on the interviewer? You can close by inviting them to correct your read of the role, which reads as collaborative rather than scripted. Save your prepared questions for the end of the interview; the guide on smart questions to ask your interviewer covers what earns you signal there.

What if I am asked this for a non-technical or customer-facing role? The method is identical. Extract the role's needs, back them with outcomes, and lead with the heaviest match. For persuasion-heavy roles such as solutions or sales engineering, the way you deliver the answer is itself part of the evidence, so treat it as a live demo of how you would pitch to a customer.

Where to take this next

• Reading a job description to extract the real, weighted needs your answer has to hit.
• Answering "why do you want this job?" so you keep the motivation question and this value question distinct.
• The STAR framework for behavioural interviews to turn each match into backed evidence rather than a claim.
• Smart questions to ask your interviewer to finish the conversation on signal, not filler.