“So, tell me about yourself” is usually the first thing an interviewer says, and it’s easy to treat it as small talk. It isn’t. Whatever you mention in the next minute and a half becomes the list of things the interviewer can ask about, so the introduction quietly sets the agenda for the rest of the conversation.
Most interviewers have skimmed your resume a few minutes before the call. They don’t need it read back to them. They want a short answer to an unspoken question: why might this person be a good fit for this role? Harvard’s career office frames every interview around exactly that question (“Why should we hire you?”), and the introduction is your first chance to give a partial answer.
Three parts: now, proof, next
A useful introduction has three parts, in this order.
Now. One or two sentences on what you do today: your role, the kind of system or product, and the main tools if they matter for this job. “I’m a backend engineer on the payments team at a mid-size retailer, mostly Java and Postgres” is plenty.
Proof. One piece of work that shows you can do what this role needs. Say what the problem was, what your part was and what changed. This is the section that does the convincing, and it should be specific enough that the interviewer wants to hear more.
Next. Why you’re interested in this role, tied to something concrete in the job description or something you learned about the team. “I’m looking for a new challenge” tells them nothing. “Your team is moving its services to Kubernetes, and I’ve just done a smaller version of that” tells them you read the ad and have a reason.
Leave out where you grew up, every job since university, and a list of hobbies, unless the interviewer asks.
Choosing the proof by reading the job ad
Here’s how the selection works for an illustrative candidate. Use it as a method; your own facts go in where theirs are.
The candidate has four years as a backend engineer at a logistics company. They’re applying for a “Senior Backend Engineer, Platform Reliability” role whose description mentions on-call ownership, migrating services to Kubernetes and mentoring other engineers. Their resume lists several things they could talk about:
| Resume item | Matches the ad? |
|---|---|
| Built the shipment-tracking API | Partly: backend work, but not reliability |
| Moved nightly cron jobs to a queue-based worker system | Yes: reliability and migration |
| Weekly on-call rotation for two years | Yes: on-call ownership |
| Wrote onboarding docs for new hires | Weakly: related to mentoring |
| Hackathon project in Rust | No |
The queue migration is the obvious proof: it touches two of the ad’s three themes and has a measurable outcome. On-call experience can appear in a clause. The Rust project, however fun, would pull the conversation away from what this role cares about.
A weak and a strong introduction
Weak version (illustrative):
I did my degree in computer science and then joined a services company as a trainee, where I worked on Java, Spring and Hibernate. After two years I moved to a logistics company, where I’ve been working with Java, Kafka, Docker, Postgres and some AWS. I’ve worked on lots of different projects there. I’m a quick learner and a team player, and I’m looking for a new challenge, which is why I applied here.
It’s chronological, it lists technologies without saying what was built with them, and “quick learner” and “team player” are claims with no evidence behind them. The interviewer has nothing specific to follow up on, so they’ll fall back on generic questions.
Stronger version (illustrative; swap in your own work):
I’m a backend engineer with four years at a logistics company, working on the services that track shipments from warehouse to delivery. The piece of work I’d point to first is moving our nightly batch jobs onto a queue-based worker system. I wrote the design, migrated the first three jobs myself and set up the alerting, and the rest of the team moved the other twelve using that pattern. Failed overnight runs dropped from a few a week to about one a month, and on-call stopped being mostly manual reruns. I’m interested in this role because your team is doing a similar migration onto Kubernetes at a much larger scale, and I’d like to work on reliability full-time instead of fitting it around feature work.
That’s around 75 seconds spoken. It separates the candidate’s part from the team’s, gives a before-and-after the candidate could explain, and finishes with a reason that only makes sense for this job. Almost any interviewer’s next question will be about the migration, which is a story the candidate has prepared.
If your background doesn’t fit the usual shape
New graduates use the same structure with different evidence. “Now” is your degree and focus, and “proof” can be an internship, a final-year project or open-source work, as long as you can describe your part and what it did. A project that a hundred users rely on beats a list of courses.
Career changers should put the connection between old and new work in the “now” sentence, so the interviewer doesn’t spend the first ten minutes wondering about it. Then let the proof come from the new field, even if it’s a side project.
Returning after a gap, give it one plain sentence (“I took eighteen months out for family reasons and have been back in hands-on work since March”) and move on to recent evidence. Don’t apologize, and don’t over-explain.
Mistakes that cost you the first impression
Running long is the most common one. Past two minutes, the interviewer starts planning their next question instead of listening. Practice with a timer.
Reading out a technology list is the second. “Java, Spring, Kafka, Docker” gives no sense of what you built or how well. Name the tools only when they connect to a result.
Overclaiming in the proof is riskier than it looks, because the proof is exactly what you’ll be asked about next. If you say you “led” a migration, expect “How many people were on it and what did you decide?” Use the verb that matches what you did: designed, built, coordinated, contributed to.
A generic “why” (“it’s a great company with a good culture”) wastes the last part. Spend five minutes on the team’s engineering blog or the job ad and find one specific reason.
Finally, a word-for-word script tends to sound recited. Learn the three parts and the facts, then say it slightly differently each time you practice.
Handling the follow-up you invited
A good introduction is bait, so be ready for the bite. If you mention the queue migration, expect “Tell me more about that” or “What was the hardest part?” Have the two-minute STAR version ready, with the design choice you made, the alternative you rejected and how you measured the drop in failed runs.
“Why are you leaving your current job?” often comes straight after. Keep it forward-looking (“I want to work on reliability full-time, and that role doesn’t exist on my current team”) and never use it to criticize a manager or employer.
Interview practice: write and trim your introduction
Take a job description you’d genuinely apply for. Highlight its three most important requirements. Write a 90-second introduction using the now, proof, next structure, then cut it to 60 seconds without losing the proof.
Answer: how to judge your draft
The “now” part should be two sentences at most and should name the kind of work, not just your title. The proof should match at least one highlighted requirement, name your contribution separately from the team’s and include an outcome you could explain if asked how it was measured. The “next” part should mention something that’s only true of this role or team.
When you cut to 60 seconds, the first things to go are extra technologies, a second project and any adjectives about yourself. The proof stays, because it’s the only part that carries evidence.
Then test it on a friend or colleague: read it once and ask, “What would you ask me next?” If they pick the project you wanted them to pick, the introduction is doing its job. If they ask something vague like “What do you do day to day?”, your “now” part wasn’t clear enough.
Related reading
- Behavioral and HR interview questions
- Behavioral and HR multiple-choice questions
- Behavioral Interviews: A Clear STAR Story, for the follow-up after your introduction
- Behavioral: Building a Career Growth Plan
- Harvard Mignone Center for Career Success: Interviewing