How Snap interviews — Question to Offer

1. The shape of a Snap loop

Snap is smaller than the FAANG companies. The loop is shorter and the rounds feel less rehearsed. A standard onsite is four rounds for E4/E5, five rounds for E6+. Each round is 45 minutes. Two are coding, one or two are system design, and one is behavioral with the hiring manager.

The levels run E3 through E7. E3 is new-grad. E4 is the IC entry bar for experienced hires. E5 is senior. E6 is staff. E7 is senior staff. Most experienced-hire offers land at E4 or E5. The system design bar starts to bite at E5 and gets serious at E6.

The first thing to notice: the engineers interviewing you have shipped the features you've used. The person grading your Stories design round may have built Stories. They aren't asking from a textbook. They're asking from production.

2. What Snap grades you on

Three things, in this order: product sense, mobile-first thinking, systems depth.

Product sense first because Snap is a product company. Every system design question is rooted in a feature you've used in the app. If you can't articulate what the user is trying to do, the systems answer doesn't land. The interviewer wants to hear you talk about the user before the boxes.

Mobile-first thinking second because the phone is the primary surface. The server is there to support what the app does. If you propose a system that needs the phone to be online and on Wi-Fi for the feature to work, you're designing for a desktop product. Snap engineers think about battery, network variability, asset size, and offline-first UX. They expect you to as well.

Systems depth third. The depth bar at E5 is one good deep dive. At E6 it's two or three deep dives plus a credible tradeoff story across the design.

3. What's different here

Product-flavored questions. Every system design prompt names a feature you can open the app and use. Stories. Snap Map. Lenses. Discover. Don't try to abstract away from the product surface. Embrace it. Talk about what the user sees first.
Camera-first design ethos. Snap thinks of itself as a camera company. Capture, share, vanish. The product loop is short. The interview values that loop. If your design takes 10 seconds to upload a snap, you've already failed the latency bar.
Ephemeral by default. Most Snap features have a TTL. Stories last 24 hours. Snaps disappear after viewing. Locations on the Map decay. The design rounds expect you to model ephemerality as a system property, not a database column.
AR is a first-class primitive. Lenses are the second-most-used feature after the camera. If you're at E5 or above, expect at least one round where AR asset delivery, face tracking, or on-device compute is in scope.
Smaller scale than FAANG. Snap has around 400M DAU. That's smaller than Meta or Google. You don't need to scope every problem at 10B users. Scope at 500M DAU and you're in the right room.

4. The level bar

How the bar shifts:

E3 / E4 (new-grad / IC entry) — design at the competent IC level. The diagram is the artifact. One seam pushed lightly. Mobile-first thinking expected as a sanity check, not as the deep dive.
E5 (senior) — design at the product-aware level. Depth is graded. One deep dive survives three pushes. The mobile/server seam is named and defended on at least one choice.
E6 (staff) — design at the systems thinker level. Two or three deep dives. Privacy and ephemerality treated as system properties. The AR / on-device tradeoff appears somewhere.
E7 (senior staff) — design at the organization level. You talk about how the platform supports new features, what the launch plan looks like, how teams own slices.

In this chapter, units target E5 by default unless the unit header says otherwise. Two units (Snap Map, take-home) target E6.

5. The Snap-flavored mistakes

Watch for:

Designing for desktop. Treating the client as a browser tab. Assuming reliable network. Snap engineers will catch this immediately.
Ignoring the camera. The camera is the start of every flow. If your design doesn't account for capture-to-share time, you've missed the product.
TTL as a database feature. Setting expires_at on a row and calling it done. Snap interviewers expect you to enforce expiry across every read surface: store, cache, CDN, client memory.
Treating the friend graph as Facebook. Snap's social graph is smaller, more intimate, and asymmetric in places (Best Friends). A friend list of 30 close people behaves differently from a follower count of 5000.
Skipping privacy. Every Snap feature has a privacy story. Snap Map has Ghost Mode. Messages disappear. Best Friends is hidden. If you don't bring privacy up in the first ten minutes, the interviewer will, and you'll lose a point.

6. The seven scenarios in this chapter

Each unit dissects one question end to end.

10.1 Snap Stories — ephemeral expiry — TTL as a system property; the canonical version of the question Meta also asks.
10.2 Snap Map — geo and privacy — geo-indexing plus per-friend visibility rules and location precision decay.
10.3 Snap chat — read and vanish — the per-recipient state machine; delete-on-read semantics; replay protection.
10.4 AR lens asset CDN — versioned lens assets, geographic targeting, on-device cache eviction.
10.5 Best Friends — the affinity graph — engagement-based scoring with recency decay; asymmetric ranking.
10.6 Discover — publisher content feed — curated content, rotation, per-user ranking, ad integration.
10.7 Take-home — ephemeral TTL enforcement — design doc for the subsystem that makes "gone after 24 hours" true everywhere.

7. The next page

The first scenario: Snap Stories. The 24-hour TTL is the obvious surface. The depth is in making "gone" mean gone everywhere.