Behavioral Interviews
Strengths, Weaknesses, Gaps in Your Resume and Tricky Questions
Honest answers about weaknesses, career gaps, short jobs, layoffs and switching stacks, and how to handle illegal or awkward questions.
On this page
- Words used in this lesson
- Question: "What are your strengths?"
- Question: "What is your biggest weakness?"
- Question: "Why is there a gap in your resume?"
- Question: "You've changed jobs often. Why?"
- Question: "Were you laid off? Tell me about it."
- Question: "You are a React/Java/PHP developer. Why switch stacks?" (switching technology)
- Question: "Where do you see yourself in five years?" and "What are your salary expectations?"
- Awkward behavior questions
- Illegal and inappropriate questions
- Other tricky questions
- A note on tone
- Worksheet: your awkward-questions page
- Try it
- Self-check list
- Interview questions
- Key takeaways
- What's next
In one line: the awkward questions (strengths, weaknesses, gaps, short jobs, layoffs, switching stacks, and questions that should not be asked) all have the same good answer: tell the truth, briefly, in a calm voice, show what you did about it, and turn back to the future. Hiding or over-explaining is what hurts, not the fact itself.
Everyone has something in their history that feels hard to say. A six-month gap. A job that lasted four months. A layoff. A weakness that is real. A move from one technology to another that looks like a step back. The problem is rarely the fact. The problem is the answer: too long, too defensive, too vague, or untrue.
This lesson takes the awkward questions one by one. For each one: what the interviewer is really asking, a simple shape, a weak and a good spoken answer side by side, and why. Then a section on questions that are illegal or inappropriate in many places, and how to stay polite and protect yourself. At the end there is a worksheet and a self-check list.
It follows lesson 0 (story bank and signals), lesson 1 (the opening questions, including "why are you leaving") and lesson 2 and lesson 3 (the story types). The next lesson, questions you should ask them, moves to your turn to ask. Salary questions are covered fully in lesson 6.
From other series on this site: Career Lesson 0 (a resume guide) is where you decide how to show gaps and short jobs on paper, which this lesson helps you explain in speech. Team Lead Lesson 13 (career growth) helps with the "where do you want to go" side of weakness answers.
What I ran / checked. Nothing was run, since this series has no code. What I read (own words only): the behavioral interview page and the list of 30 common behavioral questions in the yangshun/tech-interview-handbook GitHub repository (raw markdown). The handbook's list includes real questions such as "What is your biggest strength and area of growth?", "What are your three strengths and three weaknesses?", "What aspects of your work are most often criticized?", "What words would your colleagues use to describe you?", "What strengths do you think are most important for this job position?", and "What would your manager say about you?" from public interview reports. It also says interviewers want to see the traits that fit the company and your level, which matches the advice here. For resume gaps, layoffs and illegal questions I used widely known, general interview-prep advice; I did not fetch one specific source and I am not giving legal advice, because rules differ by country and region. Could not reach: rework.withgoogle.com, Harvard Business Review, Ladders, levels.fyi, Glassdoor pages themselves, the official Cracking the Coding Interview site, and any government employment-law page. I claim no details from those. All people, companies and numbers below are invented.
Words used in this lesson
- Strength is a skill or habit that clearly helps your work, and that you can back with a real example.
- Weakness here means a real area where you are still growing, not a disguised strength.
- Growth area is a gentler name for a weakness. It is fine to use it.
- Resume gap is a period between jobs with no work listed.
- Job hopping is changing jobs often, usually under a year or two each.
- Layoff is when a company ends a job because it needs fewer people, not because of the person's performance.
- Stack is the set of technologies you work with, such as React and Node.
- Transferable skill is a skill that works in a new setting, such as debugging or explaining things clearly.
- Discriminatory question is a question about personal traits that should not affect hiring, such as age, religion, family plans or health. Many places have laws about these.
- Deflect means politely steering away from a question without being rude.
- Reframe means describing the same fact in a more useful way, without lying.
Question: "What are your strengths?"
What the interviewer wants
Two things: do you know yourself, and do your strengths match the role? The handbook list has several forms of this: "What is your biggest strength?", "What would your previous boss say your biggest strength was?", "What words would your colleagues use to describe you?"
The shape: strength, proof, use
- Name one or two strengths. Not seven.
- Give a short proof: an example or a number.
- Link to the role: why it helps here.
Choose strengths from the job description. If it says "owns services in production", then "I'm good at debugging in production" is better than "I'm creative."
Weak versus good
Weak (about 20 seconds):
"I'm a hard worker, a quick learner and a great team player. I'm passionate about technology and I always give a hundred percent."
Why weak: five claims, no proof. Every candidate says these words, so they carry no information.
Good (about 60 seconds, about 150 words):
"Two strengths. First, I'm good at finding the real cause of a problem. In my last job, our nightly report was slow and everyone blamed the database. Instead of guessing, I added timing to each step and found that ninety percent of the time was spent in one loop in our own code. Fixing it took an afternoon and the report went from forty minutes to four.
Second, I explain technical things in plain words. Our support team often asks me for help, and a colleague once told me my explanations were the only ones she could repeat to customers.
Both strengths matter in this role, because you described a team that handles live customer issues and needs engineers who can find causes and explain them."
Why good: two, not seven. Each has a short, concrete proof. The ending ties to the role. A friend's quote is a nice small proof.
More strength examples (pick what is true)
| Strength | A one-line proof you could say |
|---|---|
| Debugging | "I found a rare duplicate-order bug by logging IDs across three services." |
| Writing | "My design notes are two pages, and the team uses them as a template." |
| Learning fast | "I moved from Java to TypeScript and shipped a feature in the first three weeks." |
| Reliability | "I add an alert and a runbook line to every service I ship." |
| Working with non-engineers | "Sales asks me to join customer calls when something is technical." |
| Mentoring | "Two juniors I helped were promoted last year." |
| Estimation | "My estimates were within 20 percent on the last six tasks." |
Question: "What is your biggest weakness?"
What the interviewer wants
They don't expect a flaw that ruins you. They want to see self-awareness and a habit of improving. The handbook's list has "What is your biggest strength and area of growth?", "What aspects of your work are most often criticized?" and "What are your three strengths and three weaknesses?". The pattern is the same: name something real, show what you do about it.
The shape: real weakness, effect, what I do, progress
- Name a real weakness that is not central to the job.
- Say the effect it had, briefly.
- Say what you do about it now. Specific habits.
- Show progress, with a small proof.
What not to say
- A fake weakness: "I'm a perfectionist", "I work too hard", "I care too much." Interviewers have heard these a thousand times and read them as dodges.
- A weakness that kills the job: "I get angry at teammates", "I can't meet deadlines" (for a role that depends on that).
- "I have none." Sounds arrogant or unaware.
- A weakness with no action. "I'm bad at public speaking" and stop.
Weak versus good
Weak (about 20 seconds):
"My biggest weakness is that I'm a perfectionist. I like everything to be perfect, so sometimes I spend too much time on details. But I think that's also a strength, because my work is always high quality."
Why weak: the classic fake. It is a strength dressed up. It shows no real self-knowledge.
Good (about 70 seconds, about 175 words):
"One thing I'm working on is that I tend to work alone for too long before showing my work. A couple of years ago I spent nearly two weeks on a feature and then found out in review that the approach didn't fit how the team was designing the rest of the system. I had to redo about half of it.
It taught me that the cost of showing work late is much bigger than the discomfort of showing it early. Now I post a short plan before I start, usually five lines, and I share a draft pull request after the first day or two, even if it's rough.
It's not perfect, and I still have to remind myself. But on my last three features, the review comments were small and I didn't need to redo anything."
Why good: it's real and believable. The cost is shown. The habits are specific. Progress is proven. It is not a disaster for most roles.
Model weaknesses for different people
You must pick something that is true for you. These are examples of honest weaknesses that are acceptable in most roles. Each answer would follow the shape above.
- Asking for help late. "I used to struggle for hours before asking. I now use a thirty-minute rule."
- Saying yes too often. "I used to accept every request. I now say, 'I can do X by Friday, which means Y moves.'"
- Public speaking or presenting. "I get nervous in front of large groups. I volunteered for a five-minute demo each sprint, and it's now much easier."
- Delegating (for a lead). "I used to take the hard tasks myself. I now write what 'done' looks like and hand it over."
- Documentation. "I'd write the code and leave notes for later. I now write the readme as part of the pull request."
- Estimation. "I used to estimate only the happy path. I now give a range and list risks."
- Giving direct feedback. "I avoided hard conversations. I learned a fact-effect-question format and I use it now."
Do not pick a weakness that is the core of the job. If you apply for a backend role, "I don't understand databases" is a problem. If you apply for a role with lots of customer talk, "I avoid talking to people" is too. Pick something real, but not central.
The "tell me about a weakness you have worked on" version
If asked for a story, use a short STAR with the change in the middle. The model above already works for that.
Question: "Why is there a gap in your resume?"
What the interviewer wants
They want a calm, honest, short explanation, and a sign that you stayed connected to the field, or that you are ready to return. Gaps are common: study, family, illness, a move, burnout, a failed startup, a job search that took long, or a layoff. Most reasonable interviewers do not mind a gap. They mind a confused or defensive answer.
The shape: fact, what I did, ready now
- State the reason in one sentence, in plain words. You do not owe medical or family details.
- Say what you did that kept you connected: courses, projects, open source, freelancing, caring for family (that is real work too).
- State you're ready and what you want now.
Weak versus good
Weak (about 25 seconds):
"Um, so there was a period where I wasn't working. It's a bit complicated. I was dealing with some things and then the job market was really bad. I didn't really do much, honestly, just took time off. But I'm ready now."
Why weak: vague and awkward. "Didn't really do much" gives the interviewer nothing. The nervous tone creates doubt that might not otherwise exist.
Good (about 45 seconds, about 110 words):
"I took about eight months out last year to look after a family member who was ill. That's resolved now, and I'm available full time. During that time I kept my skills up: I finished a course on Postgres performance and built a small tool that tracks medication times, which I use myself. It's on my GitHub. I also read a lot about how the stack has changed since I left. I'm ready to get back to full-time work, and I'm particularly interested in this role because it's close to the backend work I did before."
Why good: one clear reason, no over-sharing, shows active learning, shows readiness and a link to the role.
More gap answers
The job search was long
"After my contract ended in March, I spent about five months looking. I was selective: I wanted a team with strong code review and a product I'd care about. During that time I contributed two fixes to an open-source library I use, and I did freelance work for a local shop. I'm glad it took the time, because this role is a much closer match."
Health reasons (keep it short and private)
"I had a health issue that needed about six months of recovery. I'm fully recovered, and there are no restrictions on my work. I used the last two months to refresh my skills with a course and a small project."
You do not need to describe the illness. Don't volunteer details. If someone pushes, a polite line is: "It's resolved, and I'd prefer to keep the details private. I'm happy to talk about the work."
Start-up that failed or a break to build your own thing
"I left to build a small product with a friend. We worked on it for about ten months. It didn't find enough paying users, so we stopped. I learned a lot: I built the whole stack, handled deployments, and talked to customers, which I had never done in a larger company. I'm now looking for a team where I can use those skills with a stable group."
Study, caregiving, relocation
Say it just as plainly. "I took two years to raise a child and returned to full-time work this year." Caregiving is real work, and the right way to say it is without apology.
Never lie about dates. Employers can check dates with background checks and references. A gap is a small problem. A lie found later is a big one.
Question: "You've changed jobs often. Why?"
What the interviewer wants
They are checking for risk: will you leave in a year? They want a pattern with reasons, not a list of excuses. Short stays happen for good reasons: a contract role, a company that shut down, a layoff, a bad match, a reorganisation, or a planned step up.
The shape: pattern, reasons, what is different now
- Say the honest pattern in one line.
- Give a one-line reason for each short stay, with no blame.
- Say what you learned about what you need.
- Say what is different now, with evidence you want to stay.
Weak versus good
Weak (about 20 seconds):
"I've moved a few times because I kept getting better offers. Each company had problems, like poor management, so I left. I'm just looking for the right place."
Why weak: "better offers" suggests money-driven; "poor management" blames. "Looking for the right place" suggests you'll leave again.
Good (about 60 seconds, about 150 words):
"I can see how the last four years look. The first move, after ten months, happened because the agency I worked for lost its main client and cut the team. The second, after a year, was a planned move to a product company. The third was a mistake on my side: the role turned out to be mostly support work, not development as described, and I left after six months.
From that I learned to ask more precisely, before accepting, what a typical week looks like and who I'd work with. I did that for my current role, and I've been here for two and a half years and got promoted once.
I'm looking for a place to stay for several years, and I picked this role for that reason: the work matches what I actually enjoy."
Why good: it accepts how the history looks, gives plain reasons, owns the one mistake, and shows the later evidence (two and a half years, promotion).
A shorter-stay-only version (single short job)
"I joined in March and left in June. The company changed its product direction in my second month and the team I joined was merged into another group. After talking with my manager, we both agreed that it was better for me to find a role closer to the original one. I was upfront with them, and they provided a reference."
(Only say it if true. A reference you can name is very persuasive.)
Question: "Were you laid off? Tell me about it."
Layoffs are common in the software industry. Most interviewers have seen layoffs or been through them. The goal is to be factual, calm and forward-looking.
Rules
- Say it plainly in one or two sentences. Do not apologise.
- Say it was a company decision (if it was).
- Do not complain about the company or the managers.
- Mention what you did next: learning, projects, interviewing.
- Offer a reference from a former manager, if a good one exists.
Weak versus good
Weak (about 25 seconds):
"Yeah, they fired a bunch of us. It was really unfair, and management didn't handle it well. Some of the best people were let go and the company will probably fail anyway. It was a terrible place."
Why weak: anger, blame and prediction. It makes the interviewer wonder how you'd talk about them.
Good (about 40 seconds, about 100 words):
"In March the company reduced its engineering team by about a third, and my team was one of those affected. It was a company-wide decision related to funding, not performance. My last review was positive and my manager is happy to be a reference. It was a difficult moment, but I used the time to finish a course on cloud basics and to build a small side project, and I've been interviewing for roles that fit my backend experience. That's one reason I'm interested in this team."
What if it was a performance exit?
If you were let go for performance, do not claim it was a layoff. Be honest, short, and show growth.
"It was a performance issue. I joined during a big migration, in a stack I hadn't used much, and I was slower to ramp up than they hoped. Looking back, I should have said earlier what I didn't know and asked for more structure. Since then I've spent time deepening that stack, and in my next role I made a habit of asking early and checking in weekly with my manager. I'm happy to share how that went."
Reading this out in a mirror helps. The tone should be calm, not ashamed.
Question: "You are a React/Java/PHP developer. Why switch stacks?" (switching technology)
What the interviewer wants
They want to know if you can learn, if you're committed to the new stack, and whether you'll leave when the novelty fades. For a company hiring in a different stack from yours, they want proof that you can be productive soon.
The shape: why, proof of learning, transferable skills, commitment
- Why you want the new stack (a reason beyond the job market).
- Proof you've started: a project, a course with output, a contribution.
- What transfers: design, debugging, testing, databases.
- Honest about the learning curve.
Weak versus good
Weak (about 20 seconds):
"I know Java is declining and there are more jobs in JavaScript right now, so I want to switch. I know I can learn anything quickly."
Why weak: the reason is only the job market. "I can learn anything" is a claim with no proof.
Good (about 70 seconds, about 175 words):
"I've worked in Java for five years, mostly on backend services, and over the last year I've done more with Node and TypeScript. The reason is that I like how quickly I can build and test small services, and a lot of the front-end teams I work with already use TypeScript, so it makes collaboration smoother.
To check that I'd enjoy it, I rebuilt one of our internal tools in TypeScript on my own time, with tests and a small API. It took about three weeks in the evenings and I'm happy to show you the code.
What carries over is the part that takes years: designing services, thinking about failures and retries, writing tests, and reading unfamiliar code. What I need to learn is the ecosystem details, such as how tools like the build system work, and I'd expect the first two months to be slower. I've done a similar move before, from PHP to Java, and was productive within six weeks."
Why good: a real reason, proof of effort, a clear list of what carries over, honest about the gap, a past example of success.
Moving down in level, or to a smaller company
Sometimes the worry is that you are "overqualified" or taking a step back. Be direct:
"I know the role is a step below my current level on paper. I'm choosing it because I want to focus on building again, and I'm happy to work to grow back up in this team. I'm not looking to do the same as before."
Question: "Where do you see yourself in five years?" and "What are your salary expectations?"
The first is in lesson 1 (see the model answer). The second is covered fully in lesson 6. A short safe line for now, if it is asked very early: "I'd like to understand the role and the level better first. Can you share the range for this position?" That is a polite, standard way to reply.
Awkward behavior questions
"What would your manager say about you?"
"She'd say I'm reliable and clear: when I say a date, it holds, and she doesn't have to chase me. She'd probably also say that I'm sometimes slow to speak up in big meetings, and that she's been encouraging me to share my view earlier. I'm working on that by preparing one point before each meeting."
(Strength with proof, plus one real growth area. Both are plausible and consistent with each other.)
"Why should we hire you over other candidates?"
"I can't judge the others, but I can tell you what I bring. You need someone to 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 from half a million to four million messages a day with fewer incidents. I'm also used to writing short design notes, which helps teams decide. What I'd still need to learn is your domain, and I'd start by reading your support tickets for the first week."
"What do you do when you're stressed?"
"I try to make the problem smaller. I write down what's going wrong and what I control, and I tell my manager early if something has to give. I also keep a stable routine: I go for a walk at lunch. In the one very hard release I had, I made a list of the top three blockers, solved them in order, and updated the team every few hours. Being specific makes stress smaller."
Illegal and inappropriate questions
Some questions should not be asked in many places because they can lead to unfair decisions. Examples: your age, whether you are married, whether you plan to have children, your religion, your health, your nationality or where your parents were born, your political views, your sexual orientation. In many countries there are laws against using these when hiring. The exact rules depend on where you live. This is not legal advice. If you need it, ask a local employment advisor or a government labour office.
Some interviewers ask these without bad intention, because they are making small talk or do not know better. Some ask on purpose. Either way, you have choices. You do not have to answer.
Three ways to respond
- Answer the concern behind the question. Often there is a work-related worry. If you are asked "Do you have small children?", the real worry may be availability. You can say: "I'm able to meet the working hours and on-call requirements for this role."
- Politely deflect. "I'd prefer to keep my personal life separate from the interview. I'm happy to talk about how I'd handle the schedule for this role."
- Decline and note it. If the question continues or is clearly inappropriate: "I don't think that's relevant to my ability to do the job, so I'd prefer not to answer." Afterwards, you can decide if you want to work for this company. How they treat you in the interview is information.
Examples
| Question | A calm response |
|---|---|
| "How old are you?" | "I have eight years of experience and I'm ready to work at a senior level. Is there a particular skill you want me to cover?" |
| "Are you planning to have kids soon?" | "I plan to focus on my work and I can meet the schedule for this role. I'd rather not discuss family plans." |
| "Where are you really from?" | "I'm based in this city now and I've worked here for six years. Happy to talk about my work." |
| "Do you have any health problems?" | "I'm able to do the essential duties of the role. If I need any adjustment, I'll discuss it with HR at the right time." |
| "What is your religion?" | "I'd prefer to keep that private. I'm available for the working schedule you described." |
| "What was your last salary?" | "I'd rather focus on the value of this role. Can you tell me the range for the position?" |
The last row matters. In some places it is illegal for employers to ask about salary history, and in others it is allowed. See lesson 6 for how to handle it. You are generally allowed to decline politely in either case, though in some places it may affect the process.
Stay calm and keep notes. If you feel a question crossed a line, write down the date, who asked it, and what was said, right after the interview. You can decide later whether to tell the recruiter or HR. A short, calm note is more useful than an angry message.
Questions that look odd but are fine
Some questions feel personal but are normal and job-related: "Are you legally able to work in this country?", "Can you work these hours?", "Are you willing to be on call?", "Are you willing to relocate?", "Can you start by this date?" Answer these directly.
Other tricky questions
"What is the worst thing about your current company?"
Do not trash it. Choose something neutral, tied to your growth:
"Honestly, mostly good. The thing I'd change is that our release process is slow, about one release a month, and I'd like to be in a team that ships in smaller pieces more often."
"Have you ever been fired?"
If yes, see the performance exit answer above. If no, say "No" and stop. Do not add a speech.
"What if we ask you to work on something you disagree with?"
"I'd say my concern once, clearly, with facts, to the person who decides. If they still choose that path, I'd help make it work, unless it was unsafe or unethical. In that case I would escalate. Most disagreements are about priorities and not about ethics, and for those I follow the team's decision."
"Do you have any other offers?"
Answer truthfully and calmly. See lesson 6 for details.
"Is there anything on your resume you'd like to explain?"
This is an invitation to address a gap or odd item yourself. Use it. Spend 30 seconds on it, using the shape for that item. If there is nothing, say "No, I think it's clear, but I'm happy to answer any questions."
A note on tone
Awkward answers are about tone more than words. Calm, plain, brief and forward-looking works. Defensive, long and emotional doesn't. Practise saying the awkward part out loud until it feels boring. When a fact is boring to you, it will be boring to the interviewer, and the conversation moves on.
A good habit: make the awkward fact the second sentence, not the first or last, and follow it with something positive and forward. "I took eight months out for family reasons (fact). In that time I finished a course and built a small tool (action). I'm ready to be full-time (future)."
Worksheet: your awkward-questions page
STRENGTHS (pick 2 from the job description)Strength 1: Proof (number or event):Strength 2: Proof:Why it helps in this role:WEAKNESS (real, not central to the job)The weakness:The effect it had once (short):What I do about it now (2 habits):Proof of progress:GAP OR SHORT JOB OR LAYOFF (one card for each)Fact in one plain sentence:Dates (true):What I did in that time:What I learned:Why I'm ready / why this role:Reference I can offer:STACK CHANGEWhy the new stack (beyond the job market):Proof I started (project, link):What transfers:What I still need to learn:PERSONAL QUESTIONS I DON'T WANT TO ANSWERMy polite line:My second line if pushed:Try it
- Write two strengths with proofs from your own work. Check that each proof is a real event or number.
- Write a real weakness. Ask: would a fake weakness have been easier? If so, find the real one.
- If you have a gap, a short job, or a layoff, write the three-sentence answer: fact, action, ready. If you don't, write the answer for a friend's story.
- Write your polite line for a question about family plans or age.
- Say all four aloud. Time them. Strengths about 60 seconds, weakness about 70, gap about 45, polite line about 15.
Answers
- If your proof is "my manager said I'm good", look for a specific event or a number.
- A real weakness usually brings a slight feeling of "I'd rather not say". That feeling is a sign you're in the right place. Choose one that isn't central to the job.
- The best versions have one plain fact, one thing you did, and one forward sentence. If your answer has more than five sentences, trim.
- A good polite line does not accuse, does not give personal detail, and returns to the job: "I'm able to meet the schedule. I'd rather keep personal plans private."
- If your gap answer is over 60 seconds, it's probably over-explaining. Shorter sounds more confident.
Self-check list
- I have two strengths, each with a real proof.
- My weakness is real, not a disguised strength, and not central to the job.
- My weakness answer includes at least two actions and a sign of progress.
- I can explain every gap, short job and layoff in under 45 seconds without blame.
- My dates are accurate and match my resume and online profiles.
- I have the name of one reference who would speak well of me.
- If I'm switching stacks, I have a project or code to show.
- I have a calm line for questions I don't want to answer.
- I know I may decline inappropriate questions and I will take notes after.
- My awkward answers end with the future, not the problem.
Interview questions
What is your biggest weakness? (Must know)
I tend to work alone too long before showing my work. A couple of years ago I spent nearly two weeks on a feature and found out in review that the approach didn't fit the rest of the design, so I redid about half. Now I post a five-line plan before I start and a rough draft pull request after the first day or two. On my last three features the review comments were small and I didn't need to redo anything. I still have to remind myself, but the habit is working.
What are your strengths? (Must know)
Two. I'm good at finding the real cause of a problem. Our nightly report took forty minutes and everyone blamed the database, but I added timing to each step and found one loop in our own code. After the fix it took four minutes. And I explain technical things in plain words: our support team often asks me to join customer calls. Both help in this role, because you work on live customer issues.
Why is there a gap in your resume? (Must know)
I took eight months last year to care for a family member who was ill. That is resolved now and I'm available full time. During that time I finished a course on Postgres performance and built a small tool that I use myself, which is on my GitHub. I'm ready to return, and this role is close to the backend work I did before.
You've changed jobs frequently. Why? (Trap)
I can see how it looks. The first move came after ten months because the agency lost its main client and cut the team. The second was a planned step to a product company. The third was a mistake on my side: the role turned out to be mostly support, so I left after six months. I learned to ask what a typical week looks like before I accept. I've been in my current role two and a half years and was promoted once. I'm looking for somewhere to stay.
Were you laid off? (Must know)
Yes. In March the company reduced its engineering team by about a third, and my team was affected. It was a funding decision, not performance, and my manager is happy to be a reference. I used the time to finish a cloud course and build a small project, and I've been interviewing for backend roles like this one.
Why do you want to switch from Java to TypeScript? (Senior signal)
I've done five years of Java and I like how fast I can build and test small services in TypeScript. Our front-end teams already use it, so working together is easier. To check I'd enjoy it, I rebuilt an internal tool in TypeScript in three weeks of evenings, with tests, and I can show the code. Design, failure handling, testing and reading code carry over. What I'd need to learn are ecosystem details, and I'd expect the first two months to be slower. When I moved from PHP to Java I was productive in about six weeks.
Tell me about a weakness you have worked to improve. (Must know)
I used to estimate only the happy path. On one project I said three weeks and it took seven. Now I give a range and list what could make it longer, such as unclear data or a dependency on another team. I also tell my manager as soon as a date looks at risk. On my last six tasks the estimates were within about twenty percent. I still check myself when I feel optimistic.
What would your manager say about you? (Must know)
She'd say I'm reliable: when I give a date, it holds. She'd also say I'm sometimes slow to speak up in big meetings, and she has been encouraging me to share my view earlier. To work on it, I prepare one point before each meeting. Both are fair, and I think she'd say the second is improving.
Are you planning to have children soon? (Trap)
This is a question I'd prefer not to answer, because it's personal and doesn't affect my ability to do the job. I'd say politely, "I'm able to meet the schedule and on-call requirements of this role. I'd rather keep family plans private." If you have a concern about availability, I'm happy to talk about hours and expectations. I'd also take note of how the company handles it.
You seem overqualified for this role. Why do you want it? (Senior signal)
I understand the worry. I'm choosing this role because I want to spend most of my time building, and my current role has become mostly meetings. I'm also interested in this product and team. I'm not looking to do the same as before, and I'm happy to prove myself and grow in this team. If it helps, I can describe the parts of the role I'm most excited about.
What was the biggest mistake of your career, and what did you do about it? (Must know)
Running a data fix script on production without a dry run. It changed about twelve hundred orders instead of three hundred. I noticed within five minutes, stopped it, told my lead, and we restored from backup within the hour. I then wrote a checklist: dry run, row count check, second reader. It has prevented the same mistake since. I include it because the lesson is about habits, not luck.
Is there anything on your resume you'd like to explain? (Must know)
Yes, one item. There's a four-month job in 2023. The company changed direction in my second month and the team I joined was merged into another group. My manager and I agreed that I should find a role closer to the original. I was open with them and they gave me a reference. I mention it because I'd rather you hear it from me.
Key takeaways
- The fact is rarely the problem. The answer is: too long, too defensive or untrue.
- Strengths: one or two, each with a real proof, linked to the role.
- Weakness: real but not central, with its effect, current habits and a proof of progress. Never "I'm a perfectionist."
- Gaps, short jobs, layoffs: one plain sentence, what you did, ready now. No blame, no lies about dates.
- Stack switch: real reason, proof you started, what carries over, honest about the learning curve.
- Inappropriate questions: answer the work concern behind them, deflect politely, or decline. Keep notes. This is not legal advice, and rules vary by place.
- Make the awkward fact boring: calm, brief, and followed by the future.
What's next
The next lesson is Questions You Should Ask Them, where you take control of the second half of the interview and learn to spot red flags. Later, lesson 6 (salary, offers and negotiation) covers salary-history questions in full. To see how you might show these facts well on paper, go back to Career Lesson 0 (a resume guide).
Published by Jainik · Last updated · How these lessons are made
Keep learning
Related lessons
- A Resume Guide for Software Engineers · Career Playbook
Part of the study guide
Related series