Engineering
Updated 2026-10-18
Practice software engineer interview questions for recruiter, manager, coding, behavioral, and final rounds.
Engineering interviews are a series of working sessions, not a personality quiz. A recruiter is checking level and motive. A manager is checking whether you can own a problem through the messy middle. A technical round is checking how you break a problem down when you do not already know the answer. Later rounds ask whether people can work next to you.
Practice out loud. Writing a perfect paragraph and then reading it sounds nothing like the room. For each story, know the system, your piece of it, the constraint, and what changed because of you. If the work was a class project, a tutorial, or a change you only watched, say that before you describe it. Interviewers notice when the verbs belong to someone else.
You do not need a heroic outage. A small bug you traced, a migration you staged, or a flaky test you made boring are enough if you can say what you tried, what failed, and what you shipped.
Try a free spoken mock for this job: 3 questions, feedback that quotes your own answers. No card.
Start the free mockThis call is about fit and logistics. They want the kind of systems you have touched, the level you are aiming at, and whether your timing matches the team. Skip the architecture lecture. Give a concrete product, your part, and the stack in a sentence or two. Be plain about work you do not want.
1. What have you shipped, and which part of it was yours rather than the team's in general?
What they are checking: They want a real artifact and a boundary around your work, not a company mission statement.
Follow-up: Who used that change, and how did you know it worked?
2. Which languages and systems could you use in the first month, and which ones would you be learning?
What they are checking: They are matching you to the posting and listening for honesty about the gap.
Follow-up: When you last learned an unfamiliar codebase, what did you read first?
3. What pace and ownership are you looking for, and what would make you decline?
What they are checking: They want a preference you can explain, plus any constraint on location, hours, or start date.
Follow-up: Have you left a team because the pace was wrong, and what did you do differently in the search after that?
The manager is hiring someone who can take a fuzzy problem and come back with a plan, a risk, and a result. They have heard a lot of "we" stories. Use "I" for the decisions that were yours and "we" for the work that was shared. If a launch slipped, say what you told people and when.
1. A bug reached users. How did you find it, and what did you change so a similar one would be caught sooner?
What they are checking: They want the symptom, the path you traced, and a guard you added, not a blame tour.
Follow-up: What did you tell the people who were affected while the fix was still in progress?
2. You and a staff engineer or a product partner disagreed on the design. How did you make the call?
What they are checking: They are listening for the constraint you named and for whether you could change your mind.
Follow-up: What did the losing option get right, and where did you write the decision down?
3. A date is close and the remaining work is still large. How do you decide what to cut?
What they are checking: They want a cut you can defend to a user, not a vague promise to work harder.
Follow-up: How did you tell the partner what would not be in the release?
Talk while you think. State the inputs, the failure you are worried about, and the simplest design that could work before you add machinery. If you are stuck, say what you know and what you would look up. Guessing an API name with confidence is worse than describing the behavior you need.
1. How would you design a limit on a public API that several of your own services also call?
What they are checking: They want a key, a window, a behavior when the caller is over the limit, and where the count lives.
Follow-up: What happens to a caller who retries immediately, and how do you keep that from making the pileup worse?
2. A page that used to appear quickly now takes several seconds. How do you find the cause?
What they are checking: They are listening for a path from the browser or client into the service, the query, and the data, one layer at a time.
Follow-up: Which measurement would you capture before you change anything?
3. A cache sometimes returns old data after a write. How would you debug that, and how would you test the fix?
What they are checking: They want the invalidation path, the race you suspect, and a test that fails before the fix.
Follow-up: What would you do for the readers who already received the stale value?
Behavioral rounds for engineers are about collaboration under ambiguity. Pick stories with a technical stake: a hard comment on a change, a slipped project, a corner of the code nobody else knew. Skip stories whose only point is that you are nice.
1. You had to give hard feedback on a teammate's change. How did you do it without wrecking the working relationship?
What they are checking: They want a specific comment, the reason, and how you left the other person able to respond.
Follow-up: What did you change in your own changes after that conversation?
2. A project you owned slipped. What did you tell stakeholders, and what did you do differently the next time?
What they are checking: They want the moment you knew the date was wrong and the smaller plan you offered.
Follow-up: Which early signal do you watch for now?
3. You had to learn an unfamiliar corner of the code because nobody else was around. How did you get oriented?
What they are checking: They are listening for how you read, who you asked, and how you avoided a reckless edit.
Follow-up: What did you leave behind so the next person would not start from scratch?
The last conversation is often with a director or a cross-functional partner. They are checking judgment and curiosity. Ask about on-call, how decisions get written down, and what the first messy area of the codebase really is. Do not ask them to repeat the job posting back to you.
1. Before you accepted, what would you want to understand about the codebase and the on-call load?
What they are checking: They want a candidate who treats production ownership as part of the job, not as a surprise.
Follow-up: What answer would make you pause, and what would you ask next?
2. If the first month felt chaotic, how would you choose what to work on?
What they are checking: They are listening for how you find the real pain, who you ask, and what you would not start alone.
Follow-up: What would you ship in that month so people could see how you work?
Start from the user action and the failure, then add one component at a time. Say the tradeoff out loud before you add a queue, a cache, or a new service. Record yourself once and listen for the minute where you stop explaining and start decorating.
No. A small product, an internal tool, or a school project is usable if you can name the constraint and your decision. Inventing scale you did not have is riskier than describing a modest system clearly.
Say the behavior you want, pick a reasonable name, and keep going. Ask whether they care about the exact signature. Most interviewers would rather see the loop, the edge case, and the test than a memorized import.
Use it if you can say what you noticed, what you changed, and what you would do sooner next time. A tidy success with no decision in it is weaker than a miss you understood. Do not pick a failure that harmed people and then joke about it.
Close to a minute for the first pass. Situation, your decision, the result, then stop. The follow-up is where the depth belongs. If you are still setting the scene after forty seconds, you have not reached the point.
Practice questions written by Round Rehearsal. Not any employer's actual questions.
Try a free spoken mock for this job: 3 questions, feedback that quotes your own answers. No card.
Start the free mock