Guides › Reddit
R

Reddit Interview Guide (2026)

You can pass this loop once you know what each round is actually scoring. Reddit is a real product company with a real bar: not FAANG-brutal, but do not read that as easy.

Software Engineer12 min readUpdated 2026-11

The complete Reddit interview, start to finish. Work through these 9 sections (about 12 min) and you walk in knowing exactly what each round tests and how to prepare.

The loop at a glance

Four to five rounds on one virtual onsite day. Here is what each one is really testing and the bar you clear.

  1. Coding (2 rounds). LeetCode medium with one hard-ish twist. The bar is clean working code while narrating, not the trick.
  2. System design (E4 and up). HLD for the comment system, feed, or voting. Depth on one hard part beats a shallow tour.
  3. LLD or CS fundamentals (new grad). Replaces full HLD for juniors: clean classes, clear interfaces, fundamentals cold.
  4. Behavioral and values. Real weight here. "Remember the human" is a hiring signal, not a poster.
  5. The through-line. Product sense. Every design prompt is grounded in how Reddit actually works, so know the app.

1Snapshot, read this first#

Thing Detail
Roles Software Engineer (Product, Infra, Ads, ML/Data), Senior, Staff
Levels E3 (new grad), E4 (mid), E5 (senior), E6+ (staff)
Process length Usually 3 to 5 weeks start to finish
Rounds OA (sometimes) to recruiter screen to tech phone screen to onsite loop (4 to 5 rounds)
What wins Clear communication, clean working code, honest tradeoff talk, genuine curiosity about Reddit
What fails Silent coding, over-engineering, no questions, treating culture round as filler
Comp US (E4) ~$180k to $210k base, ~$150k to $300k equity over 4y
Comp US (E5) ~$210k to $250k base, ~$400k to $700k equity over 4y
Comp India (SE) ~₹35L to ₹65L base plus RSUs; Reddit has a smaller India footprint
Comp UK (SE) ~£95k to £140k base plus equity (London/remote EMEA)
Comp Canada ~C$150k to C$210k base plus equity (Toronto/remote)

The one thing to understand about Reddit: it is a product with a soul, and they hire people who get that.

  • They will probe whether you actually use Reddit, whether you care about communities, and whether you can reason about systems where a single hot thread gets millions of views.
  • A vote count has to feel instant but does not have to be perfectly consistent, and they want to see you already feel that in your bones.
  • A pure algorithm robot who has never opened the app tends to struggle in the behavioral and design rounds, because those rounds assume you have an intuition for how the product behaves.
From the interviewer's chair

I am listening for product sense, not just correctness. When I ask about comments or voting, I want to hear that you have scrolled a real thread and noticed how it loads. Candidates who reason from the product up, not from the textbook down, are the ones I fight to hire.

2Getting the call (the part most guides skip)#

Reddit gets a flood of applicants for every req. Cold applications work, but your odds jump hard with a referral.

Get a referral, because it gets a human to open your resume.

  • The company runs on its own product, so engineers are active on LinkedIn and, yes, on Reddit itself.
  • Find someone on the team you are targeting and send a short honest note: four or five sentences, naming one specific thing you shipped that maps to their work.
  • A referral does not guarantee an interview, but it bypasses the keyword filter and gets a person to actually read you. That is half the battle.

Your resume has to survive a keyword scan, then impress a tired engineer in ten seconds. Lead every bullet with impact and a number.

  • Weak: "Worked on backend services for the feed."
  • Strong: "Rebuilt the comment-ranking service in Go, cut p99 latency from 420ms to 110ms and handled 3x traffic during spikes."

Why the strong bullet lands:

  • It names the metric that moved (p99, not "performance"), the before and after, and the load it survived.
  • That is the exact shape of thinking Reddit wants, because that is how their own engineers talk in design reviews.

Keywords that matter for most SE roles here:

  • The actual language in the job description: Go and Python dominate the backend, TypeScript on web, Kotlin for Android, Swift for iOS.
  • Plus "distributed systems," "microservices," "GraphQL," "Kubernetes," "high scale," "A/B testing," and "observability."
  • Do not stuff them. Earn them inside a bullet that proves you did the thing.

How people actually get shortlisted:

  • A referral plus a resume that reads like you have operated real systems at some scale, meaning you can point to QPS, data size, or user counts you dealt with.
  • New grads: lean on strong internships, a shipped side project with real users, or open-source contributions.
  • Contributed to anything Reddit touches (Go tooling, a popular OSS library, GraphQL or mobile frameworks)? Say so loudly and link it.

3The loop at a glance#

Round Length What it tests
OA (sometimes, often new-grad) 60 to 90 min 2 to 3 coding problems, medium difficulty, auto-graded
Recruiter screen 30 min Motivation, logistics, comp range, do you use Reddit
Tech phone screen 45 to 60 min One coding problem, live, with an engineer
Onsite: Coding 1 45 to 60 min DSA, usually two linked mediums or one hard-ish
Onsite: Coding 2 / LLD 45 to 60 min More DSA, or object-oriented design (junior)
Onsite: System Design 60 min HLD for E4+, scale and tradeoffs (skipped or light for new grad)
Onsite: Behavioral / Values 45 to 60 min Reddit values, collaboration, hiring-manager fit

How the day runs:

  • The onsite is usually a single virtual loop day: four to five back-to-back rounds with short breaks.
  • Senior candidates get a heavier system design weight, often two design-flavored rounds.
  • New grads get more coding and often a CS-fundamentals or LLD flavor instead of a full high-level design round.
  • One onsite round is typically owned by the hiring manager and blends behavioral questions with a lighter technical discussion, so treat the manager round as both.

4The coding or technical rounds#

The coding bar sits squarely at LeetCode medium, with one hard-ish twist somewhere in the loop.

  • They are not trying to trick you with obscure competitive-programming puzzles or heavy math.
  • They want to watch you turn a vague problem into working, correct, reasonably efficient code while talking the whole time.
  • That narration is how they tell a strong engineer from a lucky one.

The patterns they reuse the most, roughly in order of how often they show up:

  • Hash maps and frequency counting: top-k, grouping, dedup, counting. Ranking and counting are half of what Reddit does to a feed.
  • Trees and graphs: BFS, DFS, topological sort, connected components. Comment threads are literally trees, so expect walking nested comments or detecting a cycle in a moderation graph.
  • Intervals, sliding window, and two pointers for windowed aggregates and overlap problems.
  • Heaps for top-k and merge problems. Merge k sorted lists is a spiritual cousin of merging ranked feeds from several sources.
  • Basic dynamic programming. Rarely deep, but a 1D DP or a classic grid or edit-distance problem shows up.
  • String parsing and manipulation, often dressed up as parsing user input or a feed token.

A very Reddit-flavored prompt: "Given a flat list of comments, each with an id and a parent_id, build the nested comment tree and return it in display order."

  • One prompt, three skills: tree building, hash-map lookup, and recursion at once.
  • It maps straight to the product, which is exactly why they like it.

Here is the shape of a clean answer so you recognize it under pressure:

def build_tree(comments):
    # comments: list of dicts with "id", "parent_id", "text"
    by_id = {c["id"]: {"id": c["id"], "text": c["text"], "children": []}
        for c in comments}
    roots = []
    for c in comments:
        node = by_id[c["id"]]
        parent = c["parent_id"]
        if parent is None or parent not in by_id:
            roots.append(node)          # top-level comment or orphan
        else:
            by_id[parent]["children"].append(node)
    return roots                        # O(n) time, O(n) space

Where the follow-up goes:

  • If they ask for display order (newest first, or by score), that is your opening to sort children and talk about ties.
  • Practice the whole shape, including what you do when a parent_id points at a comment that was deleted.
Pause before you read on: in that build_tree, what happens if the comment list arrives out of order, a child before its parent? Does the code still work?
Reveal the answer
Yes, and this is worth saying out loud in the room. The first pass builds every node into by_id before any linking happens, so order does not matter. The second pass can attach a child to a parent that appears later in the list, because the parent node already exists in the map. If you had tried to do it in one pass, you would need the parents first or a deferred-fixup step. Naming that two-pass choice as deliberate is a quiet seniority signal.

How to actually win the round. This is where strong coders quietly bleed points:

  1. Clarify first. Ask about input size, edge cases, duplicates, empty input, and whether the input fits in memory. Thirty seconds of real questions signals seniority and often reshapes the problem.
  2. State your approach out loud before you type. Say the brute force, then the better one, then pick and justify: "I could do O(n squared) with nested loops, but a hash map gets me to O(n), so I will do that."
  3. Narrate as you code. Silence kills. The interviewer cannot credit reasoning they cannot hear, and two quiet minutes reads as stuck.
  4. State complexity unprompted. Time and space, every time, and say which term dominates.
  5. Test your own code. Walk a small example by hand, including an empty case and a one-element case. Catching your own off-by-one is often the gap between a weak yes and a strong yes.

Practice shape:

  • Timer at 35 minutes per problem, talking the whole time even when alone, because talking and typing at once is a skill you build.
  • About 60 to 80 mediums across the patterns above, plus a handful of hards on trees, graphs, and heaps so one tough problem does not rattle you.

5System design (HLD for senior, LLD for junior)#

For E4 and up, system design is where the offer is won or lost. For new grads it is lighter or replaced with object-oriented design and CS fundamentals.

Use a simple framework and do not skip steps, because jumping straight to boxes is the most common senior-candidate mistake:

  1. Clarify requirements and scope. Functional and non-functional. Nail down scale: reads versus writes, QPS, latency targets, data size. Reddit is extremely read-heavy, so say that out loud and let it drive your caching and fan-out choices.
  2. Draw the high-level boxes: clients, API or gateway, services, data stores, caches, queues. Keep it legible.
  3. Design the data model and the core API, including the exact fields and the read path.
  4. Go deep on one or two hard parts: ranking, fan-out, caching, consistency, hot keys. Depth on one thing beats a shallow tour of everything.
  5. Talk tradeoffs and failure modes. What breaks at 10x traffic? What is the bottleneck? What happens when the cache is cold or a service is down?

A rough read path for the signature comment-system question, so you have a mental picture to defend:

flowchart LR Client[Mobile or web] --> GW[API gateway] GW --> CS[Comment service] CS --> Cache[(Redis hot threads)] CS --> DB[(Postgres comments)] CS --> VC[(Redis vote counts)] CS --> Q[Vote queue] Q --> Agg[Count aggregator] Agg --> DB
The comment-system read and write paths. Hot threads and vote counts serve from Redis; votes land on a queue and get batched by an aggregator before touching Postgres, so a thousand upvotes a second never hammer one row.
The point of the design round

They are checking whether you reason about scale honestly, know when to cache and when a cache will bite you, understand that a vote count can be eventually consistent and that is fine, and admit what you do not know instead of bluffing. Pick a database and say why. "Postgres for the source of truth because I want relational integrity on comment-parent links, Redis for hot counts and ranked slices, Cassandra if write volume on votes outgrows a single primary." Opinions with reasons beat buzzword soup every time.

Classic prompts they ask, all product-grounded:

  • Design Reddit's comment system: nested comments, voting, ranking. The signature one. Talk tree structure, denormalized reply and vote counts, caching hot threads, and why you load deep threads lazily instead of all at once.
  • Design a news feed or the home feed. Fan-out on write versus read, ranking, pagination with a stable cursor rather than an offset.
  • Design a voting or score-update system at scale. Hot keys on viral posts, eventual consistency on counts, write batching so a thousand upvotes a second do not hammer the row.
  • Design a notification system with dedup and delivery guarantees.
  • Design a URL shortener or a rate limiter, which show up more on phone screens and for juniors.
Red flag that fails you here

Jumping to Kafka and sharding before you have established scale or even a working baseline. Reach for the heavy tool only after you have shown you need it. Naming Redis is nothing; saying why Redis beats the alternative here is everything.

For new grads, prepare CS fundamentals cold:

  • How a B-tree index speeds a lookup and when it does not help.
  • ACID versus eventual consistency, with a concrete example of each.
  • Process versus thread and what they share.
  • TCP versus UDP basics, and what actually happens from DNS to render when you type a URL.
  • The four OOP pillars with a real example of each.
  • For LLD, practice designing something like a parking lot, an elevator, or a comment-thread model with clean classes, clear interfaces, and a reason for each boundary.

6Behavioral and culture fit#

Do not sleep on this round. At Reddit it carries real weight, and strong coders get rejected right here after clearing every coding round.

Reddit's values, and the practical read on each:

  • Caring about communities, evolving fast, remembering the human, being default open, defaulting to honesty.
  • They want people who care about users, communicate directly without politics, stay calm in ambiguity, and treat teammates with respect even during an incident.
  • "Remember the human" is a hiring signal, not a slogan. They will ask about conflict and about how you treat people when things go wrong, listening for whether you made the situation better for everyone or just for yourself.

Prepare five or six STAR stories:

  • A hard technical problem, a conflict with a teammate, a project that failed or slipped, a time you influenced without authority, a time you got critical feedback and what you changed.
  • Lead with the situation briefly, spend most of your time on your specific actions (use "I," not "we"), and always land a result with a number.

One full worked example:

  • Situation: Our service's error rate jumped to 4% after a release, and two teams were blaming each other's changes while the on-call queue piled up.
  • Task: I was the on-call engineer and needed to stop the bleeding and find the actual cause without turning it into a blame fight.
  • Action: I rolled back my team's change first to remove our variable, even though I suspected it was not us, because stopping user pain came before being right. Then I pulled both teams into one channel, shared the dashboards openly, and we bisected the deploys together. The root cause was a shared config both releases touched. I wrote the fix and added a check so the two configs could not silently conflict again.
  • Result: Error rate dropped back under 0.1% within 40 minutes, and the guardrail I added caught two similar near-misses in the next quarter. Both teams signed off on the postmortem with zero finger-pointing.

Why that story works:

  • It hits "remember the human," default openness, and ownership, with a number in the result and a durable fix rather than a one-time patch.
  • Build yours the same way: a real stake, your specific moves, a measured outcome, and something that stayed better afterward.

7Your prep plan#

4-week plan:

  • Week 1: 20 LeetCode mediums across arrays, hash maps, two pointers, sliding window. Start using Reddit daily and note how one feature per day might be built behind the scenes.
  • Week 2: 20 more mediums on trees, graphs, heaps. Read one system design primer front to back and sketch the comment system from memory afterward.
  • Week 3: Do 4 full system design mocks (comment system, home feed, voting, notifications), out loud, drawing as you go. Write out 6 STAR stories.
  • Week 4: Mixed timed coding, 2 mock loops with a friend who will push back, polish stories, and research Reddit's values and recent product and engineering news so you have a specific reason you want in.

2-week plan:

  • Week 1: 30 targeted mediums on the core patterns, plus 3 tree or graph hards. Daily out-loud practice with a timer.
  • Week 2: 3 design mocks, 5 STAR stories, 1 full mock loop end to end, and a pass over complexity analysis so you can state it instantly.

2-day crash plan:

  • Day 1: 10 mediums on trees, graphs, heaps, and hash maps. Do the comment-tree problem until it is automatic. Review one full design walkthrough of the comment system.
  • Day 2: 3 STAR stories written out, one timed coding session talking aloud, read Reddit's values page, and skim the last few Reddit engineering blog posts so you can name something specific in the behavioral round.

8Why people get rejected at Reddit#

  1. Silent coding. They solved it but never explained their thinking, so the interviewer could not score the reasoning and had to guess, and guesses skew to no.
  2. Over-engineering the design. Jumping to Kafka and sharding before establishing scale or even a working baseline. Reach for the complex tool only after you have shown you need it.
  3. Buzzword answers in system design with no reasons behind the tech choices. Naming Redis is nothing; saying why Redis beats the alternative here is everything.
  4. Zero curiosity about the product. Never used Reddit, asked no questions, flat energy in the values round. That reads as "I just want a job," and this team hires people who want this job.
  5. Bluffing. Pretending to know something instead of saying "I am not sure, here is how I would find out." Default openness is a value, so faking it fails twice.
  6. Weak behavioral stories: vague, no numbers, or every conflict story ending with "and I was right." Reddit wants to see you make things better for the team, not win arguments.

9The offer, comp and negotiation#

Realistic 2026 ranges (base plus equity, RSUs vest over 4 years):

  • US E4: ~$180k to $210k base, ~$150k to $300k equity total.
  • US E5: ~$210k to $250k base, ~$400k to $700k equity total, plus bonus.
  • India: ~₹35L to ₹65L base plus RSUs. Smaller office presence, so roles are limited and competitive.
  • UK: ~£95k to £140k base plus equity, London or remote EMEA.
  • Canada: ~C$150k to C$210k base plus equity, Toronto or remote.

Reddit equity is easier to value than at most startups:

  • As a public company now, the equity is RSUs with a real market price, not private-company options with a made-up strike.
  • You can see the current share price, do the math on the four-year grant, and know roughly what you are signing.
  • Numbers move with level, team, and market, so treat these as a map, not a guarantee, and always get the full breakdown in writing before you respond.

Negotiation tips:

  • Get competing offers, or at least a credible market number from a few sources. The strongest lever by far is a real alternative you are willing to take.
  • Negotiate equity and sign-on, not just base. Reddit usually has more room on the stock and sign-on side than on base, so aim your ask there.
  • Be direct and warm, which matches their culture: "I am excited about the comment-infra team. To make this an easy yes, I would love to close the gap on equity." No games, just a clear ask with a reason, and a real number.
Follow-ups the interviewer will ask (and your answers)
"A post goes viral and one comment thread gets millions of views. What breaks, and how do you keep it fast?"
That is a hot key. The thread and its vote counts become one cache entry hammered by millions of reads. I serve hot threads from Redis with a short TTL, replicate or locally cache the hottest entries across app hosts so one node is not cooked, and coalesce concurrent misses so a cold load triggers one fetch, not a stampede. The vote count stays eventually consistent, which is fine for this product.
"A thousand upvotes a second land on one post. How do you not melt the database row?"
I do not write the row per vote. Votes go onto a queue, a count aggregator batches them over a short window, and writes the delta to Postgres periodically. The live count shown to users comes from Redis, updated optimistically. The source-of-truth row converges within seconds, and the user never waits on it.
"Fan-out on write or on read for the home feed?"
Hybrid. Push to followers' feeds at write time for normal accounts so reads are cheap, but large subreddits or high-follower accounts would blow up a pure push, so those get pulled and merged at read time. Reddit is extremely read-heavy, so I precompute where I can and keep the expensive pull narrow.
"The parent_id of a comment points at a comment that was deleted. What does your tree do?"
I treat it as an orphan or re-root it under a deleted-placeholder node, depending on product rules. In build_tree, the `parent not in by_id` branch already catches it and keeps the child visible rather than dropping the subtree, which matters because real threads keep replies to deleted comments.
"Why Postgres for comments and not just Cassandra everywhere?"
Comment-parent links are relational and I want integrity and easy range queries on a thread, which Postgres gives me cleanly. I reach for Cassandra only if vote write volume outgrows a single primary, and even then I keep the comment graph relational. Pick the store per access pattern, not one hammer for everything.

What you can now explain in the room

  • What each round of the Reddit loop is actually scoring, and how the senior and new-grad paths differ.
  • How to build a nested comment tree in O(n), and why the two-pass version survives out-of-order input.
  • The five habits that separate a strong yes from a weak one in a coding round.
  • Why a vote count can be eventually consistent, and how queue plus aggregator keeps a hot row alive.
  • How to defend a database choice with reasons (Postgres for the graph, Redis for hot counts) instead of buzzwords.
  • Why the values round carries real weight, and how to build a STAR story that lands "remember the human."

When you are ready, map these rounds onto your real calendar and build a dated plan that fits the weeks you actually have before your loop.

Get a prep plan built around your Reddit interview

Tell us the role and your interview date. We will send back a dated, day by day plan. Free.

Thanks. Check your inbox, your Reddit prep plan is on the way.