How to Answer "Tell Me About Yourself" as a New Grad Software Engineer

TL;DR - "Tell me about yourself" is not an invitation to recite your resume. It's an invitation to frame your narrative. - Target 60-90 seconds. Not 15 seconds. Not four minutes. - The structure: who you are professionally, what you can do now, what you're looking for, why this company. - Don't start from childhood, don't list courses, and don't be so vague that nothing sticks. - Practice until it sounds natural, not until it sounds memorized.

Every technical interview starts the same way. You're connected, the pleasantries finish, and then someone says: "So, tell me about yourself."

It's the first real question, and most new grads treat it as a throwaway. They stumble through a life story starting from high school, or they nervously recite their resume in reverse chronological order, or they give a 15-second non-answer that tells the interviewer nothing and makes the next 45 minutes harder.

The people who answer it well use the question as a chance to frame the conversation. They take 90 seconds to establish who they are, what they can do, and why they're interested in this specific role. Everything that follows is easier because the foundation is set.

Why This Question Matters More Than You Think

"Tell me about yourself" is low stakes in the sense that no one answers it perfectly and no one gets rejected solely for a weak answer.

But it's high stakes in another way: it sets the tone. Interviewers are human. In the first two minutes of a conversation, they form impressions that color everything else. A candidate who opens confidently and clearly is given more benefit of the doubt throughout the interview. A candidate who stumbles through a confused opening has to overcome that impression for the rest of the conversation.

There's also a practical value. A well-structured answer tells the interviewer where to focus. If you say "I've been focused on backend development, particularly API design," the interviewer now has a direction to probe. If you say "I know a little of everything," they have nowhere to start and might ask questions that don't play to your strengths.

You're not lying. You're not performing. You're giving the interviewer what they need to have a productive conversation with you.

The Formula

Four pieces. In order.

1. Background sentence

One sentence about your professional identity. This is not your life story. It's your current professional context.

For a new grad: "I just finished my CS degree at [university]" or "I completed a software engineering bootcamp six months ago and have been building projects since."

For a career changer: "I spent the last four years in [previous field] and transitioned into software engineering about a year ago."

The background sentence grounds you. It tells the interviewer who they're talking to in ten words.

2. What you can do now

One to two sentences about your technical skills and the type of work you're capable of doing. Be specific. Don't list every technology you've touched. Pick the ones that are most relevant to this role and that you're most confident talking about.

"My main focus has been full-stack web development. I've built several projects with Rails on the backend and React on the frontend, including a [brief project description]."

If you have any professional experience (internship, contract work, open source contribution), mention it here: "I also had a summer internship at [company] where I worked on [specific thing]."

If you don't have professional experience, that's fine. Lead with your projects. Projects are real work.

3. What you're looking for

One sentence on what kind of role or opportunity you want. Be honest and be specific.

"I'm looking for a junior backend or full-stack role where I can keep building my skills in a production environment."

This sentence matters because it lets the interviewer confirm the fit quickly. If they're hiring a frontend specialist and you say you want to focus on backend, that's useful information for both parties.

4. Why this company

One to two sentences, specific to this company. Not "I love the mission" or "I've heard great things." Something you actually researched.

"I'm particularly interested in [company] because [specific reason: their tech stack, a product they make, a recent engineering blog post, their approach to a specific problem]."

The specificity here signals genuine interest, which interviewers notice. It also gives them an easy thread to pull if they want to continue the conversation in a direction you've indicated.

What "90 Seconds" Means

Ninety seconds is not a short amount of time when you're speaking. It's approximately 200-225 words. That's enough room for all four components without rushing.

Less than 60 seconds usually means you've been too vague. More than 2 minutes usually means you've included things the interviewer didn't ask for and don't care about.

Time yourself. Read your answer out loud. If you're consistently over 2 minutes, cut. If you're under 60 seconds, add specificity.

What Not to Do

Don't start from childhood or early life. "I've always loved computers, ever since I got my first PC at age 7" is not a professional narrative. It's a personal essay. The interviewer doesn't need your origin story.

Don't list coursework. "I took algorithms, data structures, operating systems, databases..." This tells an interviewer almost nothing. Every CS grad took those courses. What you built, what you've worked on, what you're capable of, those matter. Course names don't.

Don't narrate your resume. "So I graduated in May 2024 and then I did an internship at X from June to August and then I worked on some projects and now I'm here." This forces the interviewer to do work to extract meaning from your timeline. Give them conclusions, not a timeline.

Don't be vague. "I'm a quick learner who loves solving problems and works well in teams." This is background noise. Every candidate says some version of this. Replace every vague phrase with something specific.

Don't confess insecurities. "I don't have a lot of experience, but..." or "I know I'm still learning, but..." These phrases are filler that signal anxiety. You can be honest about where you are in your career without apologizing for it. "I'm a new grad looking for my first full-time role" is direct. "I don't have experience yet" is apologetic. Same fact, different framing.

Weak vs. Strong: Side by Side

Here's what a weak answer looks like:

"So, I studied computer science at State University and graduated this spring. I've taken all the core CS courses and did some projects. I also did an internship last summer. I like full-stack development and I'm looking for a job where I can learn and grow. I'm really excited about this opportunity and I think I'd be a great fit."

What's wrong with it: vague skills, no specifics, unclear what value this person brings, clichéd closing.

Here's a stronger version:

"I graduated with a CS degree from State University in May. During school, I focused on web development and built two projects I'm proud of: a budget tracking app using Rails and React and a real-time chat tool using WebSockets. I also interned at a fintech startup last summer, where I worked on their user authentication API. I'm looking for a junior full-stack role where I can work with a production codebase and keep building on my backend skills. I applied here specifically because I've been reading your engineering blog, and I found your recent post on how you migrated from a monolith to microservices really interesting, since I've been thinking through similar architectural questions in my own projects."

What's better: specific projects, relevant experience, clear technical direction, one well-researched company-specific detail.

How to Practice Without Sounding Rehearsed

The problem with practicing a "tell me about yourself" answer is that it can start to sound scripted. You want it to sound natural and considered, not like you're reciting something you memorized.

A few techniques:

Record yourself. Use your phone. Listen back. You'll catch things you don't notice when you're speaking. Filler words ("um," "like," "you know"), rushing, trailing off. Fix them.

Practice the pieces, not the script. Get fluent in each of the four components separately. Know your background sentence cold. Know your technical summary. Know your "what I'm looking for." Know your company-specific hook. When you can talk naturally about each component, you can assemble them in the moment without sounding like you're reading from a card.

Practice out loud, not in your head. Rehearsing in your head creates false confidence. Speaking it out loud reveals the awkward transitions, the places where you lose your train of thought, and the sections that run too long.

Tell it to a real person. Ask a friend, a family member, or a study partner to listen. Ask them what they remember after you're done. If they can't recall your technical focus or what you're looking for, your answer wasn't specific enough.

Vary it slightly each time. This is what keeps it from sounding robotic. Once you know the structure and have fluency in each component, let the specific words vary. You're not an actor with lines. You're a person with a story. Tell it.

Tailoring for Each Interview

The first three components (background, skills, what you're looking for) can stay mostly the same across interviews. The fourth (why this company) must change for every interview.

This is where most candidates take shortcuts, and it shows. "I've always admired your company" is not specific. "I read about your migration from Heroku to your own Kubernetes setup and it made me want to understand that problem better" is specific.

Five minutes of research before each interview is enough to find one specific detail you genuinely find interesting. Engineering blogs, recent press releases, LinkedIn posts from engineers at the company, Glassdoor reviews mentioning specific tech. Find something real. Use it.

Connecting to Other Interview Questions

"Tell me about yourself" isn't an isolated question. Your answer sets up the rest of the interview.

The projects you mention may become the subject of technical deep-dives. The technologies you claim fluency in invite follow-up questions. The company-specific interest you signal may become the topic of conversation with a hiring manager.

This means your "tell me about yourself" answer and your overall interview preparation are connected. Read real talk on behavioral interviews for software engineers to understand how the rest of the interview builds on this opening. And when the inevitable behavioral questions follow, knowing how to answer behavioral questions will help you keep the momentum going.

For the specific behavioral question format that comes up most often after introductions, see the STAR method.

The answer to "tell me about yourself" takes 90 seconds to deliver and a few hours to get right. It's worth those hours. You'll give it in every interview you have.

If you want structured practice and feedback on your interview answers as part of a broader job search program, here's how the Globally Scoped program works.