It is the only question you can be certain of, and it is the one most people answer worst.
The reason isn't nerves. It's that the question sounds like an invitation to summarise a career, so candidates summarise a career — chronologically, from university forward, in about four minutes. By the time they reach anything relevant, the interviewer has stopped listening and started reading the CV again.
The question is not "who are you". It's "why are you the obvious person for this, and can you say it without me having to dig?"
The shape
Three beats, in this order. The order matters more than the content.
| Beat | What it does | Length |
|---|---|---|
| Now | What you do today, framed as the thing this role needs | 2 sentences |
| How you got here | The one or two moves that explain why you're good at it | 2–3 sentences |
| Why this | Why this role, this company, now | 1–2 sentences |
Starting with now rather than then is the whole trick. It puts your most relevant material in the first fifteen seconds, when attention is highest, instead of the last fifteen, when it isn't.
The "how you got here" section is not a career history. It's the selected history — the two moves that make your current strength make sense. Everything else is available if they ask.
Three worked answers
The senior hire
"I'm a backend engineer, and for the last three years I've mostly worked on systems that had already been built badly once — migrations, untangling, making things reliable that weren't. That's the work I'm best at and it's what caught my eye about this role.
I got there sideways. I joined my current company to build a new service, and six months in the payments system started failing under load and I was the one who volunteered. I've been doing some version of that since — the last project was splitting a monolith that eleven teams depended on, without a weekend outage.
What I'm after now is somewhere that's doing that at a larger scale, which is why I got in touch."
Ninety seconds. No dates, no job titles, no university. Every sentence is load-bearing for one claim: I am good at fixing systems that are already running.
The career changer
The instinct is to apologise for the change or to explain it in detail. Both are wrong: explain it in one clause, then spend your time on what transfers.
"I'm a data analyst now, and I came to it from six years in logistics operations. The short version of why is that I kept being the person building the spreadsheets that decided things, and eventually I went and learned to do it properly.
What that background actually gives me is that I've been the person on the receiving end of a dashboard at 6am trying to make a decision with it. I build for that person now, which mostly means I ask what the decision is before I build anything.
This role sits close to operations, which is unusual, and it's the reason I applied rather than to the three other analyst roles open this month."
The change is one sentence. The rest is an argument that the change is an asset, made concrete rather than claimed.
The gap, or the redundancy
Say it plainly, early, without a story. The awkwardness comes from hedging, not from the fact.
"I was a product manager at a fintech until March, when the company cut the product team — about forty of us. Since then I've been doing two things: a contract project for a former colleague's startup, and finally learning enough SQL to stop asking analysts for everything.
Before that, four years in payments products, mostly the unglamorous half — disputes, refunds, the flows that only get attention when they break.
I'm looking for somewhere I can go deep on a product rather than wide across five, and yours is one of the few roles I've seen that's actually scoped that way."
The single most common failure is ending on the past. A chronological answer finishes with your current job, which the interviewer already knows about, and leaves the connection to this role unmade — so they have to make it themselves, and they may not. Ending on "why this role" hands them the conclusion you want. It also, usefully, ends the answer on a note that invites a follow-up rather than silence.
What changes between rounds
The same three beats, weighted differently. Most people deliver one version all process and it fits only one of these rooms.
| Round | What they want | What to lengthen |
|---|---|---|
| Recruiter screen | Whether you match the brief, and whether you're serious | "Why this" — they're screening motivation and fit against a list |
| Hiring manager | Whether you can do the work | "How you got here" — one concrete thing you did, with a result |
| Panel / peer | What you'd be like to work with | "Now" — how you actually work, who you work with |
| Executive / final | Judgement and scope | All three, compressed to 45 seconds, then stop |
The executive version is the one people get wrong most often. Senior people ask this question as a test of compression, and a three-minute answer has already failed it regardless of the content.
The chronology
“So I studied computer science at — I graduated in 2016, and my first role was at a consultancy where I worked on a few different projects, mostly in Java, and then after about two years I moved to…”
Four minutes, eleven facts, no claim. The interviewer's problem is that they now have to work out which parts matter, which is the job they were hoping you'd do for them.
The claim, then its evidence
“I'm best at systems that were already built badly once. Here's the two-sentence version of how I got there, and here's why this role specifically.”
One claim, selected evidence, a reason for being in the room. It also sets the agenda: the next question is usually about the thing you chose to highlight, which means you're being interviewed on your own ground.
Saying it out loud
Three delivery problems, in the order they cost you.
Starting with "so, um, I guess…" — the first four words set the register for the whole answer. Start with a noun: "I'm a backend engineer." You can practise just the first sentence and it improves the whole thing, because the confident opening changes what your voice does afterwards.
Not knowing where it ends. Most rambling answers are not badly structured; they're answers whose author doesn't know how to stop. Decide your last sentence in advance. When you reach it, stop, even if it feels abrupt — the silence reads as composure, not as a gap: why silence sounds professional.
Memorising it word for word. A memorised answer is audible, and worse, it collapses if you're interrupted. Memorise the three beats and the last sentence; improvise the rest. That's enough structure to keep you out of trouble and enough freedom to sound like a person.
If English isn't your first language, the thing to rehearse is not vocabulary — it's the transitions between the three beats, because that's where hesitation lands and where hesitation sounds like uncertainty about the content rather than about the word. The related habit is cutting the filler that gathers at the start of each beat: how to reduce filler words.
For a role-specific version with a fully worked example, the QA one is here: tell me about yourself for QA engineers.
Building yours
Write the last sentence first — the "why this role" one. If you can't write it without naming something generic (growth, culture, great team), you don't yet know enough about the role, and that's a research problem rather than a script problem: how to research a company without wasting hours.
Then write the claim your answer is making, in six words. Then pick the two pieces of history that make the claim credible. Everything you cut is still available — they can ask.
Practical target: say your answer out loud and time it. Then say it again in half the time. The second version is almost always better, and the sentences that survive the cut are the ones worth keeping — which tells you what your answer was actually about, usually more honestly than the first draft did.
