Behavioral Interviews
Tell Me About Yourself, Why This Company and Why Are You Leaving
Three questions asked in every interview, a simple structure for each, and full model answers for different experience levels.
On this page
- Words used in this lesson
- Question 1: "Tell me about yourself"
- Question 2: "Why do you want to work here?"
- Question 3: "Why are you leaving your current job?"
- A quick combined "walk me through your resume"
- Practising these three
- Worksheet: write your three answers
- Try it
- Self-check list
- Interview questions
- Key takeaways
- What's next
In one line: three questions open almost every interview: "Tell me about yourself", "Why this company?" and "Why are you leaving?" Each has a simple shape. For the first, use present, past, future in about 60 seconds. For the second, use product, work, you. For the third, talk about what you are moving toward, never what you are running from.
These questions look easy, so people do not prepare. That is a mistake. They come first, so they set the mood for the whole interview. A rambling opening makes the interviewer tired. A clear one makes them lean in. They are also the only questions you can be 100 percent sure you will get.
This lesson gives you a structure for each question and then full spoken answers for different levels of experience: a fresher, a developer with a few years, a senior developer, and a person changing careers. Read them aloud. Then use the worksheet at the end to write your own.
If you have not read it yet, lesson 0 explains how interviewers score answers and how to build a story bank. The next lesson, failure, conflict and hard feedback, uses those stories. For a written version of "tell me about yourself", see Career Lesson 0 (resume): a good summary line on a resume and a good spoken introduction are close relatives.
What I ran / checked. Nothing was run, since there is no code in this lesson. What I read (own words only, nothing copied): the "self introduction" page and the behavioral interview pages of the yangshun/tech-interview-handbook repository on GitHub (raw markdown), plus its list of 30 common behavioral questions, which it says were collected from public Glassdoor reports and which include "Tell me about yourself", "Why do you want to work for this company", "Why do you want to leave your current company" and "What are you looking for in your next role." The handbook describes the introduction as a short elevator pitch: who you are, a few highlights with numbers, no life history, and a reason you fit the role. The present-past-future shape and the "product, work, you" shape for "why this company" are common interview advice that I am presenting in my own way; I did not copy them from one source. Could not reach: rework.withgoogle.com, Harvard Business Review, Ladders, levels.fyi, Glassdoor pages themselves, and the official Cracking the Coding Interview site. I do not claim details from them. All people, companies and numbers in the sample answers are invented.
Words used in this lesson
- Elevator pitch is a very short summary of who you are, which you could say in the time of a lift ride.
- Present, past, future is a three-part shape for "tell me about yourself": what you do now, how you got here, what you want next.
- Pull reason is a reason to join a company: something good you are moving towards.
- Push reason is a reason to leave a place: something bad you are moving away from.
- Tailoring means changing your answer for a specific company and role.
- Career switcher is someone moving from another field into software.
- Notice period is the time you must keep working after you resign. More about it in lesson 6.
- Red flag is something in an answer that makes an interviewer worry, such as blaming a former boss.
- Hook is a short, interesting fact that makes the listener want to ask more.
- Scope is the size of what you were responsible for.
Question 1: "Tell me about yourself"
What the interviewer wants
They do not want your life story. They want to know in one minute:
- What do you do, at what level?
- What have you done that is related to this job?
- Why are you here?
- Are you someone I would enjoy talking to for 45 more minutes?
The handbook describes it as an elevator pitch: short, direct and attention-grabbing. It also warns against a history lesson, with every school and every job in order. It suggests to include a few highlights and numbers, and to say why you are a good fit for this role.
The shape: present, past, future
- Present (15 seconds). Who you are now. Role, kind of work, and one highlight.
- Past (30 seconds). Two or three earlier steps that led here and that matter for this job. Skip the rest.
- Future (15 seconds). What you want next, and why this role is the natural step.
Total about 60 seconds, around 150 words. A tip: write the future part first. It forces you to include only the past that supports it.
A bad version and a good version
Here is a weak answer, then a good one. Both are for a fictional developer with four years of experience applying to a mid-sized online learning company.
Weak (about 70 seconds):
"So, um, I was born in a small town and I always liked computers. I did my engineering degree at a state college, and then I did an internship in my third year which was nice. After that I joined a company and worked on a project, then I changed to another company because the pay was better. I have worked on React, Node, Mongo, Docker, some AWS, and I know Java also from college. I'm a hard worker and a team player and I'm looking for a challenging role to grow."
Why weak:
- It starts too far back. The interviewer does not need the town.
- It is a list of events, not a story with a direction.
- "Pay was better" is a push reason, offered for no reason.
- A pile of technologies does not tell the listener what you are good at.
- "Hard worker" and "team player" are empty claims. Everybody says them.
- It ends with nothing about this company or this role.
Good (about 60 seconds, about 160 words):
"I'm a full-stack developer with four years of experience, and for the last two I've mostly worked on the front end of a subscription product for an online bookshop. Recently I led the rebuild of the checkout flow, which cut abandoned checkouts by around a fifth.
I started in a small agency where I built websites for local businesses, and that's where I learned to talk to non-technical clients and ship quickly. I then moved to the bookshop to work on a bigger product with a real team, code review, and tests, and that's where I grew most as an engineer.
What I enjoy most is turning confusing flows into simple ones. I read that your team is working on lesson pages that adapt to the learner, which is exactly that kind of problem, and I'd like to work on it with a larger team and a product that has teaching at its core."
Why good:
- Present first, with a result (a fifth fewer abandoned checkouts).
- Only two past steps, each with the reason it matters.
- It names what the speaker enjoys, which gives a theme.
- The ending connects to this company. It shows research and a reason.
- It is short enough that the interviewer can pick a thread to ask about.
Model answers for different levels
All of the following are first-person, around 60 to 90 seconds spoken. Replace details with your own.
Fresher or student (no full-time job)
"I'm a final-year computer science student, and over the last year I've focused on web development. My main project is a small app that helps students in my hostel share and split bills. About forty people use it every month, and it taught me more than any class, because I had to deal with real users who find bugs I never imagined.
Before that, I did a three-month internship where I fixed bugs in an internal tool and wrote my first automated tests. In my second year I also joined a coding club, where I helped juniors with their first projects, and I enjoyed explaining things as much as building them.
I'm looking for a first role where I can learn from experienced developers and work on a real product. Your graduate program mentions pairing new developers with a mentor, which is exactly what I'm hoping for."
Notes: a fresher's "present" is projects and study. A real number (forty users) and one honest lesson work well. Mentioning mentoring ties to what a junior role needs: learning fast.
Developer with three to five years
"I'm a backend developer with five years of experience, mostly with Node.js and PostgreSQL. In my current job at a logistics software company I own the service that calculates delivery times, which handles about two million requests a day. Last year I cut its median response time from about 800 milliseconds to 200 by fixing a few slow queries and adding a cache.
Before that, I was at a startup for two years where I was one of four developers. I did everything, from database design to deployments, and I learned how to make quick decisions with little information.
I'd like to move to a place where I can go deeper on reliability and work with a larger platform team. From what I read about your payments team, you're moving to smaller services and care about uptime, so it feels like a natural next step."
Senior developer (eight or more years)
"I'm a senior engineer with about ten years of experience, and for the last four I've been the technical lead on a team of six working on a customer data platform. My focus is the parts people avoid: migrations, reliability, and unclear requirements. Last year I led a move of our event pipeline to a queue-based design, which took us from regular weekly incidents to one minor incident in the following six months.
Earlier in my career I worked on front-end performance and then on APIs, so I understand the whole path from browser to database, and I've mentored five engineers, two of whom were promoted.
I'm looking for a role where I can keep leading hard technical work and help the team make better decisions, not only write more code. I understand you're growing the platform group, so I think my experience with migrations and mentoring would be useful from the start."
Notes: seniors show scope (team size, the thing they own), judgement (the hard parts) and people impact (mentoring). Numbers should show change in outcomes, not only effort.
Career switcher (for example, from teaching or sales into development)
"I spent six years as a high-school maths teacher, and two years ago I started teaching myself to program in the evenings. I finished a part-time web course and built three projects. The one I'm most proud of is a quiz app that I built for my own students. They used it for exams, and the feedback they gave me taught me about real users.
What I carry over from teaching is clear explanation, patience with people who are stuck, and handling many tasks with a deadline. What I've added is the technical side: I'm comfortable with JavaScript, React and a basic Node API, and I review my own code with tests.
I'm looking for a junior role in a team that values learning. Because your product is in education, I understand your users in a way that most new developers don't."
Notes: a career switcher's best move is to make the old career a strength and show real proof of work (an app, users, code on GitHub). Never apologise for the switch.
Tailoring in two minutes
Before every interview, change only the last sentence (the future part) and maybe one highlight. The rest stays. This keeps the answer fresh but doesn't need a full rewrite.
Check the job description. Pick the two skills it mentions most. Make sure your "present" or "past" includes evidence of those two.
Do not read your resume aloud. The interviewer has it. Your job is to add what the resume cannot say: the theme, the reason, the direction.
Follow-ups you may get
After your introduction, expect "Tell me more about X" where X is the highlight you chose. So only mention a highlight you can talk about for five minutes. This is a feature: you control where the interview goes.
Question 2: "Why do you want to work here?"
What the interviewer wants
They want to know if you chose them or just sent fifty applications. The handbook's question list has this near the top, and it appears again and again in the company lists. A good answer is specific. A weak answer could be said to any company.
Interviewers also use the question to test your research and your motivation. Someone who is excited about the product usually learns faster and stays longer.
The shape: product, work, you
- The product or mission: one true thing you like about what they make.
- The work: one thing about the engineering or the team that excites you. Use their blog, talks, open source repositories, or job description.
- You: how your experience fits or what you want to learn.
Keep it about 45 to 60 seconds.
Where to look for specifics (15 minutes of research)
- The product itself. Use it for ten minutes. Note one thing you like and one you would improve.
- The engineering blog or talks, if they have them.
- The job description. Underline what they stress.
- Their public code, if any.
- News or product launches from the last six months.
- The interviewer's profile, to see their interests (be professional; do not mention private details).
Do not praise the salary, the brand, or the free food. They are real reasons, but they do not show interest in the work. Also avoid "your company is the best/most innovative." It means nothing.
Weak versus good
Weak (about 25 seconds):
"I've heard that your company is one of the best places to work and it has a great culture. I think it's a very innovative company and I would learn a lot here. Also it's a good brand, and the location is convenient for me."
Why weak: it could be said about any company. No detail shows that the speaker looked at anything. "Convenient location" and "good brand" are about the speaker, not about the work.
Good (about 55 seconds, about 140 words, fictional company that makes scheduling software for clinics):
"Three things. First, the product. I tried your booking page this week as if I were a patient, and I liked that it took only three taps to reschedule. I've waited too long on hold to change an appointment myself, so I care about the problem.
Second, the engineering. In your blog post about moving to event-driven reminders, you explained why you chose to retry late messages instead of dropping them. I like teams that write about their trade-offs, and it's the kind of reliability work I enjoy.
Third, I've spent the last three years building notification systems, so I could add value from early on, and I'd like to learn more about working with healthcare data, which has stricter rules than anything I've handled so far."
Why good: it contains a specific experience with the product, a specific engineering detail, and a bridge to the speaker's experience, plus an honest wish to learn. If the company's blog post is real, the interviewer will smile.
More model answers for different situations
When the company is not famous
"I looked for teams of around thirty engineers because that's where I think I do my best work: people know each other, and one developer can still change how a product feels. Your job post says the first hire on the mobile team would help set the architecture, and that's the kind of ownership I'm looking for. I also read your changelog and noticed you ship weekly, which tells me the team is comfortable with small, safe releases."
When you are applying to a big, well-known company
"Obviously, I know the product, but what draws me is the scale. I've worked with a few hundred thousand users, and I want to learn how to design for hundreds of millions, where a small mistake in a query has real cost. I also want to work in an engineering culture with a strong review process and many experienced people to learn from. Within the team, the search ranking work you described in the job post matches my background in data-heavy back ends."
When you are a fresher with no inside knowledge
"I used your open-source SDK in my college project last semester, and I found a small mistake in the docs and sent a fix, which was accepted. That experience made me curious about the people behind it. Your team seems to care about developer experience, which is something I enjoy, and I'd like to start my career in a place that treats documentation and small details seriously."
(This assumes a true story. If you did not contribute, do not say so. Use a true detail, such as "I read through your SDK examples and liked how short they were.")
Questions you may be asked next
- "What do you know about us?" Give two or three facts from your research. Short.
- "What would you improve about our product?" Be kind and specific. One idea, with a reason, and a respectful tone: "I may be missing context, but..."
- "What are you looking for in your next role?" See the next section.
"What are you looking for in your next role?"
A close cousin of both questions. Use three items, in the order of what matters:
"Three things. First, I want to work on problems where I can see users benefiting, rather than only internal tools. Second, I want to learn from people who are stronger than me in system design, because that's the area I most want to grow in. Third, I want a team that does honest code reviews and talks openly about mistakes. From what I read, this role offers all three."
Make sure the list matches the role. If you say you want to lead a team and the role is an individual contributor with no leadership, the interviewer will worry.
Question 3: "Why are you leaving your current job?"
What the interviewer is really asking
Mostly they ask: will you leave us for the same reason? And: will you speak badly of us one day? They also want to check whether you were pushed out for performance reasons.
The golden rules
- Never bad-mouth your boss, team or company. Even if it is all true. It makes you sound like someone who would do the same to them.
- Lead with what you are moving towards (a pull reason), then add a small, neutral push reason if needed.
- Be brief. Thirty seconds is enough.
- Keep it true. Interviewers often check with references or industry contacts.
- Match your answer to your resume. If you've changed jobs three times in two years, expect probing; see lesson 4.
Weak versus good
Weak (about 30 seconds):
"Honestly, my manager is really toxic. He takes credit for everything, and nobody there appreciates good work. The pay is also low and they keep making us work late. I just can't stay there anymore."
Why weak: it is probably true and it still hurts you. The interviewer pictures you saying the same about them in a year. It sounds emotional, and there is no direction. Even a correct complaint should be turned into a wish.
Good (about 35 seconds):
"I've learned a lot in my current team, especially about building and running a service end to end. But over the last year I've reached the limit of what I can grow into there: the team is small, the architecture is stable, and there are few new problems. I want to work on a larger system with more complex trade-offs and with more senior engineers around me. That's one reason this role stood out."
Why good: it begins with something positive, gives a neutral and believable push reason (limited growth), then points to the future.
Model answers for the most common honest situations
I was laid off
Layoffs are common and the stigma is smaller than you think. Be calm, short and factual.
"My company reduced its engineering team by about a third in March, and my team was part of that. It wasn't about performance, and my last review was positive. I used the time to finish a course on database performance and to build a small project, which I'm happy to show. I'm now looking for a stable team where I can contribute for the long term."
Do not apologise, and do not criticise. If asked for a reference, offer your manager's name, but only if you are sure they'd say good things.
I want to grow, and there is no path
"I've been a mid-level developer there for three years and I've taken on tech-lead tasks for the last year. When I talked to my manager about moving up, we agreed that the team's size meant there was no open senior role in the next eighteen months. I respect that honesty, and it made me realize that to keep growing I need to look elsewhere. This role includes owning design for a service, which is the next step I want."
The company is struggling
"The company is going through a difficult period, with two rounds of cost cutting this year. I'm proud of what I did there, but I want to join a team that's investing in its product, where I can plan for longer than the next quarter."
Say it plainly, with no gossip about leaders or money.
I had a bad manager (diplomatic version)
"I worked with a manager who preferred to give tasks in detail and review each one before I could continue. It wasn't a good fit with how I like to work, which is to own a problem and report back at agreed checkpoints. I learned what working style helps me do my best work, and from the way your team describes ownership, I think it matches."
Notice: no villain. Just a difference in style, and what you learned.
I was bored or stuck on maintenance
"For the last two years I've mainly maintained an older system, and I did it well: incidents went down by about half. But I haven't built anything new from scratch in a long time, and I want to get back to designing and shipping new features. This role has more of that."
I am relocating, or I need a different work arrangement
"My family is moving to this city in June, and I'm looking for a team here. I have enjoyed my current job, and I'm leaving on good terms. When I looked at roles here, yours was the one that matched my backend experience most closely."
I was fired or asked to leave
This is the hardest. Do not lie, and do not over-explain. Say it in one or two lines, take responsibility, and show what changed.
"It was a mutual decision after about eight months. I joined during a big migration and I wasn't ramping up fast enough on a stack I hadn't used before. I should have asked for help earlier and been clearer about what I didn't know. Since then I've spent time building skills on that stack, and in my last role I made a point of asking early. My previous manager can speak about that."
(This is only an example. If your real story is different, use it. A short honest answer beats a clever one.)
The red flags to avoid
| What you say | What the interviewer hears |
|---|---|
| "My boss was awful" | You will blame others |
| "They didn't appreciate me" | You may expect special treatment |
| "I just wanted more money" | You will leave for a higher offer |
| "I hated the technology" | You are not flexible |
| "I'm just looking around" | You aren't committed |
| "I don't know, just felt like it" | You haven't thought it through |
Money is a fair reason, but do not lead with it. If it is the truth, you can put it as one item in a list: "better growth and also compensation that reflects the scope of the role I've grown into." See lesson 6 for more on salary talks.
A quick combined "walk me through your resume"
This question often replaces "tell me about yourself". It asks you to go job by job. Use the same shape, but give each job a single sentence on what you did and what you learned. Spend most time on the most recent job and the one most relevant to the role. Here is a model (about 90 seconds):
"I'll go in order. After college, I joined a small agency for two years. I built client websites, which taught me how to work with deadlines and non-technical clients. Then I moved to an online bookshop for the next three years. That's where I learned to work in a larger team, and for the last year I've led the checkout rebuild, which cut abandoned carts by a fifth. I'm now looking for a role with more depth in system design. The step from agency to bookshop was about learning teamwork and process; the step from here to your company is about learning scale."
Notice the thread: each step has a reason, and the last sentence points to the new role.
Practising these three
- Write the three answers as bullets, not paragraphs.
- Time each. Target: 60, 50 and 30 seconds.
- Say them on a walk. If you stumble, simplify the sentence.
- Ask a friend: "What do you remember?" If they remember the theme, it worked.
- Re-check them the night before. Update the "why this company" paragraph with one new fact.
For a longer routine, Career Lesson 2 (practising well, mock interviews and nerves) shows how to practise with feedback.
Worksheet: write your three answers
Copy this and fill it in.
TELL ME ABOUT YOURSELFPresent (role, level, kind of work):One highlight with a number:Past step 1 (and why it matters here):Past step 2 (and why it matters here):What I enjoy / my theme in one phrase:Future (what I want next):Why this role is the natural next step (one fact about the company):WHY THIS COMPANYProduct: one true thing I tried or learned:Work / engineering: one detail from blog, talk, code, or job post:Me: how my experience fits / what I want to learn:WHY AM I LEAVING (or why did I leave)Real reason, in neutral words:What I'm moving towards:Something positive about the current job (true):One-line version for a tough follow-up:WHAT I'M LOOKING FOR IN MY NEXT ROLE (three things, ranked):1.2.3.Try it
- Write your "tell me about yourself" in the present, past, future shape. Time yourself. If it is over 90 seconds, cut the oldest past step.
- Choose one company you would like to work for. Spend 15 minutes on research and write three specific facts. Then write the "product, work, you" answer.
- Take your real reason for leaving (or wanting to leave) and rewrite it in the neutral, forward-looking form. Check: does it have any word that blames a person?
- Say all three aloud to a friend or a recording. Ask: "Which part could be about any company?" Fix that part.
- Find the one sentence in your introduction that you could not defend with a five-minute story. Remove or replace it.
Answers
- A good intro has one number, one theme and one sentence about the future. If your draft has more than two past steps, trim.
- Specific facts are things like "the changelog shows weekly releases" or "the job post mentions a search team." "Great culture" is not a specific fact.
- Replace words like "toxic", "useless", "unfair" with a description of what you want: "more ownership", "more growth", "a team that ships often."
- The generic part is usually the ending ("looking for a challenging role"). Replace it with a fact about this company.
- If you can't tell a five-minute story about a highlight, an interviewer asking about it will find the gap in seconds.
Self-check list
- My introduction is 60 to 90 seconds and starts with the present, not my childhood.
- It contains one result with a number.
- The last sentence mentions this company or role in a specific way.
- My "why this company" has at least two facts I found myself.
- None of my answers blames a person or a company.
- My "why leaving" starts with something I learned or valued.
- I know my one-line answer if asked about a layoff, a gap or a short stay.
- I have said each answer aloud, at least three times.
- I can talk for five minutes about each highlight I mention.
- I have a ranked list of three things I want from my next role.
Interview questions
Tell me about yourself. (Must know)
I'm a backend developer with four years of experience, mostly in Node.js and PostgreSQL. Right now I own a notification service at an online marketplace, and last year I cut its failed messages from about three percent to under half a percent by adding retries and better monitoring. Before that, I was in a small startup where I did a bit of everything, which taught me to make decisions with little information. I enjoy work where reliability matters, and I'd like to do that in a bigger team. That's why your platform role caught my eye.
Why do you want to work here? (Must know)
I did two things before the interview: I used the product, and I read your engineering blog. I liked how simple the signup flow was, and I liked a post where you explained why you chose to roll out changes slowly to a small percent of users. That's a habit I care about. My own experience is in releases and monitoring, so I think I could help from the first month. I also want to learn from a team that writes about its choices.
Why are you leaving your current job? (Must know)
I've had a good three years there and I learned a lot, especially about running a service in production. Over the last year I've found that I'm no longer learning at the same speed: the system is stable and the team is small, so there are fewer hard problems. I want to join a team with more scale and more senior people. That's what I hope to find here.
What are you looking for in your next role? (Must know)
Three things. I want problems where I can see the effect on users. I want to learn from developers who are better than me at system design. And I want a team that reviews code honestly and talks about mistakes. From what I've read and heard today, this team looks like it offers all three. If one of them turned out not to be true, I would raise it early and openly.
Where do you see yourself in five years? (Must know)
I don't have an exact title in mind, because things change, but I know the direction. In five years I'd like to be someone the team trusts with the hardest technical decisions and who helps other developers grow. Whether that's as a senior engineer or a lead depends on what I'm good at and what the team needs. In the near term, I want to be excellent in this role and learn the domain well.
Walk me through your resume. (Must know)
Sure. I'll keep it to the main steps. I started at a small agency, building websites for local clients, which taught me to ship fast and talk to non-technical people. Then I joined an online bookshop, where I worked in a larger team with code review and tests. For the last year, I led the checkout rebuild, which reduced abandoned checkouts by around a fifth. Each move was about gaining either depth or scale. I'm now looking for the next step in scale, which is why I applied here.
What do you know about our company? (Must know)
From the website and the blog, I know you make scheduling software for clinics, that the product is used by a few thousand clinics, and that you recently moved your reminders to an event-driven design. I tried the patient booking page and the rescheduling took three taps. I also read the job post, which says this team owns the reminders service. I'd be happy to hear if I've missed anything important.
Why should we hire you? (Senior signal)
Based on what you described, you need someone who can take the reminders service from "working" to "reliable at ten times the volume." I've done a similar move: at my last company I redesigned a notification service that went from half a million to four million messages a day, with fewer incidents. I'm also used to mentoring junior developers and writing short design notes, which helps teams make decisions. I also know my limits: I haven't worked with healthcare rules, so I'd ask early and learn fast.
You've changed jobs often. Why? (Trap)
It's a fair question. The first move was because the agency lost its main client and shrank. The second was a planned move to a product company. I've been at my current company for three years and I'm leaving because of growth, not restlessness. I know companies want people who stay and contribute, and I'm looking for a place for the long term. Happy to go into details for any move.
We're a smaller company than your current one. Why would you move? (Senior signal)
I'm looking for more ownership. In a larger company, my work is one piece of a very large system, and a change takes weeks of approvals. In a smaller team I can design, build and see the result with users within days. I know the trade-offs: fewer resources, more varied tasks, less process. I've worked in a small team before and enjoyed it, and I'm comfortable doing work outside my exact job description.
Are you interviewing elsewhere? (Trap)
Yes, I'm talking to a few companies, which is normal at this stage. This role is one of my top choices because of the product and the platform work. I'm happy to share my timeline if it helps you plan. I'd rather not name the other companies. If I get another offer before I hear from you, I'll tell you promptly.
What is your biggest motivation at work? (Must know)
For me it's making something confusing simple, for users or for my team. When I rebuilt the checkout, the part I enjoyed most was watching a user finish in three steps instead of seven. I also get energy from teaching: helping a junior understand a bug is as satisfying as fixing it myself.
Key takeaways
- Prepare these three questions first. They are certain to come, and they set the tone.
- Tell me about yourself: present, past, future, in about 60 seconds, with one number and a link to this role.
- Why this company: product, work, you. Do 15 minutes of research and use specific facts.
- Why leaving: start with something you learned, state a neutral reason, point to the future. Never blame.
- Layoffs, bad managers and short stays can be told honestly in three or four calm sentences.
- Change only the last sentence of your introduction for each company.
- Mention only highlights you can talk about for five minutes.
What's next
Next is Stories About Failure, Conflict and Hard Feedback. These are the hardest stories to tell because they make you feel exposed, and they are also the ones interviewers value most. If you want to see how a lead thinks about the other side of those conversations, Team Lead Lesson 8 (1:1s, feedback, delegation and conflict) is a good companion. For more on your career story, including promotions and levels, see Team Lead Lesson 13 (career growth).
Published by Jainik · Last updated · How these lessons are made
Keep learning
Part of the study guide
Related series