“Tell me about yourself”: examples for developers

Guess which question gets opened most often in the frontend section of the Sobes question bank. Not closures, not the Virtual DOM, not the event loop. It's "Tell us about yourself, your experience, and your recent projects."

It comes up in almost every interview, and almost everyone answers it worse than they could. Some start with university, some list their entire stack, some retell the resume the interviewer already has in front of them.

What they're really asking

The bank has many versions of this question from real interviews. Here are a few:

Tell us about yourself: how did you get into development, which teams and products have you worked on, and what did you do there?

Tell us a little about yourself: your work experience, what you're looking for, and why you decided to change jobs.

Briefly tell us about yourself, what brought you to this role, and what your expectations are.

Put them together and you get three questions: what you do, what you did yourself, and why you want this job. A good answer covers all three in two minutes.

How to build your answer

Nobody is holding a stopwatch in the interview, the numbers are for practice. The main thing is that the middle part, about what you did, is the longest.

Below are three examples. They're made up, so swap in your own projects and results.

Junior: show that you finish what you start

No commercial experience? Say so, it's not a death sentence. Talk about a study or personal project: what you built, where you got stuck, and how you got out.

I'm a junior frontend developer, I work with TypeScript and React. I don't have commercial experience yet. For the last six months I've been studying and building my own expense tracker.

You can add expenses, sort them into categories, and see monthly totals. I built everything myself, from the mockup to the release. The hardest part was error handling: if a request failed, everything the user had typed was lost. I had to rework the form so the data was kept and the request could be retried.

Now I'm looking for my first team, where I can take on small tasks and learn from code reviews. What I liked about your role is that it's mostly about the user account area, which is close to what I've been doing.

There's something to grab onto here: a specific problem and how you solved it. "I'm a fast learner" without an example tells the interviewer much less.

Middle: show that you work independently

The main question for a middle developer is how independent you are. The word "developed" doesn't answer it. Use one task to show what you decided on your own and what you agreed on with others.

I'm a backend developer, I've been writing Python for four years. For the last two years I've worked on the order service of an online store: the customer account and integrations with delivery services.

A recent example: a delivery service sometimes sent the same notification twice, and customers got two emails. I figured out where the duplicates came from, proposed a fix, agreed on it with the analyst, and took it all the way to release myself. No more duplicates.

I don't define the architecture of the whole service, we discuss big decisions with the team lead. But I own my tasks from requirements to release, do code reviews, and help a new colleague find their way around the code.

Next, I want to work more on integration reliability. As I understand it, that's a separate area on your team, and I'm curious what tasks you have there right now.

Be ready for follow-ups on this story: "what did you do personally?", "why did you choose this solution?", "what would you do differently?". Since you brought it up yourself, those questions are almost guaranteed.

Senior: show decisions that affect others

A senior developer is expected to make decisions that go beyond their own code. Scale doesn't have to be measured in millions of users. It can be a tricky migration, agreements between teams, or someone you helped grow on your team.

I'm a backend developer, I've been building B2B services for eight years. Right now I'm responsible for technical decisions in billing: our team has five people, and several other teams use our services.

My last big project was moving to a new way of calculating charges. Switching everything at once was too risky, so I proposed moving clients over in groups and first running the old and new calculations side by side. It took longer, but not a single client got a wrong invoice.

I owned the migration plan and the tricky cases, and worked out the details with finance and support. I wrote part of the code, most of it was done by the team.

Now I'm looking for a role where I can both write code and own a technical area. What caught my attention in your role is the work across several services.

The key here is what you decided, who you negotiated with, and what you had to trade off. "We migrated billing" says nothing about your role, and the interviewer will start digging for it anyway.

If you're switching stacks

Separate what carries over from what you're still learning. When you switch from Java to Go, your experience with APIs, databases, and production doesn't go anywhere.

I've been writing backend in Java for three years, and now I want to move to Go. APIs, databases, handling production incidents: I have that experience. I've built a small service in Go, but I haven't worked with it in production yet. That's exactly what I'm working on now.

From there, it's better to offer to show your code than to argue that all languages are alike.

If you had a career break

One sentence is enough. You don't need to explain in detail what happened, just move the conversation to what you've done recently.

I took a break for personal reasons. Now I'm back: I've refreshed my stack, finished my own project, and I'm ready for a full-time role.

How to rehearse without memorizing

A memorized script is obvious right away: you sound like a kid reciting a poem at a school play, and any question knocks you off track. So don't memorize the text, memorize the key points: role, project, problem, what you did, what you're looking for.

Record yourself telling your story and listen to it. Where did you start listing technologies? Where did you say "we" when it was about you? What can you cut without losing meaning?

Then tell it again in different words. If it falls apart without the exact script, simplify it. You can rehearse this question out loud in the HR mode of the mock interview, or with a friend who keeps interrupting: "what did you do yourself?", "why did you leave?".

Check your story against your resume: dates and job titles should match. If your resume is still weak, start with a resume review.

If you use Sobes Copilot in interviews, add your resume and your intro to a context. Then the hints for questions about your experience will be about your projects, not generic phrases. We explained how to set this up in the post about contexts.

If after your two minutes the interviewer asks something specific about your project, your answer worked.