Interview Questions to Ask a Software Engineer
For a hiring manager or engineering manager interviewing a software engineer, including one whose stack you do not know well. The questions follow the order of the conversation: work the candidate has shipped, design decisions, debugging and incidents, code quality, working with product and other engineers, then growth and fit. They are written as questions for a manager to ask, so the answers can be judged on specifics, ownership and reasons by someone who does not write code in the candidate's language.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Shipped work
What is the most recent thing you shipped, and who uses it?
Why ask it
Opening here gets you a product, an audience and a rough date in one answer, and it gives every later question something real to refer back to. If the scale is vague, ask roughly how many people use it and how they know that. An engineer who cannot say who the users were may have worked a long way from the result.
On the last project you shipped, which decisions were yours and which were handed to you?
Why ask it
Job titles hide this. The person who chose the approach and the person who built from someone else's ticket can both say 'I built it', and those are different hires. A useful follow-up is who would have been called if it broke at night.
Walk me through one project from the first request to the day it went live.
Why ask it
The order of the story is how they work: whether they questioned the request, when they first showed anyone a rough version, how it was released. Notice the stage they hurry past and go back to it.
Which programming languages and tools have you used most in the last two years, and what did you build with each?
Why ask it
Tying each tool to something built turns a resume list into evidence. If your stack is not on their list, ask what was hardest the last time they changed languages, because that story forecasts their first months with you better than a keyword match does.
What is the hardest technical problem you have solved, and what made it hard?
Why ask it
You can weigh this without following every term. After the story, ask for the first thing they tried and why it failed. A hard problem nearly always has a failed attempt in it, and the candidate can say what that attempt taught them. A problem that was only large tends to have none.
Once something you built was live, how did you know it was doing its job?
Why ask it
Strong answers contain a measure: fewer support tickets, a faster page, a team that stopped doing something by hand. 'It shipped and nobody complained' means their attention ended at release, which matters if you need someone to own a result and not only a task.
What have you built that was later cut, rewritten or never used?
Why ask it
Wasted work is ordinary in software, so a candidate several years in with no example is either very lucky or leaving something out. Ask when they first suspected it would not be used and what they did with the suspicion. The engineer who raised it early and was overruled has a different story from the one who kept building in silence.
What is the largest codebase you have joined partway through, and how did you find your way around it?
Why ask it
Most engineering jobs are a codebase somebody else started, so this is closer to the daily work than any from-scratch story. Real methods include making one small change to see what it touches, reading a file's history to learn why it looks the way it does, and sitting with whoever has been there longest. Then ask what they would put in a guide for the next person to join it.
Design
Tell me about a technical decision where you had two reasonable options. How did you choose?
Why ask it
This is the trade-off question in its plainest form. A good answer states what each option cost, such as speed now against flexibility later, and what tipped it. Be wary when the rejected option is described as simply wrong, since a real choice has a loser with merits.
Here is a small piece of what our team builds. How would you design a simple version of it? Think out loud.
Why ask it
Choose something real and small, such as your sign-up form or a nightly report, so the answer cannot have been rehearsed. If you cannot grade the design, grade the process: before proposing anything, do they ask how many people will use it, what must never fail and what can wait?
What do you need to know about a feature before you start building it?
Why ask it
Count the questions they list. Who it is for, what happens when it goes wrong, what already exists and how success will be judged are the common ones. An engineer with none will sometimes build the wrong thing very quickly.
Tell me about a time you chose the simpler solution over the more interesting one.
Why ask it
Good engineers feel the pull of the clever build, and the experienced ones can name an occasion they resisted it. Ask what the simple version could not do, and whether anybody ever needed that.
When have you taken a shortcut on purpose, and what happened to it afterwards?
Why ask it
Technical debt, asked as a story. A full answer has a reason for the shortcut, a ticket or note left behind, and a later day when it was repaid or judged not worth repaying. 'I never cut corners' tends to mean missed dates or a short memory.
Tell me about code you rewrote or cleaned up. How did you get the time for it, and how did you know nothing broke?
Why ask it
Cleanup competes with features for the same weeks, so the first half shows whether they can argue for it in terms a manager can act on: fewer incidents, quicker changes, a release that stops needing a weekend. The second half separates careful from brave. Tests written before the rewrite, or the old and new code run side by side for a while, are the careful versions.
How do you decide between building something yourself and using a library or service that already exists?
Why ask it
There should be costs on both sides: the time to build and look after your own, against the fee, the dependence and the day an outside tool changes underneath you. Rules about licenses and approved vendors differ by employer, so ask how that worked at their last one.
Tell me about a design decision you got wrong. When did you find out?
Why ask it
The gap between the decision and the discovery is the interesting part. Caught in review or in the first week of use, it says the team had ways to catch things. Found a year later through an outage, it says something else, and in both cases you can ask what they check now.
How do you plan for a system growing, whether that means more users, more data or more people changing the code?
Why ask it
Two weak answers sit at opposite ends: no thought at all, and a design sized for a million users the product may never see. The sound middle is knowing which part would give way first and keeping that part easy to change.
Where does security come into your work, and when did it last change what you built?
Why ask it
The second half keeps this from becoming a recital. You are checking that it shows up early in their thinking: who is allowed to see this, what a stranger could send to it, where passwords and keys are kept. Handing all of it to a separate team is a gap even where such a team exists.
Debugging
Something that worked yesterday is broken today. What do you do first?
Why ask it
The steady answer is to find out what changed: a release, a setting, a dependency, the data coming in. Proposing a fix before reproducing the problem is the weak pattern, and you can hear it without knowing the technology.
Tell me about the bug that took you longest to find. Where did the time go?
Why ask it
Long hunts usually stall on one wrong belief, such as 'that part cannot be the problem', so ask which belief it was and what finally made them test it. An engineer who can name it has changed how they search. One who only names the culprit is likely to lose the same days again.
Tell me about a time something you worked on failed for real users. What did you do while it was down?
Why ask it
Separate two things as they talk: what they did to get users working again, and what they did to find the cause. Engineers who have been through a few outages restore service first, even if that means switching the new thing off, and investigate afterwards. Ask who they kept informed while it was happening, and how often.
After an outage or a bad release you were part of, what changed so it could not happen the same way again?
Why ask it
A fix repairs one failure, while a new test, alert or release step repairs the whole kind. If nothing changed, ask whether anyone held a review afterwards and how blame was handled there, which tells you what they will expect from you.
How do you find out something is wrong before a customer tells you?
Why ask it
Monitoring, alerts, dashboards and logs are the words to expect. The sorting detail is whether they set any of it up or only looked at what others built. Try asking which alert they would add to the last thing they shipped.
A user reports a problem you cannot reproduce. What next?
Why ask it
Patience is being tested here as much as skill. Good answers collect detail from the user's side: exact steps, the account, the time it happened, the device, the logs for that minute. 'It works on my machine' as a stopping point is the one to worry about.
The application is slow and nobody knows why. How would you investigate?
Why ask it
Ask which number they would look at first. A sound answer times the request to see where the seconds go, and only then names a suspect. If the opening sentence blames the database, the network or the framework, they have chosen a culprit before measuring anything, and you can spot that without knowing the system.
Have you been on call? Tell me about an alert that came at a bad time.
Why ask it
Skip this if the role carries no on-call duty, and describe your own setup before asking, since rotation, pay and time off for it vary from one employer to the next. The story shows how they reason when tired and alone, and whether they knew when to wake someone else.
When you are stuck, how long do you go before asking for help, and what do you bring with you?
Why ask it
There is no correct number of minutes, but there should be a number, and it should shrink when something is on fire. What they bring is the part colleagues feel day to day: 'it does not work' costs someone an hour, while 'I tried these two things and here is the exact error' costs them five minutes.
Code quality
How do you know a change is ready for someone else to review?
Why ask it
Have them describe the last change they sent, not an ideal one. You are listening for work done on the reviewer's behalf: a description of what changed and why, a change small enough to read in one sitting, the failure case already tried. Engineers who skip this turn every review into two or three rounds.
What do you write tests for, and what do you decide is not worth testing?
Why ask it
Both halves need an answer. Testing everything is as much a tell as testing nothing, because neither shows judgment about where a mistake would hurt. Money, permissions and anything hard to undo should land in the first half.
Tell me about a bug your tests missed. Why did they miss it?
Why ask it
It shows whether tests are a tool they keep improving or a box they tick. Honest reasons include a test that checked the wrong thing, sample data that was too tidy, and two parts that worked alone and failed together.
What do you look for when you review someone else's code?
Why ask it
Correctness and readability are the expected start. Stronger reviewers also ask whether the change should exist at all, whether it is tested and what happens when it fails. Then ask what they let go, because a reviewer who contests every style preference slows a team down.
Tell me about review feedback you disagreed with. How did it end?
Why ask it
The route matters more than who won. A week of argument in the comment thread and a silent surrender are the two poor versions. A short call, a reason given and a decision either way is the good one.
How do you word a critical comment on a colleague's code? Give me the sentence you would type.
Why ask it
Asking for the sentence gets you past 'I try to be constructive'. Questions with a reason attached, such as 'what happens if this list is empty?', tend to land better than verdicts. Ask whether the wording changes for someone senior to them, since staying silent upward is a common gap.
What do you write down about your code, and who is it for?
Why ask it
Comments in the code, a README, a record of why a decision was made and a runbook for whoever is on call serve four different readers, and most engineers favor one. Ask what a new hire would read on day one with the last thing they built. 'The code documents itself' can be true of what the code does and is rarely true of why it was built that way.
Describe code you inherited that was a pleasure to work in. What had the author done right?
Why ask it
Praise for someone else's code reveals their own standards without a lecture on clean code. Clear names, small pieces, tests that show intent and a comment on why the odd part is odd are the usual ingredients. If they can only recall bad codebases, note the tone.
How do you release a risky change safely?
Why ask it
You may not know the names they use, such as feature flags, staged rollouts or canary releases, so ask two plain things: who gets the change first, and how long it takes to undo. A good answer has a small first audience and a way back measured in minutes. How releases are approved differs from company to company, so ask how it worked on their last team.
What does 'done' mean to you for a piece of work?
Why ask it
'Merged' is the thinnest definition and 'released' is better. The fullest one goes on: released, watched for a day or two, documented, ticket closed. The answer is also a forecast of how much chasing you would do as their manager.
What part do AI coding assistants play in your work, and how do you check what they give you?
Why ask it
Rules on these tools vary by employer, and some do not allow company code to be pasted into them, so tell the candidate where you stand first. Then ask for the last suggestion they threw away and why. The standard you are checking is the same with any tool: being answerable for a line they did not type.
Teamwork
Explain something technical you worked on recently as if I had never written code.
Why ask it
This is the one question here where not knowing the candidate's stack helps, because you are the audience they will have in every planning meeting. Interrupt once with a basic question and see what happens. Someone who backs up and tries another route will do that for your product managers, and someone who repeats the same sentence more slowly will do that too.
Tell me about a time you pushed back on a requirement. What happened?
Why ask it
Pushback worth hiring comes with a reason and an alternative, along the lines of 'that takes six weeks, but this version takes one and covers most cases'. If the decision went against them, ask what they did next. Building the agreed version properly is the ending you want to hear.
A product manager hands you a request that is vague. What do you do with it?
Why ask it
A good answer shrinks the vagueness before any building: a few pointed questions, a rough sketch, a small first version for people to react to. Get a real case, and find out where they went when no answer came.
You have a bug to fix, a feature due this week and a colleague waiting on your review. What do you do first?
Why ask it
No order is correct every time, and that is why it is worth asking: you want to hear what they would find out before choosing. Who the bug affects, what slips if the feature is late and how long the colleague has been blocked are the usual things. Some clear the review first because it frees another person and others go straight to the bug, and either can be right with a reason attached.
Tell me about a disagreement with another engineer over how to build something. How was it settled?
Why ask it
Technical arguments are normal, and how they end is what you are hiring. Good endings are a quick prototype, a decision by whoever owned that area, or an agreement to revisit with data. Then have them argue the other engineer's side for thirty seconds.
Think of the last estimate you gave that was badly off. What had you missed?
Why ask it
Everybody misses estimates, so what you are after is whether they know their own pattern: forgotten testing time, a wait on another team, a requirement that moved. An engineer who knows the pattern can tell you what they add to an estimate now because of it.
A deadline you own is at risk. Who do you tell, when, and what do you say?
Why ask it
The answer you want is early and specific: the day they know, with what is finished, what is left and what could be cut. Engineers who stay quiet and hope to catch up are how managers get surprised on release day.
Have you mentored or onboarded another engineer? What did you actually do?
Why ask it
'Actually do' is there to get past 'I am always happy to help'. Pairing sessions, a first task chosen on purpose and reviews with explanations in them count as mentoring. With a junior candidate, turn it around and ask what the best help they ever received looked like.
What did a normal week look like on your last team, from planning to release, and what would you change about it?
Why ask it
Scrum, Kanban and 'agile' mean something different at every company, so the week is more informative than the label. Their complaint is the useful part, since it names what would chafe on your team. If your process has the thing they disliked, say so now.
How much direction do you want on a piece of work: a problem to solve, or a ticket with the steps laid out?
Why ask it
You would be the one giving the direction, so compare the answer with how you really hand out work, not how you would like to. Neither preference is a fault. An engineer who wants a problem and room will chafe under detailed tickets, and one who wants the steps can stall when given only a goal and a date.
Growth and fit
What drew you to this role, and what kind of engineering work are you hoping it holds?
Why ask it
Most candidates expect some form of 'why this job', and naming the work they hope for is what makes the answer usable. Compare the work they describe with what the team will be doing over the next two quarters. If they picture building new things and the job is mostly keeping an older system healthy, both of you should know that today.
How do you keep your skills current, and what did you last learn that you then used at work?
Why ask it
'How do you keep current' asked alone gets a list of newsletters and podcasts, so the question goes on to ask what came of it. A real answer names the thing learned and the piece of work it went into, and can say what it replaced. Wide reading with nothing applied is a pleasant habit and tells you little about how they improve.
How do you get productive in a language or system you have never used?
Why ask it
Give this extra weight when your stack is not theirs. A method, such as building something small, reading existing code and finding the person who knows, predicts how the first month will go. Ask how long it took last time before something of theirs was in use.
Which kind of problem makes you lose track of time, and which do you put off?
Why ask it
Preferences come out here without the candidate having to rule themselves out. Some engineers are happiest inside a deep bug, others with an empty file, others tidying a system nobody else will touch. If the kind they put off makes up much of this job, tell them and see how they respond.
In a few years, do you see yourself going deeper technically, leading people, or something else?
Why ask it
Whether your company has a senior technical path beside the management one is something only you can answer, so answer it in the room. An engineer who wants to lead people on a team with no opening for it may well be looking again before long.
What would you want to know about our code and how we release it before you said yes?
Why ask it
Have honest answers ready on how much is tested, how often you release, who is on call and how old the oldest code is, because those come up most. A candidate with no questions at all about the codebase has not pictured the daily work yet. Describing it as better than it is only moves the disappointment to their first month.
Running the manager's interview with a software engineer
Practical guidance for the conversation itself
Setting up the manager's round
Find out what the technical round covers
Many processes pair the manager's conversation with a technical round, such as a coding exercise or a design session run by engineers. What a hiring process may include differs by employer, so check how yours is set up. Then divide the ground: the engineers test whether the candidate can write and reason about code, and your hour covers judgment, ownership and what they would be like to work with. Compare notes only after each of you has written your own.
Start from the work waiting for this hire
Before choosing questions, ask the team what the new engineer's first projects will be. If the answer is keeping a ten-year-old billing system running, lean on Debugging and Code quality. If it is a new product in an empty repository, lean on Design and Teamwork. Shipped work opens the interview in both cases, because the later groups keep referring back to it.
Change the list for a junior or a senior candidate
A candidate for a first job will not have been on call or lived through an outage, so skip those questions and the mentoring one, and let Shipped work be a course project, an internship or a tool built for a friend. With a senior engineer, spend most of the hour in Design and Debugging and add the estimating and mentoring questions from Teamwork. At that level, costs and alternatives should come up before you ask for them.
Tell the candidate what kind of hour this is
Engineers often arrive braced for a whiteboard. Say at the start that this is not the coding round, that you will mostly ask about work they have done, and that you may stop them to ask what a term means. It settles nerves, and it lets them explain things plainly instead of performing for a specialist who is not in the room.
One way to spend sixty minutes
Ten minutes on Shipped work, using the first three questions as a single thread. Ten each on Design, Debugging and Code quality, which is two questions apiece with room to follow up. Ten on Teamwork plus one question from Growth and fit, and the last ten for the candidate's questions about your code and your team. Put the same five or six questions to everyone interviewing for the opening, so that you are comparing answers to the same thing when it is time to decide.
When the candidate's stack is not yours
Judge the reasoning, not the vocabulary
You may not know the database or framework a candidate names, and you do not need to. Ask what it gave them that the alternative would not have, and what it cost. An engineer who understands a tool can say that in plain words. One who only used it because it was there will answer with more tool names.
Say so when you lose the thread
'I do not know that one, what does it do?' is a fair thing for a manager to say, and the reply is evidence. Engineers spend much of their working life explaining things to people outside the code, and one who answers you patiently in the interview is showing how those conversations will go.
Get a grading key from an engineer you trust
Before the interviews, take two or three of the technical questions you plan to use to an engineer on your team and ask what a good answer would contain for your system. Ten minutes gives you a short list to listen for. Afterwards, read your notes back to the same person if an answer left you unsure.
Ask for events, not opinions
A question that begins 'tell me about the last time' works in any stack, because you can follow who did what and in which order without knowing the tools. A question that begins 'what is the best way to' produces views on good practice, which you cannot check and which a well-read candidate can give as smoothly as an experienced one.
What strong and weak answers sound like
Strong answers are checkable
They have a system, a rough date, a number or a named role in them: 'the import job', 'last spring', 'about forty minutes of downtime', 'our database lead'. Weak answers stay at the level of principle. When you get a principle, ask for the most recent case and wait through the silence.
Listen for both 'I' and 'we'
A story told entirely as 'we' hides what the candidate did. A team project told entirely as 'I' hides the team, and sometimes the truth. The engineers you want can separate the two without being pushed: 'the team chose the queue, I wrote the retry logic'.
A strong answer includes what it cost
Most engineering decisions give something up, so a strong candidate describes what the chosen path cost as well as what it bought, usually without being asked. A weak answer presents the choice as obvious. When you hear no cost, ask what going the other way would have gained them.
Three answers that should make you ask again
'It depends', with nothing after it: ask what it depends on and which way they went last time. A tool name given in reply to a why question, as in 'we used a queue': ask what would have gone wrong without it. A story with no ending: ask whether the thing is still running, and who looks after it now.
How they talk about old code and old colleagues
Every candidate has worked in a mess. The ones who describe it with some sympathy, such as 'it made sense for the deadline they had', tend to be easier to work beside than the ones for whom every predecessor was careless. Your codebase will be the mess in their next interview.
Fluent is not the same as deep
Standard questions have standard answers, and a prepared candidate can deliver them smoothly. One more step down usually sorts it: what happened next, what the logs showed, what the other person said. Experience keeps producing detail, while a rehearsed answer runs out.
Mistakes managers make in this interview
Quizzing definitions you cannot grade
A list of terms copied from a search result leaves you checking answers against a key you do not understand, and it rewards memorizing. If a definition matters for your work, let an engineer ask it. Your own questions should be ones whose answers you can weigh yourself.
Borrowing a puzzle because software interviews have puzzles
Brain teasers and algorithm puzzles are what many people picture when they think of a software interview. Set by someone who cannot follow the solution, they measure nerves more than ability. Leave any coding exercise to the engineers on the panel. If your company has none yet, ask an engineer you trust from outside to run that part.
Hiring the keyword match
A resume that lists your exact tools is reassuring, and it is also the easiest thing on the page to acquire. Tools change every few years and working habits change slowly. Ask yourself whether the candidate's answers on debugging, testing and deadlines would still be good answers in another language, because sooner or later your team may be working in one.
Mistaking a quiet candidate for a weak one
Some very good engineers give short answers and do not sell themselves. Before marking one down, hand them something concrete: the design question about a piece of your own product, or the one about something that worked yesterday and is broken today. People who find it hard to talk about themselves often talk easily about a problem.
Wandering into personal territory
Small talk about family, age, health or where someone is from can stray into subjects an employer is not supposed to weigh, and the rules differ by country and state. Ask your HR contact, or whoever runs hiring where you are, which topics to leave alone, and keep the hour on the work.