Top 15 Phone Screen Coding Questions (and What Each One Tests)

You have 30 minutes. One problem. An engineer on the other end typing notes in a tab you cannot see.

Interviewers choose phone screen coding questions where the brute-force path is visible, the optimization is reachable in 25 minutes, and there's enough follow-up surface to probe depth without a second problem. The list below comes from frequency data across 40+ companies and hundreds of interview reports. Not the general LeetCode top 100. The narrower set that shows up disproportionately at the phone screen stage.

Problems with multiple valid approaches get picked because the interviewer can redirect to a second dimension without starting a new problem. Almost everything here is Easy to Medium. Google reaches for Hard occasionally. Amazon almost never does. The standard is a Medium with a clear O(n) or O(n log n) solution reachable in time.

Each entry covers the pattern, why it earns the spot, and what the interviewer is actually watching for.

All 15 at a Glance

#	Problem	LeetCode #	Core Pattern	Difficulty
1	Two Sum	1	Hash Map	Easy
2	Valid Parentheses	20	Stack	Easy
3	Longest Substring Without Repeating Characters	3	Sliding Window	Medium
4	Reverse Linked List	206	Linked List	Easy
5	Maximum Subarray	53	Kadane's	Medium
6	3Sum	15	Two Pointers	Medium
7	Group Anagrams	49	Hash Map	Medium
8	Merge Intervals	56	Intervals	Medium
9	Binary Tree Level Order Traversal	102	BFS	Medium
10	Number of Islands	200	BFS / DFS	Medium
11	Subarray Sum Equals K	560	Prefix Sum + Hash Map	Medium
12	Product of Array Except Self	238	Prefix / Suffix	Medium
13	Trapping Rain Water	42	Two Pointers / DP	Hard
14	LRU Cache	146	Hash Map + DLL	Medium
15	Minimum Window Substring	76	Sliding Window	Hard

The 15 Problems

1. Two Sum

Two Sum is everywhere. It has appeared at every major company so many times that some engineers solve it with the thousand-yard stare of someone who has seen things.

Two Sum is easy enough that the answer is not the signal. Your process is. The brute-force is O(n²). The hash map solution is O(n). What the interviewer watches: do you explain your approach before coding? Do you name the time/space trade-off? Do you check edge cases before declaring done? Five clean minutes here tells the interviewer whether you panic or whether you work. Most candidates declare done without testing. Don't be those candidates.

2. Valid Parentheses

Stack problems earn phone screen spots because the mental model is simple and the implementation is slightly trickier than it looks.

Use a hash map for bracket pairs, push on open, pop and compare on close. The trap: encountering a closing bracket when the stack is empty. If you write if stack[-1] == matching_open without a length guard, you will crash on "]" and watch in real time as your interviewer makes a note. This problem is Easy, which is exactly why interviewers use it to watch process instead of pattern recall.

3. Longest Substring Without Repeating Characters

This is the most-tested sliding window problem at the phone screen stage, appearing in the top five at Google, Meta, and Amazon. Pattern: maintain a window with a set or hash map, expand right, shrink left when a duplicate enters.

The interviewer probes two things: can you reason about window validity without nested loops, and can you handle the shrink logic correctly? Getting the shrink condition subtly wrong is how you fail a Medium you think you know. The sliding window guide has it spelled out.

4. Reverse Linked List

Three pointers, one pass. Short enough that the whole thing fits on half a screen.

The interviewer watches for pointer hygiene: null-terminate correctly, name variables clearly, trace a two-node example without losing track of prev versus curr. Candidates who muddle through and get it right score lower than candidates who trace once and code cleanly. The implementation is simple enough that messiness reads as a pattern, not a one-time slip.

5. Maximum Subarray

Kadane's algorithm looks like DP until you realize it's greedy. Extend the current subarray if adding the next element helps. Restart if it doesn't.

The most common mistake: initializing current_max or global_max to 0 instead of nums[0]. That breaks all-negative inputs. The interviewer who hands you [-3, -1, -2] is specifically watching for this. You will get the wrong answer of 0 and declare done with visible confidence. The correct initialization is the first element. The correct answer for that input is -1.

6. 3Sum

Sort the array, fix one pointer, two pointers for the remaining sum. The deduplication step is where most candidates fail: skipping duplicates for the outer loop and for both inner pointers.

Without deduplication you return repeated triplets on inputs with repeated values. The interviewer gives you [-2, 0, 0, 2, 2] and your solution returns [[-2,0,2], [-2,0,2]]. Phone screen interviewers choose 3Sum because you cannot hash your way around it. You have to explain the sort-then-two-pointer approach before you code, giving the interviewer a clear view of your reasoning before you have a chance to get lucky.

7. Group Anagrams

Construct a hash key from each word by sorting it or encoding a character-count tuple, then group words by key.

The candidate who constructs a meaningful hash key solves it cleanly in a few lines. The candidate who tries nested comparisons does not. Interviewers use it to test hash map fluency, specifically the ability to construct a key rather than just look things up. The follow-up ("what if the words are very long?") changes the key construction cost and opens a complexity trade-off discussion. This is the rare phone screen problem where looking smart feels good rather than desperate.

8. Merge Intervals

Sort by start time, iterate once, merge when the current interval's start falls at or before the last merged interval's end.

The detail most candidates miss: update the end with max(last.end, current.end), not just current.end. Skip the max and a fully contained interval [1,10] followed by [2,5] incorrectly shrinks your merged result to [1,5]. You will look at that output, squint, and say "that seems right." It is not right. Sorting is implied but not stated, so you must think to sort. Follow-ups like "insert a new interval" extend it naturally.

9. Binary Tree Level Order Traversal

Most candidates know BFS. Fewer do BFS by level correctly.

Snapshot the queue length at the start of each outer loop iteration and process exactly that many nodes before moving to the next level. for _ in range(len(queue)) inside a while queue loop is the clean pattern. Candidates who try to track levels with a sentinel value tend to get tangled in the sentinel logic and spend five minutes debugging something that did not need to exist. The BFS guide covers both tree and graph variations.

10. Number of Islands

Start from each unvisited land cell, flood-fill to mark the island as visited, increment the count.

The classic mistake: marking cells as visited after you push to the queue instead of before. Mark after and you push the same cell multiple times and end up counting one island as fourteen. Mark before and each cell enters exactly once. BFS or DFS both work. The interviewer cares whether you mark correctly and handle boundaries without crashing, not which traversal strategy you pick.

11. Subarray Sum Equals K

Store prefix sums in a hash map as you iterate, and at each index check whether prefix_sum - k already exists in the map. If it does, you found a valid subarray. This combines prefix sums and hash maps in a way that is genuinely non-obvious the first time you see it.

The shift most candidates miss: you store "what you have seen" rather than "what you are searching for." That inversion is the whole trick. The prefix sum guide has the derivation. If this one is not on your prep list yet, put it there now. It shows up constantly.

12. Product of Array Except Self

Two passes. Forward for left products, backward for right products. The follow-up ("can you do it in O(1) extra space?") requires writing left products directly into the output array, then doing a single backward pass with a running right-product variable.

Candidates who solve the two-array version and reason through the space optimization in conversation score the same as candidates who jump straight to O(1). The optimization is the signal, not a prerequisite. The interviewer wants to watch you reason about it, not watch you produce it silently from memory.

13. Trapping Rain Water

The one Hard on this list, appearing regularly in Google phone screens.

The O(n) two-pointer solution: maintain left max and right max as two pointers move inward. When left_max < right_max, the left side is the bottleneck regardless of what's exactly on the right, because the right is guaranteed to be at least as tall as right_max. You do not need to know the exact right side. You know it's tall enough. That realization is the whole problem. The DP arrays approach works equally well and scores the same. Both demonstrate understanding. Pick the one you can implement without panic.

14. LRU Cache

LRU Cache is the most common design-adjacent problem at the phone screen stage, which surprises most candidates because it does not look like a DSA problem until you try to make it fast.

O(1) for all operations requires a hash map for lookup and a doubly linked list for O(1) move-to-front and O(1) evict-from-back. Without both structures, you cannot hit O(1) everywhere. Python's OrderedDict is an acceptable starting point. Expect the interviewer to ask you to implement from scratch. Sentinel head and tail nodes eliminate most edge cases. The LRU Cache guide covers the full construction if you have never built one before.

15. Minimum Window Substring

The hardest problem on this list. Hard in the same way a sliding window problem is hard when you have been under pressure for twenty minutes and your satisfied-character count is sitting in the wrong variable.

Pattern: maintain a frequency map for the target, a current-window frequency map, a satisfied-character count, expand right until the window is valid, shrink left to minimize. The satisfied-character count is the piece most candidates drop when they code too fast. Interviewers use this to separate candidates who know the sliding window pattern from those who can implement it cleanly under pressure. The difference between those two groups is just reps.

How to Prepare for Phone Screen Coding Questions

Two patterns carry disproportionate weight: sliding window (3, 15) and hash map combinations (1, 7, 11). Both appear across every company. If time is limited, start there.

Drilling a problem once is not preparation. Deriving the solution from scratch on a blank editor 48 hours later is. Solve it, close it, wait, reconstruct without notes. What you can reconstruct under zero pressure, you can actually code under real pressure. What you watched someone else solve and nodded at? That is not the same thing at all.

If you want to practice the communication layer too, not just the code, SpaceComplexity runs voice-based mock phone screens with rubric feedback across all four dimensions.

The technical phone screen guide covers how the whole format is scored.

Key Takeaways

Phone screens are almost entirely Easy to Medium. Hard problems at Google are the exception, not the rule
The signal is process: brute-force explanation before coding, optimization reasoning, edge case handling before submission
LRU Cache is the most surprising entry. It tests combined data structure design, not algorithm recall, and most candidates walk in unprepared for that
Subarray Sum Equals K and Product of Array Except Self appear more than most prep lists acknowledge. Drill both early
Initializing global_max to 0 breaks all-negative inputs. You will make this mistake exactly once