How to Answer "Tell Me About Yourself" in a Developer Interview
It's the first question in almost every interview, it's entirely predictable, and most developers still answer it badly — either reciting their CV chronologically for four minutes, or freezing because the question is so open that nothing feels like the right starting point.
It's worth preparing properly. The answer sets the frame for everything after it, and a focused ninety seconds buys you a great deal of goodwill from an interviewer who has heard twelve rambling versions this week.
What they're actually asking
They are not asking for your life story, and they're not testing your memory of your own CV — which they have, in front of them.
They're asking three things at once:
- Can you communicate clearly? For most engineering roles this is genuinely being assessed from the first answer.
- What are you actually good at, in your own words?
- Does your story lead sensibly to this job?
The last one matters most. A good answer ends by connecting you to the role in front of you.
A structure that works: present, past, why here
Ninety seconds to two minutes, three parts.
Present — where you are and what you do. One or two sentences. What you do now, the kind of engineering, the scope.
"I'm a backend engineer at [company], where I've spent the last three years on our payments platform — mostly Go and Postgres, and I own the reconciliation service end to end."
Past — the relevant path, briefly. Not everything. Pick the one or two steps that explain how you got the skills this job needs.
"Before that I was at a smaller startup where I was one of four engineers, which is where I learned to work across the stack and be comfortable owning things nobody else had time for. The payments work is where I got deep in correctness and reliability — we handled a migration between processors with no downtime, which was the hardest thing I've done."
Why here — where you're pointing. Close by connecting to this specific role.
"I'm looking for a role where that reliability work is the main problem rather than a side effect, which is why your posting stood out — the [specific thing from the job post] is close to what I've spent two years on."
That's it. It's tight, it's specific, and it hands the interviewer three obvious follow-up questions, all on topics you're comfortable discussing.
Adapting it
If you're junior or a career changer
Lead with what you're building rather than what you lack, and use the past section to explain your direction as deliberate.
"I'm a developer working mostly in Python and React — for the last year I've been building [project], which is live and has about [n] users. Before that I spent four years in [previous field], where I ended up automating a lot of our reporting, and that's what pulled me into engineering properly. I've been building since, and I'm looking for a first full-time role on a team where I can learn from people more experienced than me — which is why the mentorship you describe in the posting caught my attention."
Note that the previous career is framed as an asset with a plausible bridge, not apologised for.
If you're senior
Shift the weight from tasks to scope and judgment: systems owned, teams influenced, decisions made.
"I'm a staff engineer at [company], where I lead technical direction for our data platform — six engineers across two teams, though I'm hands-on rather than managing. Most of my last two years has been breaking apart a monolith that had become the bottleneck for everyone. Before that I was at [company] doing similar work at larger scale. I'm looking for a role where I can do that kind of architectural work with more product ownership attached, which is what interested me here."
If you have a gap or a switch
Address it in one clause inside the past section, without dwelling. "I took eight months out after that, then spent the time building [thing]" is complete. Don't make it the centre of the answer; don't hide it either.
Common mistakes
- Starting at university. Nobody wants a chronological account. Start with now.
- Going over three minutes. The most common failure. Watch for the interviewer's eyes.
- Listing every technology you've touched. They have your CV. Names without stories are noise.
- Personal life details. Where you grew up, your hobbies, your family — none of it belongs unless it genuinely connects to the work.
- Being negative about a current employer. "I'm leaving because my manager is impossible" is a bad opening, however true. Frame it as moving toward something.
- Not connecting to the role. An answer that would work for any job at any company wastes the question.
- Memorising it word for word. It shows. Learn the three beats and the key phrases; improvise the connective tissue.
Preparing without over-rehearsing
Write it out once, in full. Then reduce it to a handful of bullet points — the present line, the one or two past steps, the closing connection — and practise from those out loud a few times. You want the shape memorised, not the script.
Tailor only the last part per company. The present and past sections stay largely stable; the "why here" changes every time and is where the preparation shows.
Say it out loud before the interview. The gap between an answer that reads well and one that sounds natural is bigger than most people expect.
The takeaway
Treat the most predictable question in interviewing as the free opportunity it is. Ninety seconds, three beats: what you do now, the one or two steps that got you the relevant skills, and why this specific role is the logical next one. Prepare the shape rather than the script, and finish by pointing directly at the job — the interviewer's next question will almost always be one you wanted to answer anyway.
Line up interviews worth preparing for — create a free profile on JobsList.dev and apply directly to companies.