\"Tell me about yourself\" is not an icebreaker

I spent ten years running final-round interviews. I have opened almost every one of them with some version of "tell me about yourself", and I have watched most candidates answer a question nobody asked.

They give me a biography. Born, studied, first job, second job, third job, and here I am. Chronological, complete, and by minute four I have stopped listening — not out of rudeness, but because there is nothing in it for me to hold on to.

The question is not small talk. It is the only moment in the interview where you choose what the conversation will be about.

What the interviewer is actually doing

Three things, all at once.

Deciding what to ask next. Most interviewers have not fully planned the hour. They have your CV, a rough list of areas, and a first question. Whatever you emphasise in your answer is what they will pick up. Say "I spent the last year cleaning up a test suite that took four hours to run" and the next twenty minutes will be about test infrastructure — an area you have just told them you are strong in. Say nothing specific and they will fall back on their generic list, which is a list you cannot steer.

Checking whether you can be understood. Not "are you articulate" — whether you can take something complicated you did and make a stranger understand why it mattered. That is most of the job in any role above junior, and this is the first sample of it.

Calibrating your level. A senior candidate who describes their work the way a junior does creates doubt that is very hard to undo later. Not because the work was junior, but because seniority shows in what you consider worth mentioning.

Notice that none of the three is "learn your history".

The mistake almost everyone makes

The chronological answer is the default because it feels safe and complete. It is also the worst structure available, for a simple reason: it puts the most relevant thing last.

You start in university, and by the time you reach the work that actually matters for this role, three minutes have gone and the interviewer has begun forming an impression from the weakest material you have.

The second-worst version is the CV read aloud. They have your CV. Repeating it tells them you have nothing to add to it.

The third is the personality summary — "I am a fast learner, I am a team player, I love clean code". Every candidate says this, which means it carries no information at all. Nobody has ever said "I am a slow learner who dislikes their colleagues".

A structure that works

Ninety seconds. Three parts.

Where you are now, in one sentence. Role, domain, scale. "I am a backend engineer, four years, mostly payments — the last two on a system doing about a million transactions a month."

Scale matters more than title. "Senior engineer" means five different things at five companies. "A million transactions a month" means one thing everywhere.

One thing you did, with the problem attached. This is the whole answer; the rest is framing. Pick one piece of work, and lead with the problem rather than the technology.

Not: "I worked with Kafka, Postgres and Kubernetes."

But: "Our payment retries were double-charging about one customer in a thousand — rare enough that nobody could reproduce it. It turned out to be two webhook deliveries racing each other, and the fix was moving the check inside the write so the database decided who was first."

The second version does several things at once. It shows what you consider a problem worth solving, that you can diagnose rather than guess, and that you can explain a race condition to somebody in ninety seconds. The first version shows that you have used three popular tools, which is true of everyone in the pile.

Why you are here, in one sentence. Connect what you just described to what this role needs. "That is why this role interested me — it is the same class of problem at a larger scale."

Then stop. The silence is not awkward; it is an invitation for them to follow up on the thing you chose. That is the entire point.

The part that decides whether it lands

The detail you pick must be checkable.

Interviewers do not remember adjectives. They remember numbers, names and consequences. "Improved performance significantly" evaporates. "Cut the p99 from 1.8 seconds to 300 milliseconds by removing an N+1 in the listing query" survives, and it survives because it is the kind of thing you could not say unless you had done it.

This is also the honesty check. If you inflate here, the follow-up question will find it in about forty seconds, and there is no recovering the room afterwards. A modest specific beats an impressive vague every time.

Adjust it for the level you are interviewing at

Junior. You have less to draw on, so draw on what you actually built, not what you studied. A course you finished is not a story. A project where something did not work and you found out why is. The interviewer knows your experience is thin; they are looking for evidence that you learn by running into things, because that is the only thing that predicts the next six months.

Middle. One piece of work, owned end to end. The most common failure at this level is describing the team's achievement without ever saying what you did. "We migrated to microservices" tells me nothing about you. "I owned the extraction of the billing service, and the hard part was the data" tells me a great deal.

Senior and above. Include a decision, not just an implementation. What you chose not to do is often more revealing than what you built, because at this level the job is mostly judgement under incomplete information. "We considered event sourcing and decided against it because we could not staff the operational side" says more about seniority than any list of technologies.

Practise it out loud, not in your head

This is the part people skip, and it is the part that matters.

In your head the answer is fluent, because your head fills gaps automatically. Out loud you discover that the transition between the second and third part does not exist, that the technical bit takes ninety seconds on its own, and that you say "basically" eleven times.

You do not need a script. A script sounds like a script and interviewers notice immediately. What you need is to have said it aloud three or four times, so the shape is familiar and the words are fresh.

If you want the questions that follow this one for your role and level, we keep a set of them per specialisation on the interview questions pages — the follow-ups are usually where the interview actually happens.

What to do tomorrow

Write down one piece of work. One. The problem, what you did, what changed as a result, in three sentences.

Say it out loud. Time it. If it runs past two minutes, cut the setup, not the outcome — the setup is where everyone overspends.

Then leave it alone. You are not memorising an answer; you are choosing, once, what the interview is going to be about. That decision is the whole exercise, and you can make it in twenty minutes tonight.