Top 10 Software Engineer Interview Questions I’d Practice in October 2026

The interview question I worry about is the one I recognize immediately.

I know the pattern, I can picture the solution, and I start writing before checking what changed. Then a duplicate arrives, a cache entry expires, or the interviewer adds one more requirement, and the answer I felt confident about starts falling apart.

That is the kind of preparation I want this month: a smaller list that makes me explain the uncomfortable parts.

If I were organizing my October practice, these are the ten questions I would put on the calendar. Each gives you something concrete to implement or design, a small case that exposes a weak assumption, and a follow-up worth attempting after the first version works.

This list covers MAANG plus OpenAI.

Before you start, change what counts as finished

I would keep 4 things for every attempt:
i) the contract,
ii) the implementation or design,
iii) the case that challenged it, and
iv) the reason the final approach works.

For a coding exercise, try a first pass without generated code, using documentation when an API detail gets in the way. If you use an assistant afterward, ask it for a counterexample to your reasoning before asking for a replacement solution.

For a design exercise, write down one failure sequence all the way through. A diagram that survives a server crash is more useful to me than a diagram with six additional boxes.

1. Meta practice: Can you count target-sum subarrays when numbers go negative?

The question: Given an integer array and a target, count all non-empty contiguous subarrays whose sum equals the target. Values may be positive, negative, or zero. Aim for linear time.

Related problem: UNSW’s subarray-sum problem and walkthrough (PDF, page 37).

Start with [1, -1, 1] and target 1. The answer is 3: either individual 1, or the entire array.

Sliding window is tempting, but shrinking a window does not reliably decrease its sum when negative values are present.

How I’d work through it: Keep a running prefix sum and a frequency map of earlier prefix sums. If the current sum is s, each earlier occurrence of s - target starts a valid subarray ending here. Initialise the map with one occurrence of zero, count matches, then record the current sum.

The ordering matters: recording first can count an empty subarray when the target is zero. Expected time is O(n) with a hash map; space is O(n).

Follow-up: For [0, 0, 0] and target 0, explain why the answer is 6. Then return the actual ranges and account for the potentially quadratic output.

2. Apple practice: Can you build a cache that expires the right version?

Question: Implement put(key, value, ttl, now) and get(key, now) for an in-memory cache. An entry is valid only while now < expires_at. Writes replace the old value and expiry; assume calls arrive in nondecreasing time order and TTL is positive.

Technical reference: Redis’s expiry and refresh semantics.

Try this sequence: write A = old at time 0 with TTL 5, then write A = new at time 3 with TTL 10. Reading at time 5 must return new.

Trap: An old cleanup event must not delete a newer version of the same key.

Begin with a dictionary and lazy expiry on reads: expected O(1) per operation, although unread expired entries remain in memory. If you add a heap for cleanup, attach a version to each expiry record and confirm it still matches the stored entry before deleting it. Heap maintenance adds logarithmic work and stale records need eventual removal.

Follow-up: Add a capacity limit. Explain how expired entries and least-recently-used eviction interact, then identify which steps must be atomic if calls become concurrent.

3. Google: Can you keep counting islands as the map changes?

The question: Count four-directionally connected islands in an initial grid, then report the count after every land addition. Adding land to an existing land cell changes nothing.

I would use the Google-tagged island-counting exercise for this session.

For [[1, 0, 1]], add the middle cell twice. The counts are [2, 1, 1], including the initial state.

Here’s the approach: Use union-find with path compression and union by size. A new cell creates one component; each successful union with a distinct neighboring component removes one. Comparing roots prevents counting the same merge twice.

With N grid cells and K additions, this takes O((N + K) α(N)) time, O(N) working space, and O(K) output space.

Follow-up I’d add: Allow land removal. Explain why ordinary union-find cannot split a component, and what you would reconsider before choosing an algorithm.

4. Netflix practice: Can you enforce a rolling limit at the exact boundary?

The question: Build a single-process limiter that accepts at most three events per user in the rolling interval (t - 60, t]. Timestamps are integer seconds, arrive in nondecreasing order, and rejected events do not consume capacity.

Implementation reference: Redis’s sliding-window rate-limiter tutorial.

Accept events at 0, 20, and 40. A request at 59 is rejected. At 60, the event at 0 has left the window, so another request can be accepted.

How I’d start: Keep a deque of accepted timestamps per user. Before a decision, remove timestamps at or before t - 60. Accept and append only if fewer than three remain. Each accepted timestamp enters and leaves once, giving amortised constant work per request.

The important conversation begins when two requests arrive together. Checking the count and appending the accepted event must be one atomic operation for that user.

Follow-up: Move the limiter across several servers. Choose where the authoritative decision happens and explain the consequence of losing access to that state. A counter independently maintained on every server does not enforce one global limit.

5. Amazon: Can you find the common manager of an entire group?

Question: Given an organisation tree and a non-empty list of employees, return the lowest person whose team contains them all. A team includes its manager, and repeated employee names count once.

The Amazon-tagged common-manager problem makes a useful change from memorising the two-node version.

Imagine Ava manages Ben and Cara, while Ben manages Dan and Eli. [Dan, Eli] returns Ben; [Ben, Dan, Dan] also returns Ben.

Approach: Deduplicate the requested names. In postorder, count requested people in each subtree, including its root. Return the deepest node containing every distinct target. Use an explicit traversal stack for a very deep tree.

For N people and K supplied names, one query takes O(N + K) time and O(N) auxiliary space.

Follow-up I’d add: What changes if the organisation stays fixed but you receive thousands of queries? Separate preprocessing cost from query cost.

The next five are where I’d slow down

At this point, I would stop measuring progress by the number of questions completed. The next set asks you to keep several promises at once: ordering, successful completion, valid dependencies, or correct recovery.

This is where I want my notes to become more specific. A sentence such as use a cache is not enough; I want to know what becomes stale and who notices.

6. Meta practice: Can you paginate a feed without repeating posts?

Question: A chronological feed sorts immutable posts by creation time, newest first. Return pages of three posts while new posts may be inserted. Posts have unique IDs, but timestamps can tie. For the first version, fix the eligible dataset at the start of the pagination session.

Technical reference: GraphQL’s cursor-pagination guide.

Suppose the first page is [F, E, D]. If two new posts appear ahead of it, using offset 3 against the live dataset can return posts the reader already saw.

The approach: Define a total order using (created_at, id). Use the last returned pair as the cursor and request rows strictly below it in descending order. Explain how your snapshot is maintained; a cursor alone does not freeze the dataset.

With an appropriate index, a page can typically be fetched in O(log N + P) work for P returned rows. Avoid promising that complexity without stating the storage assumptions.

The follow-up: Remove the snapshot and allow late inserts, deletion, or mutable rankings. State which guarantees survive. Stable chronological pagination and a continuously reranked feed need different contracts.

7. Apple practice: Can you return the first successful API response?

The question: Launch three independent, safe-to-repeat read requests. Return the first success completed before a shared 500 ms deadline. A failure from one request should not end the operation while others can still succeed.

Implementation reference: MDN’s first-success Promise.any examples.

Use this timeline: request A fails at 40 ms, B succeeds at 120 ms, and C would succeed at 300 ms. The result must come from B.

The mistake I’d look for: Racing completion is different from racing success. A primitive that settles on the first completion may surface A’s error too early.

Track pending requests, errors, and one shared deadline. Finish on the first eligible success, on exhaustion of all requests, or on timeout. Clean up timers and cancel remaining work where supported; handle late completions even when cancellation is only advisory.

The follow-up: At exactly 500 ms, does success or timeout win? Define the rule and use an injectable clock in your checks. Then discuss the extra backend load: parallel duplication is a deliberate latency trade-off, not a free optimisation.

8. OpenAI: Can you build a spreadsheet that rejects a cycle cleanly?

The question: Implement cell writes and computed reads with references between cells. For this practice version, support integers and addition formulas, and reject cycle-creating writes while preserving the old sheet.

The OpenAI-tagged spreadsheet exercise is my third pick.

Set A1 = 2, B1 = A1 + 3, and C1 = B1 + A1. C1 is 7; changing A1 to 4 makes it 11. Writing A1 = C1 must be rejected.

The approach: Store formulas and dependencies separately. Validate proposed edges before committing a write. Start with memoised evaluation per read; a reachable graph costs O(V + E) to traverse. Persistent caching additionally needs invalidation of downstream dependents.

The check I’d insist on: After rejecting the cyclic write, read all three cells again. Then replace a formula with a constant and confirm its obsolete dependency has disappeared.

9. Netflix practice: Can you debug a latency regression without changing five things?

The question: A deployment doubles an endpoint’s p99 latency while its median stays stable. Errors and traffic volume appear unchanged. You can inspect traces, deployment differences, and dependency metrics. Describe your first investigation and how you would judge a fix.

Engineering reference: Google SRE’s guide to monitoring latency and the slow tail.

Assume these are observations in a fictional incident, not enough information to identify a cause.

My sequence would be: Confirm comparable measurement windows and sample sizes; split latency by region, endpoint, payload size, and cache status; compare slow traces before and after the rollout; then isolate the component contributing additional time.

A small subset of requests waiting on a new dependency could move p99 while barely affecting the median. That is a hypothesis to examine, not a diagnosis.

The follow-up: CPU looks normal, but connection-pool waits are high. Explain why increasing the pool might move the bottleneck downstream. Propose one controlled change, a rollback condition, and measurements of latency, errors, and resource use that would tell you whether it helped.

10. Amazon practice: Can you retry checkout without creating another order?

The question: Design create_order(customer, request_key, cart) so that a client can safely retry after a timeout. The same customer, key, and cart should resolve to one order. Reusing the key for different contents must be rejected.

Engineering reference: Amazon’s guide to making retries safe with idempotent APIs.

Walk through this sequence: the database commits the order, the response disappears, and the client retries on another server.

The approach I’d defend: Scope the key to the authenticated customer, compare a canonical representation of the request, and enforce uniqueness in durable storage. Commit the order and its idempotency record together where the database permits. Specify how callers observe an in-progress attempt and how a completed response is recovered.

An in-memory check followed by a separate insert leaves a race between simultaneous requests.

The follow-up: Add an external payment operation. A local database transaction does not make a remote charge atomic. Discuss a durable workflow, the payment provider’s idempotency mechanism, reconciliation, and what happens after the retry window expires.

The ten checks I’d keep beside my editor

Press enter or click to view image in full size

I would use the image above as a review sheet after an attempt. It gives each question a specific result to explain, so the session cannot end with a vague feeling that I understood most of it.

For example, if I can write the cache but cannot explain why its old expiry event is harmless, I have found tomorrow’s practice task. I do not need another fifty-question list to tell me what to do next.

If you only have one week, pick three first

My first three would be #1 for reasoning, #5 for a runnable tree problem, and #8 for a small implementation with changing state. They are a manageable starting point, and the same review routine works for the rest.

• Days 1–2: Attempt #1 and #5 separately. Write the contract before coding, then keep one case your first approach mishandled or could have mishandled.
• Days 3–4: Build #8 in stages: values, formulas, then cycle rejection. Keep the grammar deliberately small so you can finish and explain it.
• Day 5: Reattempt the weakest question from an empty file. Record where you still needed a hint.
• Day 6: Work through one follow-up without looking at the previous explanation. Change the input or requirement enough to challenge your reasoning.
• Day 7: Explain a solution to another person, or record a walkthrough. Include its cost, its boundary behaviour, and the next requirement that would force a redesign.

If your loop includes system design, replace one coding session with #6 or #10. If it includes practical debugging or concurrency, make room for #7 or #9. The job description and recruiter’s format guidance should decide the emphasis.

I would rather finish October with three solutions I can adapt than ten solutions I can only recognise.

That is the confidence I want to build before an interview: knowing where my answer breaks, and having a sensible next step when it does.

Follow along if you want the deeper walkthroughs. I’ll keep focusing on the examples and follow-ups that make a familiar question worth practising again.

~ Emily