My November 2026 shortlist, with the examples, traps and follow ups that make each question worth your time.
You can recognize an interview question, write a clean solution, and still solve a different problem from the one you were given.
Let tasks run in any order and a scheduling problem becomes a counting exercise. Keep their original order and that same shortcut can give the wrong answer. Both versions look reassuringly familiar until one little sentence changes the whole job.
That is what I want my November practice to catch. I’m choosing ten questions that make us read carefully, explain a decision and handle the follow-up without starting from zero. Your evenings are too valuable for another enormous bookmark folder.
I’ve added small practice examples and review prompts, and called out where the original report leaves details open.
Start with the section closest to your next round. Questions 1–3 cover algorithms, 4–7 cover practical implementation, and 8–10 cover system design and database reasoning. Each gives you something specific to explain when you finish.
1. Waymo: can you schedule the tasks in a different order?
Coding practice · Source page dated October 30
Run unit length tasks on one worker while leaving a cooldown between two tasks of the same type. You may reorder the tasks, and you want the earliest possible finish.
Try AAABBB with cooldown 2. One valid schedule is A B idle A B idle A B, which takes eight time units. Cooldown starts when a task finishes, so consecutive starts of the same type must be at least three units apart.
For n tasks, count the most frequent type. If its frequency is f, and m types share that frequency, the answer for nonempty input is max(n, (f − 1) × (cooldown + 1) + m). Empty input returns zero.
Before trusting the formula, explain the gaps forced by the busiest types and why enough other tasks can fill them. Counting the fixed alphabet takes O(n) time and constant extra space.
Then change one rule. Preserve the original order of AAABBB. It now takes 14 units. Track the next allowed start for each type and simulate; the eight-unit schedule is no longer available.
Try the full scheduling question yourself.
2. Lyft: can your smallest window handle repeated letters?
Coding practice · Source page dated October 28
Find the shortest substring of s containing every character required by t, including repeated copies. Matching is case-sensitive, and ties go to the earliest window. Return an empty string when no window qualifies.
For s = BAXAB and t = AAB, the answer is BAXA. Both four-character windows qualify, but the earlier one wins. Returning AB would quietly lose an A.
Grow a window until its character counts meet the requirements, then shrink it while it remains valid. Keep the best start and length, taking the final substring once. Moving both pointers forward gives O(|s| + |t|) time; the fixed letter alphabet bounds counting space.
Your check is the moment a count falls below its requirement. Explain why removing one surplus A can be harmless while removing the next A invalidates the window. Update the answer only for a strictly shorter window to preserve the earlier tie.
For a useful follow-up, ask whether the same constant-space claim survives arbitrary Unicode input. Your character model suddenly matters.
Work through the complete substring problem.
3. Google: can you reuse the answer when the tree root moves?
Coding stretch · Source page dated October 29
Given a tree with positive edge weights, return the sum of distances from every node to every other node. Running a traversal from each starting node works, but takes O(n²) time.
Use the path 0 —2— 1 —3— 2. The distance sums are [7, 5, 8]. We can check all three by hand before reaching for a larger example.
Root the tree once, compute subtree sizes and the root’s distance sum, then move the answer across each edge. For an edge of weight w from parent u to child v, let s be the child’s subtree size.
answer[v] = answer[u] + w × (n − 2s)
Those s nodes get w closer; the other n − s nodes get w farther away. Two traversals give O(n) time and O(n) space. Use a sufficiently wide integer type and avoid recursion-depth trouble on a long chain.
Finish by explaining the formula without looking at it. Then try a star-shaped tree. The practice payoff is understanding what changes across one edge, so you can derive the expression again.
Try the weighted-tree question from scratch.
4. Perplexity: can you build a file system without being too helpful?
Practical coding · Source page dated October 29
Build an in-memory file system with directory creation, listing, file appends and file reads. The important restriction is that mkdir creates only the final directory. Missing parents stay missing.
After mkdir(/notes), calling mkdir(/notes/november/day1) must fail because /notes/november does not exist. Automatically creating it feels helpful, but violates this version’s contract.
Agree on the error behavior and what ls returns for a file before writing methods. The report leaves those details open. For practice, choose explicit exceptions for invalid paths and a one-element filename list when listing a file.
Represent files and directories distinctly, and share one path resolver across operations. Resolve and validate the parent before changing state. Directory listing costs O(k log k) for sorting k names, in addition to walking the path.
Check the state after a failed operation. That unsuccessful call must leave no half-created directories behind. Then add recursive directory creation as a deliberate new feature and decide whether its failures should also be atomic.
Build the file system from this prompt.
5. Palantir: can you learn the code before trying to improve it?
Code comprehension · Source page dated October 30
Read an unfamiliar SQL-like query class, explain how it runs, then solve tasks using its mapping and accumulation operations. The original class was not included in the report, so any replacement implementation is a practice stand-in.
Use a small query API with lazy where and select steps, plus a terminal fold action. Trace one row through it before touching the implementation.
Suppose completed orders have amounts 12 and 8, while a cancelled order has amount 100. Filtering completed rows before summing must return 20. If you first project only amount and then filter by status, that later operation no longer has the field it needs.
Explain when work actually happens. Building a lazy query records steps; executing an action consumes rows. For a fold, say what the accumulator represents after every row and why the empty result has a sensible initial value.
Then inspect whether running the same query twice reuses a list or consumes an exhausted iterator. This is a lovely way to practice learning unfamiliar code without turning the session into a rewrite of somebody else’s library.
Explore the query-class exercise in full.
6. Anthropic: can your crawler stop at the right time?
Concurrency practice · Source page dated October 26
Starting from one URL, discover reachable pages on exactly the same hostname. Remove fragments before deduplicating, handle cycles, and fetch each eligible page at most once. Build the single-threaded version before adding workers.
Two workers can discover the same link simultaneously. Checking the visited set and claiming that URL must happen atomically, keeping only the individual set operations safe does not protect the whole decision.
Keep network calls outside the shared state lock. Then account for outstanding work, because an empty queue can coexist with a running fetch that will discover five more pages. Completion needs both no queued work and no active work, observed through coordinated state.
Make your check deterministic. Use a fake parser that pauses one worker while the queue becomes empty, then releases another link. The crawler must wait and discover it. Afterwards, inject a fetch error and explain how work accounting still reaches completion. A hanging fetch additionally needs a timeout or cancellation policy.
Practice the crawler and its concurrency follow-up.
7. MongoDB: can a waiting writer ever get its turn?
Concurrency stretch · Source page dated October 26
Implement a read-write lock using a mutex and condition variables. Several readers may enter together, but a writer must be alone. For the first version, exclude reentrancy, upgrades and timed acquisition.
Track active readers, an active-writer flag and waiting writers under one mutex. Condition waits belong inside loops that recheck the admission rule, as Python’s condition-variable documentation explains.
Now imagine one reader enters, a writer starts waiting, and new readers keep arriving before the current readers finish. Exclusion can remain correct while that writer waits forever.
Block new readers once a writer is waiting, so existing readers can drain. This addresses reader-induced writer starvation, but does not by itself guarantee FIFO service among writers. Specify fair queueing if every waiter needs eventual admission, and assume holders eventually release.
Draw the arrival sequence before writing more code. Show R1 entering, W1 waiting, R2 waiting, R1 leaving, then W1 entering. Follow up by asking whether sustained writer traffic can now starve readers. Fairness needs its own argument.
Try the complete read-write lock exercise.
8. Instacart: does your inventory system actually own the inventory?
System design · Source page dated October 30
Design an inventory system for grocery delivery. The original report names the topic without a detailed specification, so the ownership and freshness assumptions below are our practice framing.
Start by separating a warehouse you control from a partner supermarket whose shelves you only observe. Reserving the last unit makes sense in the first case. A reservation in your database cannot prevent an in-store shopper from taking the same item in the second.
For partner stores, track product and store identity alongside each stock signal’s source, observation time and arrival time. Keep enough history to resolve stale or conflicting reports according to an explicit policy.
Try this disagreement. A store file observed at 9:00 says five units remain. A shopper reports none at 9:20. The old file arrives at 9:30. Explain why arrival order alone should not make the item confidently available again.
Then discuss what the customer sees while confidence is low, how replacements work and how you measure shown availability against actual finds. If the exercise switches to an owned warehouse, add atomic reservations and releases. That change deserves a different design.
Work through the full inventory design prompt.
9. eBay: can you make your own system asynchronous?
System design and project discussion · Source page dated October 28
Explain a system you have genuinely worked on, then change one synchronous request into asynchronous work. This is where your project experience becomes part of the technical problem.
Choose a slow operation whose result the caller can wait for. An export is a useful practice example. The initial response can return an accepted job ID, while a separate status endpoint eventually returns success, failure or a download location.
Trace acceptance, durable job creation, dispatch, worker execution and result retrieval. Each arrow needs an answer when the process stops halfway through.
Pause at the gap between saving the job and sending its message. If the process crashes there, how does the job become discoverable again? A transactional outbox is one option, a durable job table that workers poll is another. Pick one and explain it.
Then deliver the same work twice. Show how repeated execution avoids duplicating its side effects, and how permanent failures reach the caller. Async changes the interaction and absorbs bursts, it does not erase work, guarantee faster completion or make an overloaded dependency healthy.
Practice the asynchronous system design question.
10. MongoDB, can you explain what happens after SQL leaves your editor?
Database discussion · Source page dated October 26
Walk through a query’s lifecycle inside a disk based database, then explain the buffer pool and optimizer. A relational engine is a useful practice model, but settle the engine and scope first.
Follow parsing and name resolution into planning, execution, page access and returned rows. Explain how cached pages avoid some reads, why a page in active use cannot simply be evicted, and what changes when a page is dirty.
For a write-ahead-logged engine, the relevant log records must be durable before the corresponding dirty data page reaches disk. The recovery story belongs in the explanation.
Now give the optimizer an unpleasant surprise. It expects ten matching rows but gets a million. Explain how that estimate can make a nested-loop plan expensive, then compare estimates with actual rows using a controlled example.
PostgreSQL’s EXPLAIN examples give you real plans to read. Remember that EXPLAIN ANALYZE executes the statement. Use a safe local dataset for practice, and investigate statistics and data distribution before prescribing another index.
Explore the complete database internals question.
Make this a November plan you can actually finish
Please don’t turn ten questions into ten unfinished side projects. Choose the lane that matches your interview format, then give one question enough attention to expose a specific gap.
For a coding screen, begin with #1 and #2. Try #3 when you can already explain a traversal and want a harder reuse-of-work problem.
For practical coding, start with #4 or #5, then add #6. Save #7 for rounds that explicitly expect concurrency fundamentals.
For backend or design rounds, work through #8 and #9, then use #10 to deepen the storage and query discussion.
Give the first attempt a boundary. Spend about 35 minutes implementing a small version or tracing a design, then ten minutes explaining its weakest assumption. These are practice timeboxes, so a larger concurrency exercise can span several sessions.
Keep a tiny note with four lines after each attempt. Record the requirement you nearly missed, the example that exposed it, the change you made and the follow-up you still cannot answer. That last line chooses your next session for you.
Come back from an empty file or blank diagram a day or two later. Change one meaningful rule before reattempting it. Reordering becomes fixed order, a missing parent becomes an error, or a quiet workload becomes two callers arriving together.
That is the progress I want from this list. By the end of November, I want the familiar looking problem to make me curious enough to read the sentence that changes everything.
If you’re following along, tell me which number deserves the next full walkthrough. I’ll keep these notes focused on the examples and decisions you can actually use in an interview.
~ Emily
Top comments (0)