Tell Me About Yourself: How to Answer as a Software Engineer

The interviewer smiled, looked at her notes, and said: “So, tell me about yourself.”

And I — a reasonably competent engineer who’d spent two weeks reviewing algorithms and system design — panicked. Not the frozen kind of panic. The opposite kind. The kind where your mouth starts moving before your brain catches up.

I talked about my computer science degree. Then my first internship. Then the framework I used at that internship. Then some side project from 2019 that had nothing to do with the role. Then I circled back to my degree for some reason. I mentioned a hackathon. I think I talked about my hobbies at one point.

Five minutes. I rambled for five minutes. The interviewer’s smile slowly flattened into something polite but distant, the way you look at someone who’s telling you a story that’s clearly going nowhere.

When I finally stopped — not because I’d finished, but because I ran out of things to say — she nodded and moved on. The rest of the interview was fine. I didn’t get the job. And I’m pretty sure those first five minutes are why.

The thing is, “tell me about yourself” isn’t a hard question. It’s the easiest question you’ll get. That’s the problem. Nobody prepares for it because it sounds simple. And then, when the moment comes, you realize you’ve never actually thought about what to say.

I’ve since sat on the other side. I’ve interviewed probably forty or fifty engineers. And the way someone answers this question tells me a lot — not about their resume, but about whether they can communicate clearly under mild pressure. Which, for a software engineer, is basically Tuesday.

So here’s what I wish I’d known.

The framework: Present, Past, Future

Ninety seconds. That’s all you need. Maybe two minutes if the story flows naturally, but aim for ninety seconds.

Three parts. Thirty seconds each.

Present — what you’re doing right now. Your current role, the kind of problems you work on, the technologies you use daily. Not your title. What you actually do.

Past — the relevant highlights that led you here. Two or three sentences. Not your life story. The parts that connect to the role you’re interviewing for.

Future — why you’re sitting in this interview. What excites you about this company, this team, this problem space. This is the part most people skip, and it’s the part interviewers remember most.

That’s it. Present, past, future. Thirty seconds each. You talk for about ninety seconds, the interviewer has a clear picture of who you are, and the conversation can move to things that actually matter.

I know it sounds too simple. I thought so too, the first time someone told me. But simple is the point. The interviewer isn’t looking for a monologue. They’re looking for signal: can this person organize their thoughts and communicate concisely?

What NOT to do (I’ve seen all of these)

Don’t tell your life story. I once had a candidate start with where they grew up. Their childhood interest in computers. Their father’s job. I’m not exaggerating — by the time they got to their first programming experience, three minutes had passed and I still didn’t know what they did for a living right now. The question is “tell me about yourself,” not “tell me everything about yourself.”

Don’t read your resume out loud. I have your resume. I’ve read it. If you just narrate it linearly — “so I graduated in 2019, then I joined Company X, then I moved to Company Y, then I did Z” — you’re wasting both our time. I already know the timeline. Tell me something the resume can’t.

Don’t be generic. “I’m a passionate software engineer who loves solving problems and working with teams.” That describes every single person I’m interviewing today. What specifically do you work on? What kind of problems? What’s the thing that makes you different from the other four candidates I’m talking to this week?

Don’t apologize or undersell. “I’m just a junior developer, so I don’t have much experience, but…” Stop. You’re here because you qualified. Own it. Talk about what you’ve built, what you’ve learned, what you’re good at. Confidence isn’t arrogance. It’s clarity.

Three examples that actually work

These aren’t scripts to memorize. They’re shapes. Adapt them to your story.

Junior engineer (0-2 years)

“Right now I’m a frontend developer at a fintech startup called PayFlow, where I work on the customer-facing dashboard — mostly React and TypeScript. I joined about a year ago as my first role after graduating, and in that time I’ve owned the migration from our legacy jQuery components to React, which cut our bundle size by 40%.

Before that, I did a six-month internship at a digital agency where I got thrown into a bunch of different stacks — Vue, Angular, some backend Node — which honestly taught me how to learn new tools fast.

I’m really interested in this role because you’re building a design system from scratch, and that’s exactly the kind of foundational frontend work I want to go deeper on.”

Why it works: specific numbers, concrete projects, a clear reason for being here. No filler. About eighty seconds.

Mid-level engineer (3-5 years)

“I’m currently a backend engineer at DataStream, where I work on our event processing pipeline — we handle about two million events per day using Kafka and Go. My main focus over the last year has been improving reliability. I led a project to redesign our retry and dead-letter strategy, which brought our processing failure rate from 2.3% down to under 0.1%.

Before DataStream, I spent two years at a consulting firm, which was a great crash course in working across very different codebases and learning to ship fast. But I wanted to go deeper on distributed systems rather than jumping between projects.

What drew me to this role is the scale you’re operating at. Fifty million daily active users is a different kind of problem, and I want to work on systems where reliability decisions have that kind of impact.”

Why it works: shows ownership, quantifies impact, explains career progression logically, connects directly to the target role.

Senior engineer (6+ years)

“I’m a senior backend engineer at CloudBase, where I lead a team of five working on our API gateway. We handle about 800 million requests a day, and my focus has been on performance and cost — over the past year, I drove an architecture change that reduced our compute costs by 35% while improving p99 latency.

My background is a mix of platform and product engineering. I spent three years at a B2B SaaS company where I went from IC to tech lead, and before that I was at an agency, which is where I developed the habit of thinking about engineering decisions in terms of business outcomes, not just technical elegance.

I’m talking to you because I’ve been following your engineering blog, and the work you’re doing on edge computing aligns with where I want to take my career next. I’m especially interested in the technical leadership aspect of this role.”

Why it works: demonstrates scale, leadership, business awareness, and genuine interest. The interviewer immediately knows this person has done their homework.

Adapting your answer by company type

The framework stays the same. The emphasis shifts.

Startups want to hear that you can wear multiple hats and move fast. Highlight breadth, shipping speed, comfort with ambiguity. “I built the MVP in three weeks” matters more than “I optimized a system serving millions.” They want to know you’ll survive the chaos.

Big tech wants depth and scale. Quantify things. Millions of users, percentile latencies, cross-team projects. They have a leveling rubric, and your answer should make it easy for them to place you. Use the language they use. Impact. Scope. Complexity.

Enterprise / traditional companies care about stability, collaboration, and process. Mention cross-functional work, stakeholder management, working within constraints. “I worked with the compliance team to redesign our data pipeline” signals something different than “I shipped a feature in a weekend.”

None of this means lying. It means knowing which parts of your real experience to put in the spotlight. You’re the same engineer. You’re just adjusting the lens.

How to actually practice this

I’m going to be blunt: knowing the framework isn’t enough. You have to practice saying it out loud. With your mouth. I’m being specific because I know a lot of engineers who “practice” by reading their answer silently and thinking, “yeah, that sounds good.” It doesn’t count.

Record yourself. Phone, laptop, whatever. Say your answer. Play it back. The first time you do this, you will hate it. Everyone hates it. Do it anyway. You’ll notice filler words, weird pauses, sentences that go nowhere. Fix them. Record again.

Time it. Set a 90-second timer. If you’re still talking when it goes off, cut something. The goal isn’t to squeeze in more information. It’s to say less, better.

Say it to a human. A friend, a mentor, a fellow engineer who’s also job hunting. Tell them the role you’re targeting and ask: “After hearing my intro, would you know what I do, why I’m good at it, and why I want this job?” If the answer to any of those is no, iterate.

Prepare two or three variants. One for startups, one for bigger companies, one as a default. The core stays the same. The emphasis shifts. Having variants ready means you won’t freeze when the company feels different from what you expected.

I practiced mine in the car. Talking to the windshield like a normal person. It took maybe four or five iterations before it felt natural. After that, it was automatic. Every interview started strong, which made everything else easier.

Stuff people always ask me

What if the interviewer says “walk me through your resume” instead? Same framework, slightly more chronological. Start from the earliest relevant point and work forward, but keep it tight. Still ninety seconds to two minutes. Still end with why you’re here.

Should I mention personal projects or open source? Only if they’re relevant to the role and impressive enough to warrant the airtime. “I maintain a library with 2,000 GitHub stars” — yes. “I have a to-do app on GitHub” — probably not in your 90-second intro.

What if I’m switching careers from another field? Lead with the transferable skills and the “why.” “I spent five years as a mechanical engineer, which gave me strong problem-solving fundamentals. Over the past year, I’ve been building full-stack projects and completed a bootcamp focused on React and Node. I’m making this switch because…” The Past section becomes your bridge.

How do I handle gaps in employment? Briefly and honestly. “I took a year off to handle a family situation and used some of that time to deepen my skills in cloud architecture.” Then move on. Don’t over-explain. Don’t apologize. Gaps are normal.

This question comes first in almost every interview. Nail it, and you set the tone for everything that follows. Mess it up, and you spend the rest of the hour climbing out of a hole.

If you haven’t already, check out the full technical interview preparation guide for the complete picture. And if behavioral rounds are where you struggle, the STAR method guide breaks down exactly how to structure those answers.

Done reading? Join the early access community →