Reddit Phone Screen Interview: What Gets Tested and How to Pass

- Reddit phone screen runs 60 minutes on CoderPad in explicit pair programming style: narrating as you code is mandatory, not optional.
- The follow-up question is a deliberate probe that separates candidates who understand their solution from those who memorized it.
- Sliding window, hash maps, BFS/DFS, stacks, and intervals cover the five pattern families most likely to appear on the phone screen.
- The hiring manager screen is a real gate: vague answers about liking Reddit fail; specific technical reasons tied to what the team builds land.
- Aim to finish the main problem by minute 35 so you have time for complexity analysis, optimization, and the follow-up variant.
- Voice-based mock practice matters more than grinding harder problems because the pair programming format scores narration and problem-solving simultaneously.
Reddit's interview pipeline moves faster than most big tech loops. Most engineers get from recruiter call to offer in under four weeks. The Reddit phone screen interview is where a meaningful chunk of the field gets cut, and the format has a wrinkle most candidates don't see coming: there's someone watching you the entire time, waiting for you to say something.
Sitting there. Watching the cursor blink.
Know the Format Before You Log On
| Attribute | Detail |
|---|---|
| Duration | ~60 minutes |
| Platform | CoderPad (live collaborative coding) |
| Problems | 1 medium-difficulty DSA problem, usually a follow-up |
| Format | Pair programming style, no silent coding |
| Who runs it | Engineering interviewer |
| Separate hiring manager screen | Often yes, sometimes before the technical |
| Overall difficulty (Glassdoor) | 2.95 / 5 |
| Average pipeline length | ~26 days |
Reddit sometimes structures the pre-onsite phase as two distinct calls: a hiring manager screen (behavioral, 30-45 minutes) and the technical phone screen (coding, 60 minutes). The order varies by team. Don't treat either as a formality. Especially the HM screen, which trips up more people than the actual coding, mostly because they don't study for it at all.
What Actually Happens in 60 Minutes
You join a Zoom call. You get access to a shared CoderPad editor. The interviewer says hello, explains the problem, and then it is on. No warm-up. No "tell me about yourself." No gentle throat-clearing. Problem. Go.
The session is explicitly pair programming. Reddit interviewers don't sit silently while you code. They ask questions, nudge you toward edge cases, and respond when you talk through your reasoning. Three minutes of silence in this format doesn't communicate "I'm focused." It communicates "I have gone somewhere private and cannot be reached."
A typical run:
- 0-5 min: Problem statement, clarifying questions
- 5-35 min: Implementation, talking through decisions
- 35-45 min: Optimization, complexity analysis
- 45-60 min: Follow-up variant or edge case extension
One problem is the norm. A follow-up that modifies the constraints appears frequently enough to treat as expected. Common shapes: different input structure, tighter time bound, streaming version, or a new constraint that politely destroys your original approach.
That last one is intentional. You'll find out in the next section.
What They're Actually Testing
The coding problem will sit at LeetCode medium difficulty. Reddit doesn't throw hard problems at the phone screen. They throw medium problems and watch how you handle them. The rubric isn't "did you solve it" so much as "what did solving it reveal about how you think."
Common patterns candidates report seeing:
- Sliding window and two pointers (strings, subarrays, maximizing subarray length)
- Hash maps for frequency counting, complement lookup, duplicate detection
- BFS and DFS on graphs or binary trees (adjacency list inputs appear often)
- Stack problems (parentheses matching, next greater element, monotonic variants)
- Interval problems (merge intervals, overlap detection, minimum rooms)
Dynamic programming shows up occasionally but is less common at the phone screen than at the onsite. If you see DP, it tends to be 1D: coin change, house robber, Fibonacci shape.
The follow-up is a deliberate trap, lovingly set. Candidates who have a working but rote solution get stuck when constraints change. Candidates who understand why their solution works can adapt quickly. The follow-up exists specifically to figure out which kind you are. Spoiler: it will be extremely clear, to both of you.
The Hiring Manager Screen: Not a Vibe Check
Most engineers study hard for the coding round and then coast into the HM screen expecting a casual chat. They will not get a casual chat. It's a genuine filter at Reddit, not a warmup. It evaluates whether you'd fit the team's working style and whether you actually care about what Reddit is building.
Expect questions like:
- Walk me through a technically challenging project you owned.
- Tell me about a time you had to make a call with incomplete information.
- How do you handle disagreement with a technical decision you didn't make?
- What draws you to Reddit specifically?
That last question is where unprepared candidates lose the room. Vague answers ("I like the platform," "it's an exciting company") send no signal. Reddit has 1.6 billion monthly active users. "I find the platform interesting" describes basically every website that exists. It's the interview equivalent of telling someone you like food.
Reddit engineering attracts people who care about specific, hard problems: content ranking at scale, real-time vote counts across thousands of communities, safety tooling that works globally. Specific answers land. Name a problem space you'd actually want to work on.
Look at Reddit's engineering blog before the HM screen. One concrete technical detail you found there signals more genuine interest than five generic reasons.
How Reddit Scores the Phone Screen
Reddit doesn't publish a rubric, but candidate reports and the structure of the round point to four things evaluators care about:
Problem-solving process. Did you break the problem down before writing code? A candidate who writes a correct brute force, identifies the bottleneck, and proposes an optimized approach communicates more than one who silently produces an optimal solution. The thinking is what the interviewer is there to observe.
Code quality. Naming, structure, and edge case handling. Reddit engineers write Go, Kotlin, Python, and Java. They care whether code would survive a code review, not just whether it passes the test cases.
Communication throughout. If you go quiet for five minutes and produce correct code, that registers as a weak communication signal. If you explain why you're choosing a hash map over a sorted array while you code, that's a strong one. Narrating your reasoning is a learnable skill, and it matters from minute one.
Speed and coverage. Aim to have a working solution by the 35-minute mark. A candidate who takes 50 minutes on the main problem and has nothing left for the follow-up is leaving signal on the table.
What to Drill, In Order
1. Sliding window. Fixed-size and variable-size variants. Know the condition that shrinks the window from the left. Practice: Longest Substring Without Repeating Characters (LC 3), Minimum Window Substring (LC 76).
2. Hash map patterns. Frequency maps, Two Sum complement lookup, character count comparison. Practice: Two Sum (LC 1), Group Anagrams (LC 49), Subarray Sum Equals K (LC 560).
3. Graph traversal. BFS and DFS from scratch, from an adjacency list, not assuming a tree structure. Connected components and cycle detection. Practice: Number of Islands (LC 200), Course Schedule (LC 207), Rotting Oranges (LC 994).
4. Stack patterns. Monotonic stack for next greater element, balanced parentheses. Practice: Valid Parentheses (LC 20), Daily Temperatures (LC 739).
5. Two pointers. Converging on sorted arrays, fast/slow on linked lists. Practice: 3Sum (LC 15), Container With Most Water (LC 11).
You don't need to master hard problems for this round. You need to execute medium problems cleanly, explain your complexity analysis correctly, and extend your solution when the follow-up modifies the constraints.
Before you write a single line of code, spend 3-5 minutes on clarifying questions. Confirming input type, size constraints, and expected output takes two minutes and prevents the kind of assumption that silently breaks your solution at minute 40. Ask while it's still cheap to ask.
How Candidates Blow It
These are not subtle missteps. These are things that feel completely fine in the moment and look awful in the write-up.
Starting to code immediately. Skipping clarifications doesn't signal confidence. It signals that you didn't stop to think. One question at the start beats one bug at minute 45. Every single time.
Going silent during implementation. You are in a pair programming session. The interviewer is sitting there. They can see the cursor blinking. Three minutes of silence reads as a communication failure, not deep concentration. "I'm checking whether we need to handle negative numbers" is better than nothing. "Give me a second, I think I see it" is better than nothing. The bar is extremely low. Use it.
Optimizing before you have a working solution. A correct brute force with an identified bottleneck beats an incorrect optimal solution every time. Start simple. Write the O(n²) version. Say it's O(n²). Then optimize. This sequence communicates far more than jumping straight to optimal and getting stuck halfway through.
Skipping edge cases. Name them before you code, handle them during: empty input, single element, all-same values, negatives, overflow. Saying "I should also check for an empty array" out loud is worth points even if your implementation isn't perfect.
Generic answers in the HM screen. "I like Reddit's culture" sends no signal. One specific technical challenge you'd want to work on sends the right signal.
A Four-Week Plan
Weeks 1-2. Drill the five patterns above by pattern, not by random problem. Aim for 2-3 problems per pattern per day. Focus on pattern recognition: what does the problem structure tell you before you've written a line of code?
Week 3. Start timing yourself. Target a working solution in 25-30 minutes, then use the remaining time to optimize and explain your complexity analysis out loud. If you can't explain the time and space complexity without hesitating, you don't understand the solution yet.
Week 4. Run voice-based mock sessions. The goal isn't to solve harder problems. It's to stop going silent under pressure. The pair programming format rewards candidates who can narrate and code simultaneously. That's a separate skill from problem-solving, and it requires separate practice. SpaceComplexity runs voice-based DSA mock interviews with rubric-based feedback on communication and problem-solving, which is exactly what this round tests.
Day before. Review your edge case checklist. Skim Reddit's engineering blog. Have two or three specific reasons you want to work at Reddit, tied to what the team actually builds.
Once you pass the phone screen, you're heading into the full onsite loop. See the Reddit software engineer interview guide for what each of those rounds tests, and the Reddit behavioral interview questions guide to prep the values round specifically.
Further Reading
- Reddit Engineering Blog (r/RedditEng), real technical posts from the team you're interviewing with
- Reddit Careers, current job descriptions; the tech stack listed is signal for what the team uses
- CoderPad Documentation, understand the platform before you're in it
- Glassdoor: Reddit Software Engineer Interviews, recent candidate reports, updated regularly
- LeetCode Problem Set, the five patterns above are all well-represented; filter by tag