Interviews · 7 min read

"Why should we hire you?" — a structure that actually works

This question sounds like an invitation to sell yourself, which is why most answers are a list of adjectives — hardworking, passionate, a fast learner, a team player — delivered with conviction and forgotten immediately. Every candidate says those things, so none of them distinguish anyone.

The question is narrower than it sounds. The interviewer is not asking you to prove you are impressive; they have your resume and you have reached this stage, so competence is already assumed. They are asking a comparative question: of the people we are seriously considering, why you?

That reframing does most of the work. A good answer is specific to this role, and could not be given by another candidate word for word.

Build the answer from the posting, not from your resume

Start with what the job actually needs. Read the posting again and find the two or three things it genuinely turns on — not the boilerplate list of technologies, but the problem being solved. A posting that repeatedly mentions scale, migration and reliability is describing a different job from one that mentions ambiguity, zero to one and first hire.

Then find where your experience meets those specific things. The overlap is your answer. Everything else you have done, however impressive, is noise for the purposes of this question.

If you cannot identify what the role turns on, that is worth solving before the interview rather than during it. Ask the recruiter what success looks like in the first year, and listen for what they emphasise unprompted.

The three-part structure

The version that lands has three parts and takes under ninety seconds. Name the core need as you understand it. Give the closest thing you have actually done, with a number. Then say what you would bring to this specific situation.

The first part matters more than people expect, because it demonstrates you have understood the job — which is itself a differentiator, given how many candidates are visibly applying to everything. Saying my read is that the hard part here is X invites correction if you are wrong, which is useful, and signals thought if you are right.

The second part is where credibility comes from. Not I have experience with migrations but I led the ledger migration at a company of similar size, zero downtime, and the reconciliation errors that had been costing two days a month went away. A number makes a claim checkable, and checkable claims are the ones that get remembered.

The third part connects the two without overclaiming. I would expect the first few months here to look similar — understanding the existing constraints before touching anything, then doing it incrementally.

What to leave out

Leave out adjectives about yourself. Hardworking, detail-oriented and passionate are self-assessments, and interviewers discount self-assessments automatically because everybody offers the same ones. If a quality matters, demonstrate it through the example rather than asserting it.

Leave out comparisons to other candidates. You do not know who they are, and unlike other applicants reads as arrogance without evidence. The comparative framing belongs in your head, not in the answer.

Leave out anything that is really about what you want. I would learn a lot here is a reason for you, not a reason for them. It can be a sentence at the end; it cannot be the answer.

The variants

The same material answers several questions. What makes you a good fit for this role is identical. Why are you interested in this position leans more on the third part. Tell me why we should pick you over someone with more experience is asking you to address a specific gap, and the answer is to acknowledge it plainly and then redirect to what you do have — trying to argue the gap does not exist is the failure mode.

For a career change, the structure holds but the second part changes: you are looking for the closest analogous problem you have solved in another context, and being explicit about what transfers. I have not worked in this industry, but the problem you are describing is one I have solved twice in a different one, and here is why I think it transfers.

Preparing it

Write it out, then cut it in half. Almost every first draft is twice as long as it should be, and length is the enemy here — a ninety-second answer that lands beats a three-minute one that covers more ground, because the interviewer stops absorbing after about a minute.

Then say it out loud. This particular answer sounds noticeably different spoken than written, and the difference is usually that the written version is too formal to say without sounding rehearsed. Rehearsed is the specific failure to avoid, because it undermines the credibility the specifics are meant to build.

Prepare one version per role rather than one universal version. The whole point is that it should not be portable, and a portable answer is by definition a generic one.

When you genuinely are not the strongest candidate

Sometimes you know you are underqualified on paper. The honest answer is more effective than the confident one: acknowledge what you lack, be specific about what you bring instead, and say what you would do about the gap. On paper I am light on X. What I do have is Y, and I would expect to close the gap on X in the first few months by Z.

Interviewers respond well to this because it demonstrates self-awareness and because they have usually already noticed the gap. Pretending it is not there tells them you either cannot see it or will not admit it, and both are worse than the gap itself.

The short version

It is a comparative question, not an invitation to list your qualities. Name what the role actually turns on, give the closest thing you have genuinely done with a number attached, and connect it to their situation. Ninety seconds, spoken out loud beforehand, different for every role you apply to.

A worked example, taken apart

Consider a backend role where the posting keeps returning to reliability, an ageing payments system and a small team. A weak answer says: I am a strong engineer with five years of experience, I am passionate about clean code and I work well in teams. Everything in it is probably true and none of it is about this job.

The stronger version: My read is that the hard part here is changing a payments system that cannot go down, with a team small enough that nobody can be dedicated to it full time. That is close to what I did at my last company — I led the ledger migration with zero downtime, running old and new in parallel for six weeks and reconciling daily until the difference was zero, while still holding my normal delivery work. I would expect to start the same way here: understand what the current system guarantees before changing anything, then move it incrementally.

It is not longer than the weak version. It names the problem, gives evidence with a mechanism attached, and describes an approach. And critically, no other candidate could deliver it verbatim, which is the entire test.

What interviewers are listening for underneath

Three things, usually. Have you understood the role, or are you describing a generic job? Is your evidence real, meaning specific enough to ask follow-up questions about? And is your framing about them or about you — an answer built around what you would gain reads as someone who wants a job rather than this job.

The follow-up almost always targets the evidence. How long did the migration take, what went wrong, what would you do differently. Answers built on real work survive this comfortably, which is another reason to resist the temptation to reach for your most impressive story rather than your most relevant one.

Where it lands in the interview

This question usually arrives near the end, which means it doubles as your closing statement. If earlier answers went badly, this is the place to quietly repair the impression — not by referencing the stumble, but by making the strongest version of your case clearly.

Because of that placement, it is worth being the one answer you have genuinely prepared. Most candidates prepare for the technical rounds and improvise this, which is exactly backwards given it is the last thing the interviewer hears before writing their feedback.

Adapting it for a panel

In a panel interview the question is often asked by the most senior person present, and the others are listening for whether your answer speaks to their part of the job. A version aimed only at the hiring manager can land flat with the engineer or the stakeholder in the room.

The fix is small: after the core answer, add one clause that acknowledges the wider group. Something like — and I know part of this role is working closely with the analytics side, which is where the reconciliation work I mentioned actually lived. It costs eight seconds and it stops half the room feeling talked past.

The question you should ask back

If the conversation allows it, follow your answer with a question that tests your own read: does that match how you see the role, or is the harder part somewhere else? This is genuinely useful rather than a rhetorical move. If they correct you, you have learned what the job is actually about and you still have time to address it before the interview ends.

It also demonstrates the thing the answer was trying to demonstrate — that you are thinking about their problem rather than performing a prepared piece — and interviewers notice the difference between a candidate reciting and a candidate engaging.

Related guides

Try JobStraight free →