Software engineer interview guide
What a software engineering loop looks like, what coding interviewers listen for, how to structure an answer, and ten questions to practise.
A software engineering loop is usually four to six conversations: a recruiter screen, one or two coding rounds, a system design round for mid-level and above, a behavioral round, and sometimes a domain deep-dive on something you built. The coding rounds carry the most weight and are where most rejections happen, so this guide spends most of its time there.
The thing to internalise early: a coding interview is not a test of whether you can produce a working program in 40 minutes. It is a test of whether the interviewer would want to pair with you. Silence, guessing, and heroic debugging read badly even when the final code is right.
What the coding round looks like
Forty-five minutes, one or two problems, a shared editor or a whiteboard. Expect a medium-difficulty problem drawn from a small set of patterns: arrays and hashing, two pointers and sliding windows, trees and graphs (BFS and DFS), heaps for top-k, intervals, and dynamic programming. Interviewers rarely pick exotic problems; they pick problems that have a brute force, an obvious improvement, and a follow-up.
The follow-up is where levels get decided. “What if the input doesn’t fit in memory?” “What if this has to be thread-safe?” “Can you do it in one pass?” A mid-level engineer answers the follow-up; a senior engineer anticipates it.
What interviewers listen for
- Clarifying questions before you write anything: input size, value ranges, duplicates, empty input, what to return on failure.
- The brute force and its complexity, stated out loud, even if you skip straight to the better approach.
- The name of the pattern. “This is a sliding window” tells the interviewer you have a map of the territory.
- Narration while coding. Say what each block does before you type it; go quiet only for mechanical parts.
- A trace through a small example after the code is written, not before.
- Edge cases you thought of yourself: empty input, one element, all duplicates, negative numbers, overflow.
- Time and space complexity at the end, unprompted.
How to structure an answer
Restate the problem in one sentence. Ask two or three clarifying questions. Give the brute force with its complexity. Say the better approach and why it works, name the pattern, and check the interviewer agrees before you write code. Write the code in a function with a clear signature, commenting each logical chunk rather than each line. Trace one example. State the complexity. Then list two edge cases you would add tests for.
If you get stuck, say what you are stuck on. “I know I need to get from O(n²) to O(n log n), which usually means sorting or a heap — let me think about which.” That sentence gets hints; silence gets a low score.
Questions to practise
- Given an array of integers and a target, return the indices of two numbers that sum to it. Then: what if the array is sorted?
- Merge a list of overlapping intervals. Then: insert a new interval into an already-merged list.
- Implement an LRU cache with O(1) get and put.
- Return the k most frequent elements in an array. Then: do it in O(n) with bucket sort.
- Check whether a binary tree is a valid binary search tree.
- Given course prerequisites, return a valid order to take them, or detect a cycle.
- Find the length of the longest substring without repeating characters.
- Serialize and deserialize a binary tree.
- Design a rate limiter class: allow N requests per user per minute.
- Given a grid of 0s and 1s, count the islands. Then: what changes if the grid is streamed row by row?