These software engineer interview questions are language-agnostic. They test how a candidate thinks about problems, writes code others can trust, finds bugs and works within a team, whatever the stack. They suit a first technical round for generalist roles, and candidates can use them to practice explaining their reasoning out loud. Each question includes what a good answer covers and, where it helps, a red flag. Choose 6 to 8, let the candidate pick their language, and pair this set with a stack-specific page if the role needs one.
What a strong software engineer interview checks
- Problem solving: breaking a problem down, starting simple and improving with reasons.
- Data structures and complexity: picking the right tool and knowing what it costs.
- Code quality: readable code, sensible error handling and useful tests.
- Debugging: a calm, evidence-driven way to find the cause.
- Shipping: estimating, reviewing and releasing changes safely.
- Teamwork: clear communication in reviews, tickets and disagreements.
Software engineer interview questions: problem solving
1. Given a list of transaction amounts and a refund total, how would you check whether any two transactions add up to it?
What good looks like: start with the brute force (check every pair, O(n squared)), then improve. Sorting plus two pointers gives O(n log n). A single pass with a hash set, checking whether total minus amount has been seen, gives O(n) time and O(n) memory. Strong candidates ask about duplicates, negative numbers and whether one transaction can be used twice.
Red flag: writing code before confirming the inputs and edge cases.
2. You have a list of meeting times, some overlapping. Merge them into the fewest blocks.
What good looks like: sort by start time, then walk the list, extending the current block when the next meeting starts before it ends and starting a new block otherwise. That's O(n log n) because of the sort. Good answers clarify whether touching meetings (one ends at 10, the next starts at 10) should merge.
3. Your build tool must install packages in an order that respects their dependencies. How?
What good looks like: model packages as a directed graph and run a topological sort, either Kahn's algorithm (repeatedly take nodes with no remaining dependencies) or depth-first search. If nodes remain that never reach zero dependencies, there's a cycle, and the tool should report it rather than loop forever.
4. When would you reach for a stack, a queue, a heap or a hash map?
What good looks like: a stack for last-in-first-out work like undo history or matching brackets. A queue for first-in-first-out work like breadth-first search or task processing. A heap when you repeatedly need the smallest or largest item, such as the top 10 scores or the next scheduled job. A hash map for fast lookup by key. Strong candidates attach a real example to each.
5. What does binary search need, and where does it go wrong?
What good looks like: sorted data (or any monotonic condition), with O(log n) lookups. Common bugs are off-by-one errors in the bounds and loops that never end because the middle index doesn't move. A strong answer mentions using it on answers, not just arrays, like finding the smallest batch size that fits in memory.
6. A recursive function is correct but painfully slow on bigger inputs. Why might that be?
What good looks like: it may recompute the same subproblems many times, as naive Fibonacci does, making it exponential. Caching results (memoization) or building the answer bottom-up makes it linear in that example. Deep recursion can also hit the stack limit, so an iterative version may be safer.
Code quality and testing
7. What makes a good unit test?
What good looks like: it is fast, deterministic, tests one behavior, and has a name that says what broke when it fails. It follows an arrange, act, assert shape and tests behavior through the public interface rather than private details. Strong candidates explain the balance between many unit tests, fewer integration tests and a handful of end-to-end tests.
8. A test passes locally and fails in CI about one time in ten. What do you do?
What good looks like: treat it as a real bug. Common causes are dependence on the current time or time zone, test order, shared state between tests, real network calls, unseeded randomness and race conditions. Reproduce it by running the test many times or in random order, then fix the cause.
Red flag: "Add an automatic retry and move on."
9. How do you decide whether to refactor code or rewrite it?
What good looks like: refactoring in small, tested steps is almost always safer, because the old code holds fixes for edge cases nobody wrote down. A rewrite can make sense when the design blocks the main goal and the scope is small enough to finish. Strong candidates mention running old and new side by side and comparing results.
10. Walk me through how you review a teammate's pull request.
What good looks like: understand the goal first, then check correctness, edge cases, tests, readability, security and performance, roughly in that order. Separate blocking issues from suggestions, ask questions instead of issuing orders, and approve quickly when it's good. Large PRs get a request to split them.
11. Merge or rebase: when do you use each?
What good looks like: rebasing your own feature branch onto main keeps history linear and easy to read. Don't rebase a branch others have based work on, because it rewrites shared history. If you must force-push your own branch, use --force-with-lease so you don't overwrite someone else's commits. Merging preserves the exact history at the cost of extra merge commits.
12. Where should input validation and error handling happen?
What good looks like: validate at the edges where outside data enters (requests, files, user input), so the core logic can trust its inputs. Fail fast with clear messages, don't swallow errors, and log enough context to debug without logging secrets or personal data.
Debugging and shipping
13. A user reports "the app is slow sometimes." Where do you start?
What good looks like: turn the vague report into data. Which action, which users, what time, how slow. Check metrics and logs for that window, look for patterns like one endpoint or large accounts, and form a hypothesis to test. If the slowdown started with a change, git bisect can find the commit.
14. You get a ticket with vague requirements. What do you do before coding?
What good looks like: ask the author for the goal behind the request, write two or three concrete examples of expected behavior, and agree on acceptance criteria. Then propose the smallest slice that delivers value and can be checked early.
15. How do you estimate a feature you've never built before?
What good looks like: break it into parts, estimate each, and call out the unknowns. Give a range instead of a single number, and suggest a short spike to shrink the biggest unknown. Strong candidates revisit the estimate as they learn and say so early if it changes.
16. How do you ship a risky change to a large user base safely?
What good looks like: put it behind a feature flag, roll out to internal users and then a small percentage, watch error rates and key metrics, and expand in steps. Have a tested way to roll back that doesn't need a new deploy. Database changes need to be backward compatible with the previous version of the code.
17. What security basics should every engineer follow?
What good looks like: never build queries or commands by concatenating user input (use parameterized queries), keep secrets out of the repository, give services the least access they need, keep dependencies updated and scanned, and escape output shown to users. Strong candidates know where to look things up, such as the OWASP Top 10.
Behavioral (STAR)
18. Tell me about a task that turned out much bigger than your estimate.
What good looks like: when they noticed, how quickly they told people, what they cut or changed to deliver, and what they now do differently when estimating.
Red flag: they kept quiet until the deadline passed.
19. What piece of work are you proudest of, and what would you improve about it now?
What good looks like: a clear explanation of the problem and their own role, a result they can measure, and honest criticism of their own solution. The second half of the question shows how they've grown.
A simple scoring rubric
Running this interview with AI
A generalist first round is a good job for an AI interviewer, because the goal is a consistent, fair read on many candidates before your engineers spend time. NTRVSTA's exam library covers programming languages including Java, Python, C++ and JavaScript, so candidates can work in the stack they know. The interviewer adapts in real time, moving a strong candidate to harder problems and giving a struggling one simpler questions or a hint.
The report shows a score breakdown across technical skills, English proficiency and communication, with video snippets of key moments. Before setting a pass bar, read how AI interviews are scored, and compare tools in the best AI interview software or technical interview platforms. For stack-specific rounds, see Python, system design and QA engineer questions.
Questions
Should a software engineer interview be in a specific language?
Let candidates pick the language they know best for problem-solving questions, unless the role needs deep expertise in one stack from day one. You learn more about reasoning when the candidate isn't fighting unfamiliar syntax.
Are algorithm questions still worth asking in 2026?
A few, if they resemble real work, like merging time ranges or ordering dependencies. Puzzle-style questions that need a memorized trick tell you little. Balance them with debugging, testing and code review questions, which predict day-to-day performance better.
How should candidates use AI coding assistants in interviews?
Decide the rule in advance and tell every candidate. Many teams now allow assistants in take-home or pairing exercises and ask candidates to explain and verify the generated code. For reasoning questions like the ones here, a conversation without tools works best.
Ready to give every engineering applicant a consistent first round? Book a 20-minute demo, or run a sample interview yourself to hear how it adapts.
