Software Engineer Interview Questions and What to Listen For

Good software engineer interview questions test how a candidate reasons about real work: a bug they tracked down, a trade-off they made, code someone else must maintain. The 15 questions below are grouped by interview stage, each with what a strong answer shows and the warning sign to listen for.

We build Talent Summoner, which finds and ranks engineering candidates before the interviews start; the questions work whether or not you use it. As of 30 September 2026 your first Role is free with no card, then US$29 per Role or US$59 a month for 4 Roles (pricing).

This page is for founders, HR people and small teams interviewing engineers, often without a senior engineer in every room. If you run a mature loop with coding rounds and calibrated interviewers, keep your rubric and use only the screening and final questions.

15 software engineer interview questions by stage

Use the same questions, in the same order, for every candidate at a stage. You are listening for clear reasoning and specific examples, not a single correct answer.

Screening call questions

#	Question	A strong answer shows	Warning sign
1	Tell me about a recent project. What was your part in it?	A specific account of what they did themselves	Only "we"; they can't say which parts were theirs
2	Which languages and tools have you used most in the last two years, and for what?	An honest list tied to real work, with strengths and gaps	A long list of tools with no example of using any
3	What engineering work do you enjoy most, and least?	Self-awareness and a match with this role's daily work	The work they dislike is most of this role
4	Why are you looking for a new role now?	A calm reason such as growth or a better team fit	Blaming every past team, with no part of their own

Skills interview questions

Bring in an engineer or a trusted advisor for this stage if you can.

#	Question	A strong answer shows	Warning sign
5	Walk me through how a feature you built works, from the user's click to the data being saved.	Each step in order, in plain words, with why it was built that way	Vague, or jargon when you ask for a simpler version
6	Tell me about a bug that was hard to find. How did you track it down?	A method: reproduce, read logs, narrow down, check the fix	It "just went away", or they guessed until it worked
7	When do you write tests, and when do you decide not to?	A view that weighs risk, cost and how often the code changes	"Always" or "never", with no reasons
8	Describe a time you chose between two technical approaches. How did you decide?	Named options, compared trade-offs, what they'd do differently now	The newest tool because it was new

Work sample questions

Keep the task small and the same for every candidate, or talk through code they are free to share. Never ask for code that belongs to a past employer.

#	Question	A strong answer shows	Warning sign
9	Talk me through your solution. What would you change with more time?	They know the weak spots and rank what to fix first	"It's perfect", or they can't explain parts of their own code
10	How would this need to change if many more people used it?	Where it would slow down or break, and sensible next steps	They ignore the question or redesign everything
11	If a teammate took over this code tomorrow, what would they need to know?	Naming, notes, tests and the parts that are easy to get wrong	"It's self-explanatory"

Final interview questions

#	Question	A strong answer shows	Warning sign
12	Tell me about critical feedback you got on your code. What did you do?	They listened, asked questions, then changed something or explained calmly	Defensive, or never had feedback they disagreed with
13	Describe a time a deadline was at risk. When did you tell people?	They raised it early and offered options	Silent until the deadline passed
14	How do you explain a technical problem to someone who isn't an engineer?	A real example in plain words, focused on the decision needed	Non-engineers are a problem to work around
15	What did you teach yourself recently, and how?	Curiosity and a practical way of learning	Nothing new in a long time

What a software engineer has to prove

Tie each question to one proof point, so every score means something:

They can build working software in your stack, or learn it quickly.
They break problems into steps and explain the trade-offs.
They write code others can read and change, with tests where it matters.
They find and fix problems in running systems, not only in new code.
They work well with others and explain technical ideas in plain words.

For where to find engineers, see how to hire software engineers; for Hong Kong pay and channels, see hiring a software engineer in Hong Kong.

How to score software engineer interview answers

Score each answer right after the interview, before you talk to the other interviewers:

Score	What it means
1	No real answer, or a clear warning sign
2	Some relevant points, but vague or missing key parts
3	A clear, specific answer that meets what the role needs
4	Clear and specific, with good reasons and self-awareness

Write the candidate's example next to each score. Then compare candidates question by question, not by overall feeling.

Copy this scale into the candidate interview scorecard template, and keep notes in the interview notes template.

Software engineer interview mistakes to avoid

Personal questions. Age, family plans, religion, health and origin are not about the job, and many places restrict asking about them.
Brain-teasers. They test puzzle skill, not how someone builds software.
Large unpaid take-homes. Keep work samples small, or pay for the time.
Improvised questions. Without a shared list you cannot compare answers.
Confidence over evidence. A calm speaker is not always the stronger engineer.

When this question set is wrong for you

The 15 questions on this page suit a generalist product or backend engineer at a small company. Replace them in three cases:

Senior or staff hires. Add a system design round run by a senior engineer.
Specialist roles such as machine learning, security or embedded work. Add a domain-specific technical round.
A large engineering team with a calibrated loop. Keep your own rubric; use this page only for the non-technical stages.

Where Talent Summoner fits before the engineering interviews

Talent Summoner is our product for candidate sourcing and candidate ranking. The facts below were checked on 30 September 2026.

Candidate sourcing takes a role brief and returns a ranked shortlist with plain-English reasoning. It searches LinkedIn, GitHub and other public sources, over 200 million profiles.

Candidate ranking scores up to 50 CVs you already have, free and with no account.

What it does not do: run or score your interviews, send paid LinkedIn InMail, or sync with an ATS today. The interview decisions stay with your team.

We re-check the product facts on this page every quarter.

Can someone without a technical background interview a software engineer?

Yes, for the screening call and final interview. For the skills interview and work sample, bring in an engineer or trusted advisor to join or review the work.

How many interview stages does a software engineer hiring process need?

Three or four is usually enough for a small team: screening, skills, a work sample and a final conversation. Add a stage only if it tests something the others do not.

Should we use a take-home coding test?

A small, clearly scoped task can show real skill if every candidate gets the same one and knows how it will be judged. If the task is large, pay for the time.

What is the biggest red flag in a software engineer interview?

A candidate who cannot explain parts of their own code or work sample. It usually means they did not write it or do not understand it.

Use the 3 or 4 questions listed for each stage, share the scoring scale with every interviewer, and decide who makes the final call before the first interview.