How to Answer "Tell Me About Yourself" in a Software Engineering Interview

Somewhere in the first two minutes of nearly every software engineering interview, you'll hear some version of "tell me about yourself." It's the most predictable question in the whole process, which makes it a little strange that it's also the least prepped. I've opened a lot of rounds with it, and the gap between a candidate who has said their answer out loud before and a candidate who is building it live is audible inside thirty seconds. The good news is that this is some of the cheapest prep in interviewing: 90 seconds of material, a handful of bullets, and a few out-loud reps.

What the interviewer is doing while you answer

On most rubrics I've worked from, there's no scorecard line for the intro, so technically nothing is being graded yet. What the opener actually does is set the interviewer's prior for the round. We form an early read on your level and strengths, and everything that follows gets interpreted through it: a strong opener buys your later wobbles a charitable reading as nerves, while a rambling one can get your later strengths discounted as flukes. I won't argue that's fair, but human graders work this way, and you can use it.

While you're talking, here's what's realistically happening on my side of the table. I'm skimming your resume, often giving it its first careful read (many interviewers get handed the resume a few minutes before the round). I'm calibrating your level, listening for whether you describe your work with ownership or as a series of assigned tasks (what counts as the right amount of ownership shifts a lot between new grad and senior loops). And I'm picking my first follow-up from whatever you chose to highlight, which is the part candidates underestimate most: the beats you mention become the menu the follow-ups get ordered from, so your opener quietly steers where the rest of the interview goes.

The resume walk, and why it wastes the slot

Improvised, the answer almost always comes out as a chronological walk. Graduated in such-and-such year, first job, second job, the stack at each stop, four or five minutes, trailing off around "so that's basically my background." None of it is false, and it still wastes the opening, for two reasons. It carries no signal about what you think matters, and it burns time that comes directly out of your own round, since the interview is a fixed length and a long intro means fewer minutes of the coding or design work where the actual scores live. If that describes your current answer, don't be too hard on yourself. Nobody teaches this question, and chronology is the natural shape an unprepped answer takes.

Think of it as your opening crawl

The mental model I offer candidates: this is your opening crawl. Star Wars doesn't begin with the full history of the galaxy. The crawl selects the two or three facts the audience needs, so that when the first scene starts, everyone already knows what movie they're watching. That's the entire job of your opener. You're telling the interviewer what movie they're in, so the next forty minutes land in the context you chose.

Present, past, pull-forward

Aim for roughly 90 seconds, and treat two minutes as the ceiling.

Present, in one or two sentences. Who you are today: role, rough tenure, domain, and your genuine strength. For example: "I'm a backend engineer, six years in, mostly payments infrastructure, and most of my work has been about making unreliable third-party systems safe to build on."

Past, in two or three beats. This is where the resume walk gets replaced. Choose the two or three moments that explain how you arrived here, selected for this specific role instead of recited in order, and give each one a sentence or two: the project or the transition, plus what it says about you. Choose beats you want follow-up questions about, because the follow-ups will come from this list. If the migration is your best story, the migration belongs in your opener.

Pull-forward, in one or two sentences. Why this room. What you want next and why it points at this team. Eloquence matters much less than specificity here; I'm listening for evidence that you thought about this company before you sat down.

Prepping it without turning it into a script

Treat it exactly like the behavioral story bank: bullet points that you rebuild out loud each time. Fully memorized scripts develop a glassy, recited sound, and they tend to shatter when the interviewer interrupts, which we do, usually because one of your beats was too tempting to sit on. Bullets hold the shape while the delivery stays alive.

A prep loop that works:

Write the three sections as seven or eight bullets total.
Deliver it out loud from the bullets, timed. Over two minutes usually means a past beat needs to go.
Record it on your phone and listen back twice. This is uncomfortable and extremely effective; rambles and undersells that were invisible while speaking are obvious on the second listen.
Retune the pull-forward for each company. The present and past sections stay largely stable across a search.

Cooking has a name for this kind of prep: mise en place. Everything gets chopped before the pan is hot, so during service you're assembling rather than deciding. The reason a 90-second opener can come out calm on interview morning is that the decisions were all made the week before.

Adjusting the mix for the room

The same bullets get weighted differently depending on who's across the table. Recruiter screens want more present and pull-forward, and less technical depth. Hiring managers want the past beats, with ownership and impact front and center. Peer engineers want enough technical specificity to hang their follow-ups on. One out-loud rep of each variant is usually enough to make the shifts feel natural.

The opener is a small piece of the loop with outsized leverage, because it's the only question you can be certain is coming and it shapes how everything else gets heard. Practice the delivery out loud a few times before the real thing: a phone recording and an honest friend cover most of it, and if you want reps against something that responds and interrupts the way an interviewer does, that's what we built Preppable for. However you run the reps, make sure the first time you assemble this answer isn't in the room that counts.