New Grad Software Engineer Interview Prep: Questions and a Mock Test

Every coding round ends with a complexity question, and a correct solution whose cost you cannot state is a partial answer.

The part candidates underprepare is that language built-ins have costs too, and choosing the wrong one turns a linear solution into a quadratic one silently. Python's own documented average-case complexities make the point precisely: appending to a list is O(1), inserting at a position is O(n), indexing a list is O(1), and the membership test x in list is O(n). By contrast, set membership is O(1) and dictionary get and set are O(1). Sorting a list is O(n log n).

That table explains a very common interview failure. A loop that checks whether an item has been seen using a list is O(n) per check and O(n squared) overall; changing the list to a set makes it linear, and the code looks almost identical. Interviewers set problems where exactly this substitution is the point.

Be precise about what n means, and about space as well as time. A recursive solution has stack depth, a memoisation table has size, and an answer that says linear time without mentioning the linear space it also uses is incomplete.

Worst case and average case differ for hash-based structures, and saying so unprompted is a good signal: dictionary and set operations are constant on average and degrade with adversarial or pathological hashing.

Interview algorithm questions are drawn from a surprisingly small set of patterns, and recognising which one applies is most of the work.

Hash map for counting or lookup, which converts repeated searching into constant-time access and is the single highest-yield pattern. Two pointers on a sorted array, for pair sums and in-place partitioning. Sliding window for contiguous subarray or substring problems with a constraint. Binary search, both on a sorted array and, more interestingly, on the answer itself when a predicate is monotonic. Breadth-first search for shortest path on an unweighted graph and depth-first search for exploration and cycle detection, with the reminder that a grid is a graph. A heap for top-k and for streaming problems. And dynamic programming when the problem has overlapping subproblems and optimal substructure, where the practical route is usually to write the recursion first and then add memoisation.

The recognition cues are worth rehearsing. The word sorted suggests two pointers or binary search. Contiguous suggests a sliding window. Shortest path on equal-weight edges means breadth-first search. Count the ways or maximise over choices suggests dynamic programming. Top k suggests a heap.

The habit that earns marks regardless of pattern: state a brute-force solution and its complexity first, then improve it. That guarantees you have something correct on the board, it demonstrates you understood the problem, and it makes the optimisation legible as a decision rather than as a memorised trick.

Interviewers assess four things, and only one of them is the final answer.

Problem understanding comes first. Restating the problem, asking about input size, duplicates, empty input, negative numbers, and whether the input may be modified, takes ninety seconds and prevents the most expensive failure mode, which is solving the wrong problem elegantly.

Communication is second and is where silence is fatal. An interviewer cannot award credit for reasoning they cannot hear. Saying what you are considering and why you are rejecting it is the observable behaviour being graded, and a candidate who works silently for ten minutes and produces a correct answer usually scores worse than one who thinks aloud and needs a nudge.

Code quality is third. Meaningful names, small functions, no duplicated blocks, and handling the edge cases you identified at the start. Writing the edge cases down when you name them, then checking them off, is a cheap way to demonstrate rigour.

Verification is fourth and most often skipped. Walking through your own code with a small example, out loud, catches off-by-one errors before the interviewer finds them, and finding your own bug reads far better than having one pointed out.

On hints: they are deliberate. Taking one gracefully and incorporating it is assessed positively; resisting one is assessed badly. Nobody is expected to solve everything unaided.

Most loops include a round that is not algorithmic, and new graduates are frequently underprepared for it because coursework does not cover it.

HTTP semantics are examinable and precise. RFC 9110 defines a method as safe if "their defined semantics are essentially read-only; that is, the client does not request, and does not expect, any state change on the origin server", covering GET, HEAD, OPTIONS and TRACE. A method is idempotent if "the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request", which is the safe set plus PUT and DELETE. The consequence worth knowing: POST is neither, so a retried create can duplicate, and DELETE is idempotent even though the second call usually returns 404, because the property concerns server state rather than the status code.

Status codes: 401 means unauthenticated, 403 means authenticated but not permitted, 404 not found, 409 conflict with current state, 500 a server-side failure.

Databases come up at a basic level. What an index is and why it makes reads faster and writes slower, what a primary key and a foreign key are, the difference between inner and left joins, and what a transaction guarantees. If you can also say that the default isolation level in most systems permits a row to change between two reads in the same transaction, you are ahead of most new graduates.

Version control too: what a merge conflict is, the difference between merge and rebase, and why force-pushing to a shared branch is a problem.

The behavioural round is not a formality, and the most common defect is answering in the first person plural.

"We built a recommendation feature" tells an interviewer nothing about you. "I owned the data pipeline, and I argued for a simpler baseline first because we had six weeks" does. The interviewer is assessing you specifically, and a collective subject makes your contribution invisible.

Amazon publishes the clearest example of a written rubric, and several of its Leadership Principles describe behaviours any interviewer is listening for. Customer Obsession states that "leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust." Are Right, A Lot asks that leaders "seek diverse perspectives and work to disconfirm their beliefs". Bias for Action puts the reversibility argument in one line: "Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking."

With limited professional experience, coursework, personal projects, internships, part-time work and team activities are all legitimate material. What matters is the structure: situation, what you specifically did, and a result you can quantify even roughly.

Prepare a genuine failure story. The most common mistake is a disguised strength, working too hard or caring too much, which reads as evasion. A real failure with a real cost and a specific change in how you now work is what the question is for. Prepare a disagreement story too, since almost every loop asks for one.