INTERVIEW QUESTION
Tell me about yourself: how to answer in about 90 seconds
Introduce yourself in about 90 seconds around one piece of work you want the interviewer to ask about, instead of a tour of your résumé.
Most answers to “Tell me about yourself” are a tour of the résumé the interviewer already has open: every job in order, a list of tools, then something polite about wanting a new challenge. Nothing in it gives them an obvious next question, so the conversation starts from zero.
A more useful way to see the question: in about 90 seconds, you are choosing what they ask about next.
Interviewers mostly use the answer to orient themselves. What do you do now, and at what scope? Does any of it touch what this role needs? Is there one piece of work worth digging into?
They also notice how you organize it. A data-science interviewer on Reddit names long monologues as one of the most common errors they see, and would rather a candidate pause to think.
What to say, and in what order
Splitting the answer into three parts stops the background from using up the time meant for your best work.
- Now (about 15 seconds). Your current role or studies, the area you work in and the kind of problems you handle.
- Proof (about 45–60 seconds). One piece of work that matters for this job: the problem, what you did and what changed. They will probably ask about this part, so pick it on purpose.
- Next (about 15 seconds). What you want to do next, and why this role is a sensible step toward it.
Add a before only when it explains your path, such as a career change. One sentence is plenty.
The proof is also where you can say something the interviewer can't already read. A QA engineering interviewer describes a strong introduction as one with details about projects and teams that go beyond the résumé or LinkedIn profile.
Before the interview, underline the sentence in your draft that you most want them to ask about. If there isn't one, the proof is too thin.
How long to talk, and when to go shorter or longer
Interviewers in the threads we read asked for two to three minutes, and experienced candidates often suggest a minute. About 90 seconds sits between the two and leaves them time to ask about the proof.
Inside that range, structure matters more than the clock. A sales hiring manager is happy with around three minutes and doesn't use a stopwatch, but listens for whether the story is structured or rambling.
The upper limit is real, though. A recruiter on r/recruitinghell asks for a quick two-minute summary, and recalls a candidate whose 15-minute answer to a hiring manager ended their candidacy.
Who is asking changes the right length. Recruiters are often checking direction and basic fit: can you say clearly what you do, does your experience hold up, and do you want this role in particular. A minute usually covers that.
A hiring manager or panel will push into the proof, so give the fuller version, and don't mention anything you couldn't talk about for five minutes. If several interviewers ask it in one day, give each the short version so it doesn't take time from every session.
Seniority matters too. With ten years behind you, two minutes can be right, as long as the extra time explains your moves rather than listing more jobs.
You've gone too long if you're still on your second job and haven't reached the proof, or if the interviewer is glancing at their notes or trying to come in. Stop at next. If you're unsure, offer more: “I'm happy to go into that project in more detail.”
So prepare two versions. The short one is what the stronger examples show: a sentence of now, a few of proof and one of next, about 40 seconds. The longer one, about 90 seconds, keeps the same proof but adds what made it hard and the decision you made. Add depth to that project rather than a second one.
Example answers
In these made-up examples, each stronger answer is the short version: about 40 seconds aloud, most of it on one piece of work. Compare that with how long the proof part of your own answer runs.
Software engineer
Weaker
“So I graduated in 2019 with a computer science degree, then I joined a startup as a junior developer working with Java, Spring and React. In 2021 I moved to an e-commerce company where I've been working on microservices, Kafka and AWS. I like solving problems and working in a team, and I'm looking for a new challenge.”
This may all be true, but it doesn't help the interviewer. They learn which tools you've used, not what you did with them. And “a new challenge” could describe any job.
Stronger
“I'm a backend engineer on the payments team at an online retailer, where I look after the services that handle refunds and payouts.
The work I'm proudest of is our refund pipeline. Refunds were failing silently when a payment provider timed out, and support only found out when customers complained. I designed a retry and reconciliation process, ran the migration, and the silent failures stopped.
Next, I want to own a service end to end, and your platform team's focus on payment reliability is close to the work I've enjoyed most.”
The interviewer now knows what you do and has clear things to ask next: how the reconciliation worked, what you traded off, and how you rolled it out.
Product manager
Weaker
“I started my career in consulting, then moved into product about five years ago. I've worked at two startups and now I'm at a fintech company. I've done a lot of roadmapping, stakeholder management and agile delivery, and I'm passionate about building products customers love.”
It lists job titles and product vocabulary, but no decision the candidate made. “Products customers love” is something every product manager says.
Stronger
“I'm a product manager at a small-business lending company, where I own the flow that owners use to apply for a loan.
The work I'm proudest of is reducing how many applicants gave up halfway. Our data showed most dropped off at the document upload step. I spoke to a dozen applicants, learned they didn't have bank statements to hand, and we changed the flow so they could connect their bank instead. Completed applications rose clearly the next quarter.
Next, I want to work on a product with a larger, more varied set of customers, which is why your payments team caught my eye.”
One product, one decision made from evidence, and an outcome. The interviewer can ask about the calls, the trade-offs or the numbers.
Product designer
Weaker
“I'm a product designer with six years of experience. I've worked across B2B and B2C, mobile and web. I'm skilled in Figma, user research, prototyping and design systems. I'm very user-centered and I love solving complex problems.”
A list of skills and adjectives that could open any designer's portfolio. There's no project to ask about.
Stronger
“I'm a product designer at a travel booking company, working on checkout in the mobile app.
The project I'd most like to talk about is our seat selection screen. Support kept hearing from families who were split up on flights. I watched recordings of people booking, saw that they skipped seat selection because it looked like an upsell, and redesigned it to show free seats first. Complaints about split families dropped sharply.
Next, I want to work closer to research and earlier in product decisions, which this role seems to offer.”
It points to one design decision, the evidence behind it and what changed. That's the thread the interviewer is most likely to pull.
Data analyst
Weaker
“I have a master's in business analytics and three years of experience as a data analyst. I'm proficient in SQL, Python, Tableau and Excel, and I've built a lot of dashboards and reports for different teams. I'm detail-oriented and I love working with data.”
Tools and dashboards, but no sign that any of the work changed a decision. That's what analyst interviewers most want to hear.
Stronger
“I'm a data analyst on the growth team at a meal-kit company, where I answer questions about why customers stay or cancel.
Last year leadership was about to cut a discount on second orders because it looked expensive. I compared customers who used it with similar customers who didn't, and found the discount roughly paid for itself through repeat orders. We kept it and narrowed who it was offered to instead.
I'd like to keep doing work where the analysis feeds straight into decisions, which is how your team describes this role.”
The analysis is tied to a real decision. It also shows judgment: the analyst compared like with like before drawing a conclusion.
Program manager
Weaker
“I'm a certified PMP and Scrum Master with eight years of experience managing programs. I've run large cross-functional initiatives, managed risks and dependencies, and run stand-ups and steering committees. I'm very organized and good at keeping everyone aligned.”
Certificates and meetings describe process, not results. The interviewer can't tell what any program achieved, or what the candidate did when one went wrong.
Stronger
“I'm a program manager at a healthcare software company, coordinating releases across five engineering teams and our compliance group.
The program I learned the most from was moving our customers to a new billing system. Two months in, two teams were working toward different launch dates without realizing it. I mapped the dependencies, got both leads together, and we agreed to launch in phases. The first phase went out on the original date.
Next, I'm looking for larger, more technical programs, which is what your platform team runs.”
It shows the candidate catching a real problem and making a call about it. The interviewer will likely ask how they spotted the mismatch.
Consultant
Weaker
“I studied economics at university, then joined a Big Four firm in their advisory practice. I've worked on projects in retail, banking and healthcare for several well-known clients. I'm analytical, a strong communicator and a team player, and I'm excited about a career in strategy consulting.”
Clients and sectors are named, but the candidate's own part in any project is missing. “Analytical” and “strong communicator” are claims with nothing behind them.
Stronger
“I'm an analyst in the operations advisory team at a professional services firm, mostly working with retailers on their supply chains.
On my last project, a grocery chain wanted to close two warehouses. I built the cost model, and while checking it with store managers I found that one warehouse handled most of the chain's fresh food, which the original plan had missed. We changed the recommendation to close only one.
Next, I want to move toward strategy work, where the questions are broader and I'd spend more time with senior client teams.”
One project, the candidate's own role in it, and a moment where their work changed the recommendation. It also explains why consulting, and why now.
What counts as proof in your role
The order above works for any role. What changes is which piece of work makes the best proof, because each role is judged on different things.
Use this table to pick your proof, and to spot the habit that most often weakens openings in your field.
| Role | Lead with | Strong proof | Watch out for |
|---|---|---|---|
| Software engineer | The systems or product area you work on | Something you built, fixed or decided, and what changed for users | Listing languages and frameworks |
| Product manager | The product, its users and your scope | A product decision you made and its effect on customers or the business | Describing the roadmap instead of your calls |
| Product designer | The products and design problems you work on | One project: the user problem, your design decision and what changed | Walking through your portfolio slide by slide |
| Data analyst | The questions your work answers, and for whom | An analysis that changed a decision | Naming tools and dashboards without the decision |
| Consultant | How you approach problems and work with people | One project that shows problem-solving or teamwork, then why consulting | Naming clients or institutions without your own part |
| Program manager | The programs and teams you coordinate | A cross-team delivery you got moving again | Describing process instead of the problem you solved |
The software engineer and consulting guides cover the questions that usually come after this one.
“Walk me through your résumé” and other versions
Walk me through your résumé. Chronological order is expected here, but spend time by relevance, not by date. Older roles get a sentence each. Most of the time goes on the work closest to this job, and you still finish with what you want next.
A product interviewer's list of common mistakes puts it well: give context for why you made each move, rather than listing employers in order.
Several job changes. Give each move a reason. An engineering hiring manager's video on this question says they look for a clear purpose behind frequent moves, such as new skills or broader scope, and some reassurance you won't leave again soon.
Changing careers. This is where the before earns its place. Explain the bridge, then pick proof from your old field that transfers. A teacher moving into product design might describe rebuilding a course after watching students get stuck in it.
First job. A university project, research or internship counts as proof if you can explain what you personally did and decided. Pick one and be ready to go deep.
Returning after a break. Mention it in a single plain sentence (“I took a year out to care for a family member”) and move on. A long explanation makes a normal event sound like a problem.
Where the opening goes wrong
These are the patterns that most often leave the interviewer with nothing to ask about:
- The résumé recital. It leaves the interviewer to work out why any of it matters here.
- The company's story instead of yours. Explaining what the product does at length while your own work stays vague. A widely shared post on behavioral interview mistakes makes the point that a real contribution disappears behind “we” surprisingly easily.
- The memorized speech. It sounds fine until the interviewer interrupts. A product-management interviewer thread describes polished answers that all sound alike and fall apart once the questions get specific. Keep cues, not sentences.
- Opening with hobbies. A personal detail can be a nice last line if it's relevant, but it shouldn't take the place of the work.
Before you walk in
Prepare what your answer invites. Be ready for two or three questions about your proof: what was hard, what you decided and what you'd change. Know where your part ends and the team's begins. Have answers ready for why this job and why you're leaving, because they often come next.
Then write three cues, one each for now, proof and next, and say the answer aloud without notes. Time it. Afterwards, ask whoever is listening: “What would you ask me next?” If they pick the thread you intended, the answer works.