'Tell Me About Yourself' in a Coding Interview: The 90-Second Script That Works

You open the video call. Pleasantries. A beat of silence. Then: "So, tell me about yourself."

And somehow, after months of grinding LeetCode, this is the moment people fall apart. They ramble through every job they've held since college. They recite their resume verbatim, as if the interviewer forgot how to read. They apologize for career gaps. They say "like" forty times. By the time the interviewer finally pivots to the actual problem, the damage is done, and neither party quite knows it.

What most candidates miss: this opener is not casual. It is not a warmup lap. It is the beginning of the interview, and the impressions it forms are sticky. How you handle it also determines how much clock time you have left for the problem you actually prepared for.

A cat being interviewed at a microphone, looking deeply uncomfortable The exact energy when you open your mouth to answer "tell me about yourself."

The First 90 Seconds Are Disproportionately Heavy

The primacy effect is well-documented in hiring research. Interviewers form initial judgments within seconds, and separate research found that untrained observers could predict interview outcomes from just the first 20 seconds of an exchange. The initial impression doesn't determine everything. But it builds a lens. Answer a mediocre second question after a strong intro and the interviewer reads it as "still sharp." Answer the same question after a stumbling intro and the read is "as expected."

Your intro builds the frame through which the rest of the interview gets interpreted. That's not a soft claim. It's how attention and memory work under time pressure.

The good news: this is the one part of the entire interview you can rehearse word for word. The coding problems are unknown. Your introduction is not.

The Time Budget Nobody Talks About

There's a constraint specific to DSA interviews that generic interview advice never mentions. You have 45 minutes, maybe 50. Subtract five for setup and pleasantries. Subtract three to five for the interviewer to explain the problem and constraints. Subtract another five for follow-ups and closing. You're left with roughly 30 to 35 minutes of actual problem-solving time.

Every extra minute your introduction runs is a minute subtracted from your coding time. A four-minute origin story doesn't just bore the interviewer. It leaves you with 26 minutes instead of 30 to solve a medium-to-hard problem. On a tight problem, that difference is the entire optimization step. You just talked yourself out of a job.

The 60-to-90-second ceiling is not arbitrary. It's enough to say something meaningful. It's short enough to leave the clock intact.

A Structure That Actually Works

Three parts. Current role with one concrete impact, one or two relevant past highlights, and why this specific role. Each part gets roughly one to two sentences.

Current role with impact. Not just your title. "I'm a backend engineer at [Company], on the payments infrastructure team. Last year we cut processing latency by 40% by reworking our queue architecture." The number isn't bragging. It's a hook. It tells the interviewer you think in measurable outcomes, not vibes.

One or two relevant past highlights. Not a chronology. One thing that's genuinely interesting or relevant to the role. If you're interviewing for a systems role, mention the distributed systems project. If it's product-facing, mention the feature you shipped. You have five years of experience. You do not need to account for every year.

Why this specific role. One sentence. Specific. Not "I've always admired the company's culture" (you have not). Something real: a product you use, a technical challenge they've published about, a specific team's domain. "I've been following your work on distributed transaction consistency since your engineering blog post two years ago" is genuine. "I'm excited about the opportunity to grow" is filler someone's autopilot typed.

End with a clean handoff. "That's the quick version. Happy to go deeper on any of it." This signals confidence, stops the monologue, and returns control to the interviewer without making them awkwardly cut you off. It also previews the collaborative style that interviewers are explicitly evaluating once the problem starts.

The Agenda You're Setting Without Knowing It

Whatever you mention becomes fair game for the next five minutes before the problem starts.

If you say "I've done performance optimization work at scale," the interviewer will follow up. If you can only describe adding database indexes and can't talk about query plan analysis, connection pooling, or cache invalidation strategies, that gap is now front and center. You've opened a door you can't close.

The intro is an agenda. You control it. If you're strong in graph algorithms, mention you recently worked on a routing system. If you want to avoid deep system design questions before the coding section, don't volunteer that you've "architected distributed systems at scale." Mention what you can defend, and let the follow-up threads go where you want them to go.

Most people treat the intro as a performance to survive. It's actually a steering wheel.

Cut This. All of It.

Your hometown, personal life, family situation. The interviewer doesn't need it and it burns time.
A chronological resume recitation. They have the resume. You are not improving it by reading it aloud.
Anything negative about your current employer. Even if your manager is genuinely, legendarily terrible. Especially then.
Career pivots framed as "I'm trying to move into..." Reframe: "I've been focusing on X and am looking for a role where I can go deeper on Y." Own where you're going. Don't apologize for where you've been.
Vague claims you can't back up. "I'm passionate about clean code" says nothing. "I spent three months extracting a 40,000-line monolith into services and wrote the migration playbook the team still uses" says something.

Clean rule: if you couldn't spend five minutes talking confidently about something, don't mention it in your intro. Saying less, more precisely, is almost always the stronger move.

Tailoring Without Sounding Like You Googled the Company Five Minutes Ago

Every company gets roughly the same intro with one sentence swapped. That's fine. The tailoring doesn't need to be deep. It needs to be specific.

For a startup in fintech: "I've been wanting to work on payments infrastructure end-to-end. At my current company I touched parts of it, but ownership was split across four teams."

For a big-tech infrastructure role: "I've done incident response and owned on-call rotations, but I haven't had a chance to work on the failure detection and alerting systems themselves. That's the direction I want to go."

One specific reason why this role, why now, stated plainly. That's all the tailoring the intro needs. The interviewer is not grading your company research. They're checking whether you have a coherent reason for being in the room.

Two Scripts for Your Next Coding Interview

Experienced engineer (5+ years):

"I'm a software engineer at Vercel, on the edge runtime team. Most recently I've been working on improving cold start latency for serverless functions, cut our median from 180ms to 60ms by reworking how we serialize execution contexts. Before that I was at a Series B startup doing full-stack work across a lot of the data pipeline. I'm interviewing here because I want to work on infrastructure at a much larger traffic scale than I've had exposure to. That's the quick version. What would you like to dig into?"

Word count: 88. Time to deliver: about 35 seconds.

Early career (0-3 years, one job or recent grad):

"I'm a software engineer at [Company], been there about a year and a half working primarily on the backend API layer. One project I'm proud of is a rate limiting system I built from scratch that handles about 50,000 requests per second in production now. Before that, I did my capstone on distributed consensus algorithms, which got me really interested in systems problems. I'm interviewing here because your team's focus on storage engine internals is exactly the direction I want to go. Happy to go deeper on any of that."

Word count: 90. Time: about 40 seconds.

Both have: one concrete number, one real project, one specific reason for being here. Neither has a life story, vague enthusiasm, or three minutes of career arc. If yours currently does, that's the bug to fix.

Your Intro Is Also Your Warm-Up

The intro is your first time hearing your own voice under pressure. Your first few sentences in a high-stakes conversation are almost always the worst ones. If the intro is scripted and practiced, those worst sentences are a non-event. By the time the problem starts, your vocal presence is settled, your nerves have found a rhythm, and you're already in the conversation.

Practice it out loud. Not in your head. In your head it sounds great. Out loud it sounds like someone who learned English from a LinkedIn notification. SpaceComplexity runs mock interviews that start exactly the way real ones do, intro included, so you can hear yourself under realistic pressure before it counts.

The first problem won't catch you cold if the first 90 seconds didn't.

If You Forget Everything Else

The intro sets a cognitive frame. Everything after it gets filtered through the impression it creates.
In a 45-minute DSA interview, a long intro actively reduces your coding time. 60 to 90 seconds is the ceiling.
Structure: current role plus one concrete impact, one or two relevant highlights, one specific reason for this role.
The intro is an agenda. Mention what you can defend. Steer toward your strengths.
Leave out: personal life, career regrets, resume recitation, vague claims, anything you can't back up in a follow-up.
Tailor with one sentence, not a paragraph. Be specific, not flattering.
Practice it out loud. It's the only part of the interview you can fully script.