Tell me about yourself for a software engineer interview

Interviewers are listening for the kind of engineer you are, one result you can defend, and why this team. They are not waiting for your language list.

Build your answer

Target role The job you are interviewing for. Years of experience Years in this kind of work. Use 0 for a first role or a career change. Current role or background A field, a path, or a short phrase.

Win 1 Include a number. Win 2 Optional. Win 3 Used in the long version.

Key strength One habit, not five adjectives. Why this company or role A reason that would be wrong for a different employer.

Runs in your browser. Nothing you type is uploaded.

30-second version

About 29 seconds · 72 words

A short cut for a recruiter screen.

Stop after one result. A short screen does not need the second story.

60-second version

About 55 seconds · 138 words

The default. Present, then past, then future.

If they lean in, drop the second result and spend the time on how the first one happened. Leave duties from the job description out.

90-second version

About 79 seconds · 197 words. You have room to add one specific detail.

A longer cut when they ask you to walk through it.

I'm looking for a software engineer role. For the past 6 years I've worked as a backend engineer on a payments team. Before that, the results are specific. I cut checkout latency 40% for 2 million weekly sessions. I also led a migration off a legacy billing service with zero downtime. I then mentored 4 engineers and cut on-call pages in half. Each of those has a before and an after I can defend. The way I work, when it counts, is making tradeoffs explicit when a system is under load. What I want next is this software engineer seat, because this team owns customer-facing reliability, and I want that scope. On the job I'd stay this concrete about software engineer, including what moved and what did not. The numbers in those results are ones I can defend, including what I owned. The decision under the first result is the part I know best. I checked the baseline before I called that result done. I would use the same judgment on the next software engineer problem. The work I want next is still software engineer work: a clear owner, a number, and a decision I can explain.

They can interrupt. Go present, then proof, then why this role. When they ask, go from the headline number to the decision you made.

When you can say the minute without the page, practice it live with Luna. It hears the question and helps you keep a line. 24 hours free.

How to answer it for this role

Lead with the seat, not the stack. "Backend engineer on a payments team" tells a hiring manager where you have been. A list of languages tells them you are nervous. If the posting is a product engineer role, say that. If it is infrastructure, say that. The same person can honestly want two different jobs, and the first sentence should match the room.

Pick results that survive a follow-up. Latency, incident count, migration downtime, and adoption are easier to defend than "owned the service." Be ready to split what you did from what the team did. A 40% improvement you measured is stronger than a 40% improvement you inherited in the dashboard.

Skip the origin story unless they ask. A bootcamp, a computer science degree, and a first job can wait for "walk me through your resume." This answer is the frame. The coding round will test the skill. This minute tests whether you can narrate impact without drifting.

What to emphasize

Name the surface you work on: product, platform, data, mobile, or internal tools.
Use one production number, not a tour of every service.
Tie the last sentence to this team's users or reliability bar.

What to leave out

Reciting languages, frameworks, and cloud logos.
"I'm passionate about technology" with no result after it.

Sample 60-second answer

This is the sample loaded into the builder above. About 55 seconds, 138 words. Replace every fact with yours before you practice it.

I'm looking for a software engineer role. For the past 6 years I've worked as a backend engineer on a payments team. Before that, the results are specific. I cut checkout latency 40% for 2 million weekly sessions. I also led a migration off a legacy billing service with zero downtime. The way I work, when it counts, is making tradeoffs explicit when a system is under load. What I want next is this software engineer seat, because this team owns customer-facing reliability, and I want that scope. In the job I'd bring that strength to the team's current goal, and I'd report what moved. Those results are the kind of work I want to keep doing as a software engineer. I can explain the constraint behind the first result and the number I was willing to defend.

The 30-second cut is about 29 seconds. The longer cut is about 79 seconds. Both use the same facts in the same order. Read the longer structure guide if you want the timing rules in full: how long the answer should be.

Tips before you say it

Say the 60-second version out loud before you edit it. A sentence that looks fine on the page often runs long or sounds like a memo.
One number per win. “Improved the process” is a claim. “Cut hold time from 6 minutes to 2” is a result you can be questioned on.
Stay in order: present, past, future. If you start with where you grew up, the interviewer is waiting for you to arrive.
Leave a door open and then stop talking. The extra story you add in the silence is usually the one you did not prepare.
Keep your part separate from the team’s. “We launched” collapses the first follow-up. “I cut the scope, engineering shipped it” survives.

Other roles

Questions people ask

Should a software engineer mention LeetCode in tell me about yourself?

No. The opener is about the job you have done and the job you want. Coding practice can come up when they ask how you prepare. It is not a professional result.

How technical should the 60-second answer be?

One concrete system and one number is enough. If you explain the design, you have started the design interview early and you will run long. Offer the depth, then stop.

What if my work is under an NDA?

Keep the shape and drop the secret. "Cut checkout latency 40% for a large consumer flow" is defendable without naming the internal service or the customer.