Most software engineering interviews mix three things: whether you can code, whether you can reason about a system, and whether anyone wants to work with you. The questions below cover all three. For each one there is the reason it gets asked, which is usually not the obvious one, and a way to structure an answer.
Last reviewed September 2026
Software engineer interviews usually cover three areas: a coding exercise, a system design discussion, and behavioural questions about how you work. Expect to be asked to introduce yourself, walk through a project, solve a problem out loud, and describe a disagreement. Interviewers are listening for how you reason, not whether you recall the right answer.
It sounds like small talk and it is not. The interviewer is deciding, in the first minute, which version of the rest of the interview to run.
Ninety seconds, three beats: what you do now, one thing you built that is relevant to this job, and why this role. Do not walk through your CV in order. They have it.
I am a backend engineer, four years, mostly Python and Postgres. Most recently I rebuilt our payments integration so it could survive the provider going down, which cut failed checkouts by about a third. I am here because this role is the same problem at a much bigger scale.
They want to hear what you personally did. Plenty of candidates describe a team achievement and never say which part was theirs.
Say the problem, your specific decisions, and the measurable outcome. Use "I" for your work and "we" for the team, and be careful which you use where.
Our search took eight seconds on large accounts. I found the query fanning out per row, rewrote it as a single aggregate with an index on the join column, and added a cache for the top queries. It went to under 400 milliseconds and support tickets about search stopped.
A system design warm-up. They are watching whether you ask about scale before you start drawing.
Ask the constraints first: how many writes, how many reads, how long links live. Then take it in order: API, storage, key generation, caching, and only then scale.
First, how many links a day and what read to write ratio? Assuming heavy reads, I would store the mapping in a key value store, generate keys with a counter encoded in base62 rather than hashing, since that avoids collisions entirely, and cache the hot keys.
A fundamentals check. Fast, correct answers here buy you credit for the harder questions.
Give the one-line difference, then the practical consequence. The consequence is what separates a memorised answer from an understood one.
A process has its own memory space, threads share one. So threads are cheaper to create and can share data directly, which is also why they need locks and why a crash in one thread can take the whole process with it.
Not about the disagreement. They are checking whether you can be wrong gracefully and whether you escalate or stew.
Pick a real technical disagreement with a resolution. Say what they argued, what you argued, how it was settled, and what you would do differently.
A colleague wanted to add a queue for a job that ran twice a day. I thought it was premature. We disagreed for a week until I suggested we just measure it. It ran in two seconds, so we left it, but he was right that the pattern would not hold, and we added the queue six months later when volume grew.
Answers here vary wildly, and it is the fastest way to tell a careful engineer from a fast one.
Talk about what you test rather than which framework you use. Mention the tradeoff you make about how much to test.
I test behaviour rather than implementation, so refactors do not break the suite. Heaviest coverage on anything that touches money or permissions. I try to write the failing test first for bugs, because it proves the fix actually fixes it.
A breadth check. They want to see how far your mental model reaches, not a recital.
Move through the layers and say where you are less certain. Pretending to know everything here reads worse than an honest boundary.
DNS resolves the host, a TCP connection opens, TLS negotiates, the browser sends the request, the server responds with HTML, and the browser parses it and fetches sub-resources. The part I know least well is the exact TLS handshake order, though I know it establishes a shared key.
They are listening for how you talk about people who are not in the room.
Point forwards, not backwards. Criticising your current employer costs you more than any honest grievance gains you.
I have learned a lot there, but the product is stable now and most of my work is maintenance. I want to be building again, and this role is closer to that.
Senior signal. Junior answers jump to the fix, senior answers stabilise first.
Stop the bleeding, then diagnose, then prevent. Mention communication, because that is what people forget.
First reduce impact, roll back or feature flag off, before understanding it fully. Then say clearly in the channel what is happening, so nobody duplicates work. Diagnose from logs and the recent deploy list. Afterwards, a writeup about the cause, not the person.
Always asked, rarely prepared for. Having none reads as not caring.
Ask two things you actually want to know. Questions about how the team works land better than questions about perks.
What does the path from a merged pull request to production look like? And what is the thing about this codebase that new joiners find hardest?
Most engineering interviews include a live coding round. These five come up constantly. What is being judged is whether you talk while you think, ask about edge cases, and state the complexity without being asked.
def reverse_words(sentence):
return ' '.join(sentence.split()[::-1])split() with no argument collapses runs of whitespace, which handles double spaces and leading spaces without a special case. Reverse the list, join with single spaces.
O(n) time, O(n) space.
Say out loud that split() handles the whitespace edge cases. Interviewers often follow up with "what about two spaces", and answering before they ask it reads well.
def two_sum(nums, target):
seen = {}
for i, n in enumerate(nums):
if target - n in seen:
return [seen[target - n], i]
seen[n] = i
return []One pass with a dictionary of value to index. For each number, check whether its complement has already been seen. The nested loop version is the obvious answer and the one they are hoping you improve on.
O(n) time, O(n) space. The brute force is O(n squared) time, O(1) space.
Store after checking, not before, or a single element can match itself when the target is double that value.
from collections import Counter
def first_unique(s):
counts = Counter(s)
for ch in s:
if counts[ch] == 1:
return ch
return NoneCount every character first, then walk the string in order and return the first with a count of one. Two passes, but both linear.
O(n) time, O(k) space where k is the alphabet size.
The second loop must walk the string, not the counter. Dictionary order is not the answer they want you to rely on.
def merge(a, b):
out, i, j = [], 0, 0
while i < len(a) and j < len(b):
if a[i] <= b[j]:
out.append(a[i]); i += 1
else:
out.append(b[j]); j += 1
out.extend(a[i:])
out.extend(b[j:])
return outTwo pointers, always taking the smaller head. When one list runs out, the rest of the other is already sorted, so extend rather than continuing to compare.
O(n + m) time, O(n + m) space.
Use less than or equal rather than less than, so equal values keep their original order. That is what makes the merge stable, and it matters if this is part of a merge sort.
def is_balanced(s):
pairs = {')': '(', ']': '[', '}': '{'}
stack = []
for ch in s:
if ch in '([{':
stack.append(ch)
elif ch in pairs:
if not stack or stack.pop() != pairs[ch]:
return False
return not stackA stack. Push every opening bracket, and on a closing bracket check the top matches. The classic bug is forgetting the final check that the stack is empty.
O(n) time, O(n) space.
Returning True at the end without checking the stack passes "([" incorrectly. Interviewers test that exact input.
InvisiHire listens to your call and drafts what you could say next, using your own resume. Free to start, no card needed. Check your employer's or your institution's rules on assistance before you use it.
Start free See how it works