STAR interview questions for software engineers
The behavioral (STAR) interview questions software engineers get keep coming back to the same themes: a hard technical problem you owned, a disagreement, a mistake or failure, influencing people without authority, prioritizing under pressure, and, for senior roles, leading and growing others.
Prepare five or six true stories that each cover several themes, and tell them with STAR: Situation, Task, Action, Result. Spend most of the time on what you did and what changed because of it.
By PickedJobs · Updated
How STAR works for engineers
- Situation (10%): the team, the system and what was at stake, in two sentences.
- Task (10%): what you specifically were responsible for.
- Action (60%): what you did, in order, and why. Say “I”, not “we”; interviewers are assessing you.
- Result (20%): what changed, with a number if you have one, and what you'd do differently.
Aim for about two minutes. Technical detail is welcome, but only as much as the interviewer needs to see your judgment.
The questions, and what each one tests
| Question | What they're looking for |
|---|---|
| Tell me about the most technically challenging problem you've worked on. | Depth, how you break a problem down, and whether you can explain it simply. |
| Tell me about a time you disagreed with a teammate or your manager. | Whether you argue with data, listen, and commit once a decision is made. |
| Tell me about a mistake you made or a project that failed. | Ownership, honesty and what you changed afterwards. Blaming others is the classic wrong answer. |
| Describe a production incident you handled. | Calm under pressure, communication, and fixing the cause as well as the symptom. |
| Tell me about a time you had to deliver with an unrealistic deadline. | Prioritization, negotiating scope and saying no well. |
| Tell me about a time you convinced others to adopt your idea. | Influence without authority: writing it up, prototypes, building support. |
| Describe a time you received difficult feedback. | Self-awareness and whether you acted on it. |
| Tell me about a time you worked with an unclear or changing requirement. | Asking the right questions and shipping something useful anyway. |
| Tell me about something you improved that nobody asked you to. | Initiative and judgment about what's worth doing. |
| Tell me about a time you helped a teammate grow. (Senior and up) | Mentoring, code review and raising the bar for the team. |
| Describe a technical decision that affected several teams. (Staff and up) | Scope, trade-offs, and bringing other teams along. |
Example answer: a disagreement
Question: “Tell me about a time you disagreed with a technical decision.”
- Situation: “Our team planned to split the monolith's billing module into its own service before the holiday peak.”
- Task: “I owned billing reliability and thought the timing put our busiest weeks at risk.”
- Action: “Rather than argue in the meeting, I pulled six months of incident data and showed that most billing incidents came from two slow queries, not the architecture. I wrote a one-page proposal: fix the queries and add load tests now, split the service in January. I shared it with the tech lead first, then the team, and offered to own the January migration plan.”
- Result: “We went with the proposal. Billing had no incidents over the peak, p95 latency fell by 60%, and we split the service in February with the load tests already in place. I learned to bring data before opinions.”
Example answer: a mistake
Question: “Tell me about a mistake you made.”
- Situation: “I shipped a database migration that locked a large table for eight minutes during business hours.”
- Task: “It was my change, so the recovery and the follow-up were mine.”
- Action: “I rolled back, posted updates in the incident channel every few minutes, and wrote the postmortem the same week. The root cause was that our staging data was too small to show the lock. I added a check to CI that flags locking migrations and wrote a short guide on online schema changes.”
- Result: “The check has caught four risky migrations since, and the guide is now part of onboarding. I now test migrations against production-sized data.”
Notice what both answers do: they're specific, the speaker's own actions are clear, and they end with a measurable result and a lesson.
Build a story bank
List your five or six strongest stories down one side and the themes above across the top, and tick which stories cover which themes. Every theme should have at least one story, and your best stories should cover several. Write each one out once with the STAR method answer builder so the numbers and order are settled; your resume bullets are a good source, and the resume bullet point generator works in the other direction too.
Common mistakes
- Too much situation: five minutes on the system's history before anything happens.
- “We” throughout, so the interviewer can't tell what you did.
- No result, or a result with no number or outcome.
- A “weakness” story that is really a boast.
- Criticizing former colleagues.
After the interview
Send a short thank-you that mentions something specific from the conversation; the interview thank-you email generator drafts one. If an offer follows, read how to negotiate a software engineer job offer, and before applying, tailor your resume to the job description.