Software Engineer
Interview Questions

What the interviewer is looking for: A strong answer weighs constant-time average lookups against ordered traversal and worst-case guarantees. Red flags are naming structures without connecting them to access patterns, ordering needs, or memory trade-offs.

What the interviewer is looking for: Look for contiguous memory and O(1) indexing versus cheap insertions/deletions and no random access. A weak answer recites definitions without a concrete situation where one clearly wins.

What the interviewer is looking for: The candidate should reach the fast/slow pointer approach (O(n) time, O(1) space) and explain why it works. Red flags include only proposing a hash-set solution and being unable to reason about the pointer meeting.

What the interviewer is looking for: A good answer mentions writing a recurrence relation and reasoning about branching factor and depth, with an example like merge sort. Weak answers guess Big-O from the number of loops without accounting for recursion.

What the interviewer is looking for: Strong answers combine rotating the exposed key immediately with rewriting history (filter-repo/BFG) and force-pushing, noting that the key must be treated as compromised. A red flag is only deleting the file in a new commit, leaving it in history.

What the interviewer is looking for: Look for understanding that merge preserves history with a merge commit while rebase produces a linear history by replaying commits, plus the caution against rebasing shared branches. Confusing the two or claiming one is always better is a red flag.

What the interviewer is looking for: The candidate should explain that a shallow copy shares nested references while a deep copy recurses, and give a mutable-nested-object example. Not knowing the copy module or the mutability implication is a red flag.

What the interviewer is looking for: A strong answer covers catching specific exceptions, using finally for cleanup, and re-raising or logging rather than silently passing. Bare except blocks with no handling should be flagged as a smell.

What the interviewer is looking for: Look for multiple-inheritance-of-type via interfaces versus shared state/implementation in abstract classes, and the design intent behind each. A red flag is only reciting syntax without a design rationale.

What the interviewer is looking for: Strong candidates cover the encoding scheme, the key-value store, read-heavy scaling with caching, and collision handling, while clarifying scale assumptions first. Jumping straight to code or ignoring read/write ratios is a red flag.

What the interviewer is looking for: Look for adding machines versus adding resources to one machine, plus statelessness, load balancing, and cost/limits. A weak answer defines the terms but cannot discuss when each is appropriate.

What the interviewer is looking for: The candidate should handle ties and empty results, using DISTINCT with a subquery or a window function. Red flags include assuming exactly one second value or an approach that breaks with duplicates.

What the interviewer is looking for: A good answer explains that indexes speed reads via an auxiliary structure that must be updated on every write, so they trade write cost and storage for read speed. Not knowing the write penalty is a red flag.

What the interviewer is looking for: Strong answers distinguish PUT (idempotent full replace) from PATCH (partial update), use correct status codes, and consider validation. Treating all writes as POST or ignoring idempotency is a red flag.

What the interviewer is looking for: Look for the idea that repeating the same request produces the same result, which makes safe retries possible after timeouts. A candidate who cannot connect idempotency to network failures shows a shallow understanding.

What the interviewer is looking for: A strong answer shows a systematic approach — reproducing, isolating variables, forming and testing hypotheses — rather than random changes. Red flags are vague stories with no method or crediting luck.

What the interviewer is looking for: Look for evidence-based disagreement, seeking to understand their reasoning, and disagreeing-and-committing once a decision is made. Either steamrolling or staying silent to avoid conflict are both red flags.

What the interviewer is looking for: Strong answers value tests that catch regressions, document behaviour, and are deterministic and focused, while warning against brittle tests coupled to implementation. Chasing coverage percentage as the goal is a red flag.

What the interviewer is looking for: Look for catching defects and sharing knowledge while keeping feedback specific, kind, and focused on the code not the person. A candidate who treats reviews as gatekeeping or nitpicking style over substance is a red flag.

What the interviewer is looking for: Strong answers clearly separate personal contribution from team work, explain technical decisions, and reflect on what they learned. Vague 'we' statements with no ownership or inability to justify choices are red flags.

What the interviewer is looking for: Look for concrete, recent habits — side projects, reading, open source, courses — and genuine curiosity. Generic claims of 'always learning' with no specifics suggest limited real engagement.