Why do you want this role, specifically?
answer
- two specifics from the job description
- evidence you have done that work
- what you take off the team
- what the role gives you next
- toward this, not away from that
basics
~10 sTests whether you want this job or any job. Answer with two or three specifics from the posting, evidence you have already done that kind of work, and what the role gives you next.
how to answer
4 beats- the hook: the part of the role you actually wantOpen with one or two concrete elements of the posting, not adjectives about the team. Detail proves you read it: the ownership boundary, the platform, the reliability problem, the users.
- proof: where you have already done this workAttach evidence to the hook immediately, with one number if you have one. Shipped work is strongest, self-directed work is next, and unbacked interest is the weakest grade.
- what the team gets from youSay what you would take off their plate, in the scope your level supports. This is the half most candidates skip, and its absence is what makes an answer sound like tourism.
- the forward line: what this role gives you nextOne sentence naming a capability you do not have yet and that this role plainly develops. Keep it short, and keep it about the work rather than a title or a timeline.
your answer
4 story prompts- Open the posting and mark the three lines you can back with something you have actually shipped.
- Pick one number from your last year that proves you can do the role's core task.
- Write one sentence naming what this role gives you that your current one cannot.
- Reuse the project from your tell-me-about-yourself close here, re-angled at this posting's ownership scope.
draft and rehearse your own answer in a learn session
go deeper
This probes motivation quality and self-knowledge. The interviewer wants to know whether you understood the job as described, whether the move is toward this work rather than away from your current one, and whether your reasons will survive the unglamorous parts of the role. A strong answer shows selectivity backed by evidence, not enthusiasm.
Two things pulled me toward this one. The first is that the posting puts offline behaviour at the centre instead of treating it as an edge case, and that is what I have spent the last year inside. I help maintain the upload queue in a community-maintained offline-first survey app, six of us keep it alive, and my first real contribution replaced a naive retry loop with a bounded queue and backoff. Failures on flaky connections went from 9.4 percent of upload attempts to 2.1 percent across two sprints. The second is that you ship to devices nobody can reach after release. That forces a kind of care I like. When the maintainers cut the conflict-merge screen out of that release to hold the date, I wrote the plain conflict log that replaced it, and I still think the trade was right even though it was my favourite part of the design. What I want next is to do this beside people who have done it much longer. I have learned one queue well, but I have never owned a data migration across a fleet of devices already in the field, and this role would put me in the room where that happens.
The signal is in the proof beat: a specific contribution with a non-round number, in the same problem class as the role. Naming the cut he disagreed with adds credibility. It would downlevel further if the forward line asked for growth in the abstract instead of one named capability.
I read the posting as a sync-reliability job with a product surface on top, and that is the shape of work I have been steering toward on purpose for about two years. The concrete reason is the ownership line you describe: one team holding the client, the sync protocol and the server contract. Most of my frustration in my current job comes from arguing across a boundary I do not control, and I have watched fixes sit for a quarter because they needed agreement from three groups. The last release cycle on the open-source field-data project I help run was the opposite of that. We had fourteen issues tagged and reliability was drifting, so I wrote the case for cutting to five, all of them in the upload path, and took the argument on the thread rather than in private. We closed the cycle at 1.9 sync errors per hundred sessions, down from 6.8. What you would get from me early is that triage instinct and someone who will write the reasoning down. What I want from it is the part I cannot get where I am now, which is owning that decision on a product with paying users and a pager, instead of on a project people work on after dinner.
Strength here is selectivity: he names a structural feature of the role, ties it to a lived frustration, and backs it with a scope-cut he argued in public with a measured outcome. The both-directions close keeps it from reading as tourism. Vagueness about the ownership line would drop it a level.
Anchor on the work itself: the lines of the posting you can already point at coursework, a side project or a first job for. Curiosity is acceptable currency at this level, but only if you name what you have already taught yourself unprompted.
Show that you chose this role rather than applied broadly. Name the ownership boundary, product surface or reliability problem in the posting, and match it to something you shipped end to end with a peer or two.
Speak at team scope: what this team is trying to build, where you would take load off it inside a quarter, and which parts of the role others avoid that you actively want, such as on-call, the release process or an inherited system.
Tie the role to a direction you can move. Name the technical bet the posting implies, say whether you agree with it, and describe the mechanism you would leave behind that outlives your first project.
saying these in an interview costs you the question
- Generic praise that would fit any posting at any employer
- Reciting the job description back with no evidence you have done that work
- Talking only about what you get and never about what the team gets
- Framing the move as escape from your current job rather than pull toward this one
- Naming a technology you want to learn with no sign you have started
- Answering about the industry or the salary band instead of the role
- What part of this job do you think you would enjoy least?Answer it honestly and small. Pick something real but survivable that the role genuinely contains, say why it does not deter you, and show you have done a version of it before without complaining. Refusing to name anything reads as either flattery or as not having read the posting.
- If this same team were working on a different product, would you still want it?The probe checks whether your motivation is durable or attached to one shiny thing. Say which layer of your answer survives the swap, usually the problem class, the people or the ownership scope, and which layer does not. A candidate who claims everything would be identical sounds indifferent.
- What would make you turn this role down?Give one or two real conditions in calm language, framed as fit rather than demands, and keep them relevant to the work: no ownership of what you ship, or a scope narrower than described. Avoid turning this into an early negotiation, and never answer with nothing would.
## One answer, many costumes This prompt arrives in many costumes and they all want the same thing: - what interests you about this position, - why this team, - what caught your eye in the posting, - why are you applying to us for this and not for something more senior. Treat them as one answer with different entry points. The interviewer is deciding two things at once. 1. First, whether you read the job description and understood the job it describes, because a candidate who did not will be surprised by the actual work and leave. 2. Second, whether the role is **a step you want rather than a step available**, because motivated people ramp faster and stay through the boring quarters. ## The weak versions - The weak version is **a mirror**. It hands the posting back as adjectives: challenging problems, great team, room to grow, modern stack. Nothing in it could not be said about any job, and the interviewer hears an applicant who applied widely. - The second weak version is **the escape story**, where every sentence is really about what is wrong where you are now. Even when the complaints are fair, they teach the interviewer nothing about the job in front of you, and they invite them to imagine how you will describe them in a year. ## The strong version is specific and two-directional - **Specific** means you can quote the role back at a level of detail that only a careful reader has: the ownership boundary, the platform, the reliability problem, the fact that one team holds both the client and the contract. - **Two-directional** means you cover both what pulls you and what you take off their plate. A pull with no contribution reads as tourism. A contribution with no pull reads as a candidate who would accept anything. ## Three grades of evidence Evidence is what separates it from a nice speech, and it comes in three grades. 1. **Shipped work** is the strongest: something you built that resembles the role's core task, with a number attached. 2. **Self-directed work** is next: a contribution, a project or a deep dive you did without being assigned it, which is the only evidence available to most career switchers and most juniors, and it is genuinely persuasive because nobody made you do it. 3. **Stated interest alone** is the weakest grade, and if it is all you have, say it plainly rather than dressing it as experience. ## How the bar moves The bar moves with level in a predictable way. - **Early on**, the interviewer is checking that you understand what the day looks like and that your curiosity has already produced something. - In the **middle**, they are checking selectivity: did you choose this, and can you match your shipped work to the posting line by line. - At **senior level** the question quietly becomes a team question, and the answer should include what you would relieve the team of in the first quarter and which unpopular parts of the scope you want. - At **principal level** it becomes a direction question, and the answer should engage with the bet the role implies rather than accept it. ## One structural note Keep the forward-looking line short and specific. What this role gives you next is one sentence, not a paragraph of career philosophy, and it should name **a capability rather than a title**. Ending on growth in the abstract undoes the specificity you just spent ninety seconds earning.