Interview prep ยท questions
Behavioral interview questions
10 questions, from core to senior. Say your answer out loud first, then open the model answer and check it against the points a strong answer covers.
Tell me about yourself.
Show the model answer
Give a short work summary in three parts: present, past, future. Start with the present: your role, your main stack and the kind of product you work on now, in one or two sentences. Then the past: choose two real achievements from your own projects that match this job. For each one, give your part and a result, with a number if you have one. Then the future: what you want next and why this role fits. Leave out your childhood, a list of every job and private details. Do not read your resume aloud, because the interviewer has it. Talk for 60 to 90 seconds, then stop, so the interviewer can choose what to ask about. Write this answer down, say it aloud several times, and change the two achievements to fit each company.
A strong answer covers
- Present first: role, main stack and product, in one or two sentences
- Two real achievements that match this job, each with my part and a result
- Future: what I want next and why this role fits
- 60 to 90 seconds, and then I stopped
- No reading of the resume and no private details
Likely follow-up
Which of those projects are you most proud of, and why?
Tell me about the most complex project you have led.
Show the model answer
Choose one real project where you made the main technical decisions, and tell it in the STAR order: situation, task, action, result. Start with one sentence that names the project and says why it was complex: scale, unclear scope, old code, many teams or a hard deadline. Give the situation and your task in two or three sentences. Spend most of the time on your actions. Say which options you compared, what you decided and why, how you divided the work, and one real problem you solved. Say 'I' for your own work and 'we' for the team's work, so your part is clear. End with the result: what was released, a number if you have one, and what you would do differently now. Avoid a long tour of the whole system, and do not take credit for the work of others. Talk for two to three minutes.
A strong answer covers
- First sentence: the project and why it was complex
- STAR order: situation, task, action, result
- Most of the time on my actions and decisions, with the reasons
- A result with a number, and one thing I would do differently
- Two to three minutes; 'I' for my work and 'we' for the team
Likely follow-up
What was the hardest technical decision in that project, and what was the alternative?
Tell me about a time the requirements were unclear.
Show the model answer
Use a real task from your own work where you had to find out what was needed before you could build it. Say first, in one sentence, what was unclear and what was at risk. Then show your method, because the interviewer scores the method. Say which questions you asked and who you asked: the product manager, the designer, users, or the data. Say how you wrote down your assumptions and got them confirmed. Say how you reduced the risk: a small prototype, a first version behind a flag, or the smallest part that could be shown early. End with the result and with what you do now because of it, for example a short written scope before work starts. Do not blame the product manager, and avoid a story where you waited for someone to decide or guessed in silence. Keep it to about two minutes.
A strong answer covers
- First sentence: what was unclear and what was at risk
- The questions I asked, and who I asked
- Assumptions written down and confirmed
- A small first version or prototype to learn early
- No blame; about two minutes; ends with the result and what I do now
Likely follow-up
What do you do when you cannot reach the person who can answer your questions?
Tell me about a production issue you handled.
Show the model answer
Choose a real incident where you took part in the fix, and tell it in time order. Start with the effect: what users saw, how many were affected, and how the team found out, for example an alert or a support ticket. Next, say how you reduced the harm first: a rollback, a feature flag turned off, or a quick patch. Helping users comes before finding the cause. Then the investigation: what you checked, what the root cause was, and the lasting fix. Include communication: who you informed and how often you gave updates. End with prevention: the test, the alert or the process change that was added so it does not happen again. Do not blame a person; talk about the system that allowed the mistake. If you caused the issue, say so plainly. Keep it to two or three minutes.
A strong answer covers
- Effect first: what users saw, how many, and how we found out
- Harm reduced before the root cause: a rollback, a flag turned off or a patch
- The root cause and the lasting fix, in plain words
- Who I informed, and how often
- Prevention added after it: a test, an alert or a process change; no blame
Likely follow-up
How long did it take to notice the problem, and how would you notice it sooner next time?
Tell me about a disagreement with a teammate, a designer or a product manager.
Show the model answer
Choose a real disagreement about work, not about a person, that ended with a decision. Start with one sentence on the subject and why it mattered. Describe the other person's view fairly, as that person would describe it; many candidates skip this part. Then give your view and the reason behind it. Next, say what you did to settle it. For example, you asked questions to understand the goal, brought data or a small prototype, or wrote down the options with their costs. Say what was decided. If your view lost, say that you supported the decision fully and what you learned. Avoid a story where you were simply right and the other person was simply wrong, and never speak badly about a colleague. End with how you worked together after it. Keep it to about two minutes.
A strong answer covers
- A work subject, told without attacking the person
- The other side's view, described fairly
- What I did to settle it: questions, data, a prototype, written options
- The decision, and my full support for it even if it was not my choice
- How we worked together after it; about two minutes
Likely follow-up
Tell me about a time you disagreed and later saw that you were wrong.
Tell me about a technical decision you got wrong.
Show the model answer
Choose a real decision that was yours, that had a real cost, and that you corrected. Do not choose a hidden strength, such as working too hard. Do not choose a failure so large that it raises doubt about your judgment. Give the decision and its context in two sentences: what you chose, and why it looked right with what you knew then. Then say plainly that it was wrong and how you noticed: a signal, a number or a complaint. Own it; do not move the blame to the deadline, the team or the requirements. Spend most of the time on what you did next: how you told the team, how you fixed it, and what it cost. End with the lesson as a habit you have now, for example a short design note or an earlier review. Two minutes is enough.
A strong answer covers
- A real decision that was mine, with a real cost
- Why it looked right then, in two sentences
- A plain statement that it was wrong, and how I noticed
- What I did to fix it, and what it cost
- A concrete habit I have now because of it; no blame on others
Likely follow-up
How do you decide now when a technical decision needs a second opinion?
How have you helped another developer grow?
Show the model answer
Answer with one real example about one person, not with general words about mentoring. Start with the person's role, not the name, and what the person needed: for example a junior developer new to the codebase. Then describe what you did in concrete terms. It can be pair programming on a real task, or code reviews that explain the reason and not only the fix. It can be a task a little above the person's level, or a document that answers a common question. Show that you let the person do the work and did not take the task over. End with the result for that person: what they can do alone now. Do not sound superior, and avoid a story that is really about your own output. If you were never a formal mentor, use reviews, onboarding or pairing. Keep it to about two minutes.
A strong answer covers
- One real person and what they needed, with no name
- Concrete actions: pairing, reviews that explain why, a chosen task, a document
- The person did the work; I did not take it over
- The result for that person: what they can now do alone
- About two minutes, and not a story about my own output
Likely follow-up
How do you give feedback on a pull request that has many problems?
Tell me about shipping under time pressure. What did you cut?
Show the model answer
Use a real release where the date was fixed and you had to choose. Say first what the deadline was and why it could not move. Then show that you reduced scope with a clear method and did not reduce quality at random. Say how you sorted the work: what users needed on the first day, what could come a week later, and what could be dropped. Say who agreed to the cuts: the product manager or the client. It must not be a silent decision. Name what you refused to cut and why, for example tests for the main flow or error handling. If you accepted technical debt, say how you recorded it and when you fixed it. End with the result and with what you would do differently. Avoid a story about working nights to do everything. Keep it to about two minutes.
A strong answer covers
- The deadline, and why it was fixed
- How I sorted the work: needed on the first day, later, dropped
- The cuts were agreed with product or the client
- What I refused to cut and why, for example tests for the main flow
- Technical debt was recorded and fixed after; about two minutes
Likely follow-up
Looking back, did you cut something that you should have kept?
Why do you want to work here, and why are you leaving your current job?
Show the model answer
Say why you want this job first, and keep the reason for leaving short and about the future. For this company, give two or three specific reasons from your own research. One can be the product and who uses it. One can be the engineering: the stack, a blog post or an open-source project. One can be how the role matches work you have done and liked. Avoid reasons that fit any company, such as a good culture, and do not put the salary first. For leaving, give one true reason that looks forward: a larger product, more ownership, a new domain, or an international team. One sentence is enough. Never speak badly about your current employer, manager or colleagues. The interviewer will imagine you saying the same about them. Be honest and do not invent enthusiasm. Keep the whole answer to one or two minutes.
A strong answer covers
- Two or three specific reasons from my own research on the product and the engineering
- The role is connected to work I have done and liked
- One true, forward-looking reason for leaving, in one sentence
- Nothing negative about my current employer, manager or colleagues
- No reason that fits any company; one or two minutes
Likely follow-up
What would make you stay at your current company?
What are your salary expectations? And what questions do you have for us?
Show the model answer
For the salary, say a researched range in one sentence, then stop talking. Before the call, find out what this kind of role pays for your level and for remote work or your location. Make the bottom of your range a number you would be glad to accept, because the offer is often close to the bottom. Say the currency, gross or net, and per month or per year. Then stay silent and let the interviewer answer. Do not explain, apologize or lower the number yourself. For your own questions, always have three ready, because having none looks like no interest. Ask what success looks like in the first three months. Ask how the team decides what to build and how code reaches production. Ask what the hardest problem for the team is now. Do not ask what their website already answers.
A strong answer covers
- A researched range, with the bottom at a number I would be glad to accept
- One sentence: currency, gross or net, per month or per year
- Then I stopped talking and waited
- Three questions ready: success in the first months, how the team works, the hardest problem now
- No question that their website already answers
Likely follow-up
That is above our budget. Can you be flexible?