Software engineer interview questions, grouped by what they test
Group interview questions by what they test: background and motivation at the recruiter screen, past experience in behavioral rounds, project reasoning in technical deep-dives, and clarification plus correctness in coding exercises. Pick a small set, write notes for each, and rehearse the answers aloud rather than memorising scripts.
About 8 min read
Read a question list as a test of evidence, not a script
Question lists are easy to find and easy to misuse. The same questions appear on dozens of sites because interviewers do ask variations of them, but a written model answer does not survive contact with a real conversation. The interviewer hears a rehearsed paragraph, asks one follow-up the paragraph did not cover, and the preparation collapses.
The useful way to read this list is backwards. Each question is a claim that an interviewer might want a certain kind of evidence from you: your motivation, your ownership of a decision, your reasoning under a constraint. For every question you practise, the real work is choosing which of your experiences supplies that evidence, then delivering it clearly enough that a follow-up finds more of it rather than less.
No list predicts your interview. Employers design their own processes, and even inside one company the questions vary by team, level, and interviewer. Treat the groups below as coverage of the common territory, then confirm the actual format with your recruiting contact. Microsoft and Amazon both advise candidates to clarify what the interviews will cover rather than assume a fixed question set.
Reference: Amazon Careers: software development interview topics
Recruiter screen questions: background, motivation, and logistics
The recruiter screen checks whether your background fits, whether you understand what you applied for, and whether the logistics work. Answers here should be shorter and more factual than later rounds: the recruiter is routing you, not evaluating your architecture. Prepare a focused introduction, a specific reason for this role, and accurate answers about availability and expectations.
The questions that travel with these include work authorisation, location and working-arrangement needs, salary expectations, and your timeline. Answer them accurately and decide your numbers in advance; improvising a salary range or a start date under pressure rarely goes well.
- Tell me about yourself. (They want a one-minute map: current work, one relevant example, why this role.)
- Why this company or this role? (They want evidence you read the posting, not flattery.)
- What are you looking for in your next position? (They want a direction they can check against the role.)
- What are your salary expectations? (They want to know whether the conversation is viable before investing more time.)
- Are you interviewing elsewhere, and when could you start? (They want factual answers, not pressure tactics.)
Behavioral questions: what you did, not what the team did
Behavioral questions assume past behaviour is evidence about future behaviour. The trap in every one of them is the same: describing what the team accomplished while the interviewer is still waiting to hear what you personally did. Situation, Task, Action, and Result can organise an answer, but the structure cannot supply a missing decision or an unsupported outcome.
Prepare a small bank of real experiences covering different evidence: a disagreement, an ambiguous task, a mistake, a result you owned, something you learned. Most behavioral questions map onto one of these shapes, so five honest stories rehearsed at different lengths beat fifteen answers you have never said aloud.
- Tell me about a time you disagreed with a teammate. (They want the reasoning on both sides and how it resolved.)
- Describe a project you are proud of. (They want your specific contribution, not the launch announcement.)
- Tell me about a mistake or failure. (They want your part in it and what you changed afterwards.)
- Give an example of working with unclear requirements. (They want how you reduced the ambiguity before acting.)
- Tell me about a time you had to learn something quickly. (They want the actual method and its limits.)
Technical deep-dive questions: reasoning you can defend
A deep-dive starts from work you claim to know and follows it wherever the interviewer wants to go. The questions below look simple; their difficulty is entirely in the follow-ups. Prepare one or two projects well enough that you can move between the summary, the decision, and the implementation detail without changing the facts.
The pattern to rehearse is constraint, choice, cost. Every 'why did you use X' is asking what requirement made X useful, what the alternatives were, and what you accepted by choosing it. An answer that names a technology without those three parts invites exactly the follow-up you are not ready for.
- Walk me through a project on your resume. (They want the problem, your contribution, and a decision.)
- Why did you choose that technology or approach? (They want the constraint, the alternatives, and the cost.)
- What would you do differently now? (They want evidence you learned, not that the project was flawless.)
- How did you verify it worked? (They want to separate a test result from a production claim.)
- What was the hardest technical problem in it? (They want difficulty you can explain, not impressiveness you cannot.)
Coding and system-design questions: think out loud
Coding questions test whether you can turn a prompt into working reasoning, not whether you recognise the problem. Expect to restate the input and output, ask about constraints, explain an approach before optimising it, and test boundary cases. Memorised solutions fail the moment the interviewer changes one requirement, which is the point of changing it.
System-design questions test whether you can make an ambiguous problem concrete. Expect to clarify requirements, state assumptions, propose a baseline, and discuss one failure or scaling concern honestly. The question 'design a notification service' is really asking how you handle missing information. The first minutes of clarifying questions are part of the assessed answer.
- Here is a problem; solve it. (Clarify the contract first: inputs, constraints, edge cases.)
- How would you make this faster? (Name the bottleneck before proposing a fix.)
- Design a URL shortener, a chat system, or a notification service. (Requirements and assumptions come before components.)
- What happens when this part fails or the load doubles? (They want failure behaviour you can reason about.)
- What would you monitor in production? (They want signals connected to actions.)
Choose a small set matched to your real interview
Working through every question on the internet is a way to feel prepared without becoming prepared. Start from the confirmed format instead. A recruiter screen next week needs the first two groups and the logistics answers. A technical loop needs deep-dive and coding practice. A question that cannot appear in your next interview is preparation you can safely postpone.
For each question you keep, write notes rather than an answer: the experience it should draw on, the decision or evidence it needs, and one follow-up you expect. Notes survive a nervous moment and a rephrased question; a memorised paragraph survives neither.
- Confirmed format first: ask the recruiter which stages and subjects to expect.
- Five to ten questions: matched to that format, not the whole list.
- Notes per question: the experience, the evidence, and one expected follow-up.
- One question at a time: finish a spoken rehearsal before adding the next.
Rehearse the answers aloud, then rehearse the follow-ups
The gap between a good written answer and a good spoken one is where most question-list preparation fails. Say each answer once, untimed, and notice where you become vague. That vagueness is the actual preparation task, and it almost never lives where you expected it to.
Then practise the question behind the question. 'Why did you use a queue?' becomes 'what happens when it backs up?' 'Tell me about a disagreement' becomes 'what would your teammate say?' A follow-up you did not prepare is the test of whether the answer was yours. Save the questions that expose weak answers and drill them again; in PrepRole, a Known Question attached to your Target Role repeats exactly that loop.
Frequently asked questions
Are these the questions I will actually be asked?
No list can promise that. These groups cover the territory most software engineering interviews share, but employers design their own processes and interviewers improvise follow-ups. Ask your recruiting contact which subjects and formats to expect, then prepare evidence rather than predicted wording.
Should I memorise model answers?
No. A memorised answer sounds rehearsed and collapses under the first unexpected follow-up. Prepare notes instead: which experience the question should draw on and what evidence it needs. Rehearse aloud so the explanation is yours, not the article's.
How many questions should I prepare?
Enough to cover the confirmed format, usually five to ten. One experience can serve several questions if you change the emphasis rather than the facts. Depth on a small set beats shallow coverage of a long list.
What about questions I cannot answer honestly?
Say what you do know, mark the boundary, and explain how you would find out. An honest gap with a plan reads better than a confident guess that a follow-up exposes. If a question touches experience you genuinely lack, prepare a calm admission rather than a borrowed story.
Practise the next answer
Pick five questions from the groups below that match your confirmed interview format, then answer them in a Mock Session for that Interview Stage. Save any question you want to drill again as a Known Question on your Target Role. The sample trial uses a fictional background and will not ask about your actual experience.
Sources and scope
Employer sources describe their own processes, which may change. The exercises and illustrative examples are PrepRole editorial guidance, not employer questions or hiring criteria.
Related guides
AI feedback can be wrong. A practice Verdict is not a hiring decision.
Sample resume and job · Behavioral · English No account or upload needed.