Why should we hire you for this job?
answer
- one claim, said in a sentence
- closest evidence to the hardest task
- the second, different kind of proof
- what the resume does not show
- the honest gap and your plan
basics
~20 sAsks you to make your own case out loud. Give one claim, two pieces of evidence closest to the job's hardest task, one thing the resume does not show, and an honest note on what you would need early.
how to answer
5 beats- the claim, in one sentenceSay the thing you want repeated in the hiring debrief, tied to the job's hardest part. One sentence, no hedging verbs, no preamble about how many good candidates there must be.
- first evidence: the nearest thing you have donePick the item from your history closest to that hardest part and give it with a specific outcome. Nearness beats impressiveness; a smaller project in the same problem class outperforms a bigger one in a different world.
- second evidence: a different kind of proofVary the type rather than repeating the first. If the first was shipped code, make the second judgement, collaboration or something you did unasked, so the case rests on two legs.
- what the resume does not showName one working trait that is real and provable in your stories, such as being comfortable saying scope is too large. Skip generic virtues like hard-working, which carry no information.
- the honest limit and how you close itEnd with one real gap and a concrete first-month ask. Conceding something specific makes the whole case more believable than a flawless pitch does.
your answer
4 story prompts- Write your claim as one sentence a hiring manager could repeat in the debrief.
- List the two things you have done closest to this job's hardest task, one number each.
- Name a working trait your resume cannot show, then find the story that proves it.
- Decide the one limit you will concede, and the first-month ask that closes it.
draft and rehearse your own answer in a learn session
go deeper
This tests whether you can advocate for yourself without either deflating or overclaiming, and whether your self-assessment matches the evidence you present. The interviewer is listening for a case an advocate could repeat in the debrief. A strong answer selects rather than lists, attaches proof to every claim, and names one honest limit.
My case is that I have already done the smallest version of this job and nobody had to assign it to me. About six months into contributing to an open-source app that collects survey data on phones with no signal, I picked up the background upload bug nobody wanted. Reports were marked as sent and then quietly lost when the process was killed mid-handoff. I read the platform's background-work documentation properly, reproduced it with a harness I had to write first, and fixed the state machine. Lost-upload reports went from forty-one in a month to seven. The second half of the case is that harness. Before it, the sync path had no integration coverage at all, and I left eleven cases behind so the next person would not be reproducing failures by hand on a train with the antenna covered. That is the pattern I would bring: I take the unglamorous reliability work, and I leave tooling behind me. What I do not have is production on-call experience at your traffic. So in my first months I would want to be paired on releases rather than trusted alone with them, and I would rather ask for that now than discover it during an incident.
The claim is specific and provable, and the two evidence pieces are different in kind: a fix with a number, then tooling left behind. The closing limit is real and comes with a concrete ask. Dropping the number, or the unprompted framing, would flatten it into enthusiasm.
Three parts, quickly. First, I own the piece of this job that usually goes wrong. On the open-source data-collection project where I look after the sync module, I killed a feature I had personally argued for, multi-device merge, because plain single-device uploads were still failing twenty-three times per thousand. Building merge on top of that would have been building on sand. We shipped the retry rework instead and ended the cycle at six per thousand. Second, I can make that call where people can see it. I wrote the proposal to drop my own feature, absorbed the disagreement from two other maintainers on the thread, and we came out of it with a written rule for what earns a slot in a release, which we have used twice since. Third, the thing the resume will not tell you is that I am comfortable being the person who says the scope is too big while everyone in the room is excited. That is also the trade you would be making. I will be slower than some candidates to say yes to a roadmap item, and I will show up to that argument with the reliability numbers rather than a feeling.
The case rests on ownership of the role's failure-prone core, a decision made in public, and a named cost stated as a trade rather than a fake weakness. The written rule shows the decision outlived the moment. Without the second number the scope-cut claim would be unfalsifiable.
You are not expected to out-experience anyone. Make the case on trajectory and evidence of self-direction: something you built or fixed without being asked, and the speed at which you picked up the last unfamiliar thing.
Make the case on reliable delivery of the role's core task. Two shipped things close to the job, at least one with a number, plus what you can be trusted to own alone rather than shadow.
Argue at team level: what breaks less, ships sooner or gets decided faster because you are there. Include the cost of hiring you, such as a strong opinion about scope, stated plainly rather than hidden.
The case is leverage, not throughput. Name the class of problem you convert from recurring to solved, the people whose ceiling rises around you, and the judgement you bring on bets that will not resolve for a year.
saying these in an interview costs you the question
- Listing adjectives about yourself with no evidence attached to any of them
- Comparing yourself to imagined other candidates you know nothing about
- Claiming to be a perfect fit with no gap anywhere
- Answering with how much you want the job rather than what you would deliver
- Rambling through the whole resume instead of picking the two closest items
- Apologising your way through the answer and never making a claim at all
- Who do you think we are comparing you to, and where do they beat you?Do not pretend nobody beats you. Name a plausible strength another candidate would bring, concede it without hedging, then say why your combination still serves this specific job. Confidence with a real concession lands far better than an answer that claims dominance across the board.
- What would we be trading off by hiring you?Answer with a genuine cost that is a consequence of a strength, not a rehearsed fake flaw. Say how you make it cheap for the team, for example by flagging it early or asking for a specific kind of pairing. Candidates who cannot name a trade sound unaware of themselves.
- What would you need from us in your first month to do that?Be concrete and modest: access, one named person to pair with, a first scoped problem, the on-call rotation only after a period. This shows you have thought about ramping as a shared cost rather than assuming you land fully formed.