Snap Data Engineer Interview Guide

Snap's interview loop for data engineers is one of the most infrastructure-heavy among social media companies. Candidates who over-index on SQL and algorithm prep get caught off guard by how much the process tests pipeline ownership, system design, and cross-functional communication. If you're coming from a pure software engineering background, recalibrate your prep accordingly.

Snap Data Engineer Role

Your job is to own the Airflow DAGs and Spark jobs that feed Snap's ad-serving models, content-ranking systems, and finance reconciliation workflows. Snap's $5.4B+ annual revenue runs on auction-based ads, which means late or incorrect data in those pipelines directly hits the bottom line. Success after year one looks like owning a pipeline domain end-to-end (Ads attribution, Spotlight creator payouts, or Snapchat+ subscription analytics), with clean SLAs that downstream data scientists and analysts actually trust.

A Typical Week

Infrastructure work consuming 20% of your week on top of the 30% spent writing code is the split that surprises most candidates. SLA reviews, on-call triage, Kafka consumer debugging, runbook updates for the next rotation engineer: pipeline maintenance is a first-class responsibility here, not an afterthought. Nearly a fifth of your time goes to cross-functional syncs with teams like Ads Measurement and Spotlight product analytics, who depend on the tables you build.

Projects & Impact Areas

Ad revenue attribution is the highest-stakes pipeline work. A 3% discrepancy in eCPM multi-touch logic can trigger a fire drill with the Ads Measurement data science pod, and you'll be the one reconciling the numbers. The same week, you might write data quality checks for Spotlight creator payout tables or draft a design doc for Snapchat+ subscriber event pipelines, where partitioning strategy matters because finance pulls those tables every Monday morning. Some roles also touch hardware telemetry data (AR Lens interaction events, sensor streams from Spectacles), which involves schemas and volume profiles that look nothing like social app engagement tables.

Skills & What's Expected

Working ML knowledge matters here (Snap's platform leans on ML for content ranking and AR), but production-grade Python/Java/Scala is where candidates actually get filtered out. Snap's postings require 3+ years of pipeline building alongside SQL, so pure SQL specialists hit a wall. The underrated skill is stakeholder communication: you need to understand why a 6-hour staleness on the stories_daily_views table matters to content ranking, then explain that tradeoff to a non-technical product lead in a way that shifts priorities.

Levels & Career Growth

Snap uses numeric levels (L3 through L7+), and L4 postings appear explicitly on their careers page. The jump from L4 to L5 hinges on owning an entire pipeline domain, setting its SLAs, and being the person downstream teams page when something breaks. L6+ requires cross-team influence, like defining org-wide data contracts that multiple pods adopt or leading a significant infrastructure migration. If you have 5+ years of pipeline experience, push for the L5 level match during the process rather than accepting L4 with a vague promise of fast promotion.

Work Culture

Snap runs a "default together" policy requiring four days per week in the Santa Monica office (Tuesday through Friday, with Monday as the flexible remote day). Many engineers come in all five days for the cafeteria and the ocean-adjacent location. Engineering culture here genuinely values rewrites when the math works out. Their engineering blog openly discusses making the most of migrations, so don't be surprised if your team is mid-rewrite of a legacy Java ETL job into Python on any given quarter. Most engineers are offline by 6 PM, and weekend work is limited to on-call rotations.

Snap Data Engineer Compensation

No cliff on your initial RSU grant sounds friendly, but the absence of traditional yearly stacking refreshers means your equity income can thin out after that initial three-year vest completes. The sign-on bonus is your real buffer. Part of it vests quickly over the first six months, with the remainder spread across three years, so it front-loads cash during the period when you have the least visibility into what future equity grants might look like.

Snap recruiters often open with a "non-negotiable" framing on comp. Push past it. The sign-on bonus is almost always movable, and at senior levels, the initial RSU grant size is fair game too. Base salary is the hardest lever to pull, so spend your negotiation capital on equity and sign-on instead of fighting over a few thousand in base.

Snap Data Engineer Interview Process

Budget about six weeks from recruiter screen to offer. That's slower than most big-tech loops, so don't mistake silence for rejection. Proactive check-ins with your recruiter are worth the awkwardness.

The top rejection driver, from what candidates report, isn't the coding round. It's system design. Snap's round explicitly asks you to architect an end-to-end data pipeline (ingestion, processing, storage, serving) using technologies like Spark and Kafka, and candidates who default to generic web-app designs instead of data platform thinking get filtered out. One wrinkle worth flagging: round 6 is labeled "Behavioral" but actually digs into technical depth, asking you to walk through a past data engineering project's architecture or optimize real code. Prep two separate story banks, one for the pure behavioral round (stakeholder conflicts, SLA recoveries) and one for the technical deep-dive, or you'll burn through material fast.

Snap Data Engineer Interview Questions

/* BigQuery Standard SQL */
WITH latest_per_payment AS (
  SELECT
    payment_id,
    user_id,
    amount,
    status,
    processed_at,
    updated_at,
    ROW_NUMBER() OVER (
      PARTITION BY payment_id
      ORDER BY updated_at DESC, processed_at DESC
    ) AS rn
  FROM `snap_fintech.snap_payments`
), deduped AS (
  SELECT
    payment_id,
    user_id,
    amount,
    status,
    processed_at
  FROM latest_per_payment
  WHERE rn = 1
)
SELECT
  DATE(processed_at) AS processed_date,
  SUM(CASE WHEN status = 'SUCCESS' THEN amount ELSE 0 END) AS successful_revenue,
  COUNT(DISTINCT CASE WHEN status = 'SUCCESS' THEN user_id END) AS paying_users
FROM deduped
GROUP BY processed_date
ORDER BY processed_date;

from collections import defaultdict
from typing import Dict, Iterable, List, Tuple

# Type: (user_id, event_time_ms, amount_cents)
Event = Tuple[str, int, int]


def max_10min_spend_by_user(events: Iterable[Event], window_ms: int = 10 * 60 * 1000) -> Dict[str, int]:
    """Return {user_id: max sum(amount_cents) in any time window of length window_ms}.

    Assumptions:
      - Events can arrive out of order.
      - Window is inclusive on the right, and left boundary is (t - window_ms).
        Concretely, for a right endpoint time r, we keep events with time >= r - window_ms.
      - amount_cents can be any integer, but typical pipelines expect non-negative.
    """
    per_user: Dict[str, List[Tuple[int, int]]] = defaultdict(list)
    for user_id, t_ms, amt in events:
        per_user[user_id].append((t_ms, amt))

    result: Dict[str, int] = {}

    for user_id, rows in per_user.items():
        # Sort by event time to enable a two-pointer sliding window.
        rows.sort(key=lambda x: x[0])

        left = 0
        running_sum = 0
        best = 0

        for right in range(len(rows)):
            t_r, amt_r = rows[right]
            running_sum += amt_r

            # Shrink from the left until the window satisfies time constraint.
            min_allowed = t_r - window_ms
            while left <= right and rows[left][0] < min_allowed:
                running_sum -= rows[left][1]
                left += 1

            if running_sum > best:
                best = running_sum

        result[user_id] = best

    return result


if __name__ == "__main__":
    sample = [
        ("u1", 1_000, 100),
        ("u1", 2_000, 200),
        ("u1", 700_000, 500),  # outside 10 min from earlier ones
        ("u2", 3_000, 50),
        ("u2", 4_000, 75),
        ("u2", 5_000, 25),
    ]
    print(max_10min_spend_by_user(sample))

import heapq
from collections import defaultdict
from typing import Dict, Iterable, List, Tuple

# Type: (viewer_id, story_id, view_time_ms)
View = Tuple[str, str, int]


def top_k_stories_by_unique_viewers(
    views: Iterable[View],
    now_ms: int,
    k: int,
    window_ms: int = 24 * 60 * 60 * 1000,
) -> List[Tuple[str, int]]:
    """Return list of (story_id, unique_viewer_count) sorted by count desc, story_id asc.

    Deduplication is per (viewer_id, story_id) within the 24 hour window.
    """
    if k <= 0:
        return []

    cutoff = now_ms - window_ms

    seen_pairs = set()  # (viewer_id, story_id)
    counts: Dict[str, int] = defaultdict(int)

    for viewer_id, story_id, t_ms in views:
        if t_ms < cutoff or t_ms > now_ms:
            continue
        key = (viewer_id, story_id)
        if key in seen_pairs:
            continue
        seen_pairs.add(key)
        counts[story_id] += 1

    # Keep a min-heap of size k for top-k selection.
    # Tie-breaker: story_id ascending in final output.
    heap: List[Tuple[int, str]] = []  # (count, story_id)
    for story_id, cnt in counts.items():
        item = (cnt, story_id)
        if len(heap) < k:
            heapq.heappush(heap, item)
        else:
            # Replace if strictly better, or same count but lexicographically smaller story_id.
            if item[0] > heap[0][0] or (item[0] == heap[0][0] and item[1] < heap[0][1]):
                heapq.heapreplace(heap, item)

    # heap is smallest-first, convert to required order.
    out = [(story_id, cnt) for cnt, story_id in heap]
    out.sort(key=lambda x: (-x[1], x[0]))
    return out


if __name__ == "__main__":
    now = 2_000_000
    views = [
        ("v1", "s1", now - 1_000),
        ("v1", "s1", now - 900),   # duplicate pair
        ("v2", "s1", now - 800),
        ("v1", "s2", now - 700),
        ("v3", "s2", now - 600),
        ("v4", "s3", now - 500),
    ]
    print(top_k_stories_by_unique_viewers(views, now_ms=now, k=2))

Snap's loop hits hardest where pipeline ownership bleeds into system design. You might be asked to sketch a batch-plus-streaming architecture for ad revenue reconciliation, and the interviewer will immediately probe whether your design handles late-arriving Snap Pay refunds or idempotent backfills on BigQuery fact tables. That overlap is where most candidates stall, because rehearsing each area in isolation doesn't prepare you for questions that demand both architectural reasoning and hands-on pipeline mechanics in the same breath.

The quiet trap is data modeling. Questions about grain choices for Spotlight ad revenue tables or SCD strategies for advertiser dimensions don't feel as intimidating as system design, so candidates underprepare. But Snap's interviewers care whether your model actually serves their real consumers (finance close, BI dashboards, ML feature stores), and vague answers about star schemas won't cut it.

Practice Snap-tagged questions and full solutions at datainterview.com/questions.

How to Prepare for Snap Data Engineer Interviews

The widget above covers Snap's strategic priorities and financials. What it can't tell you is how to translate that context into interview answers that feel specific rather than rehearsed. Snap's Bento platform, their modular data infrastructure, shows up repeatedly in engineering blog posts and is the kind of internal system a DE would interact with daily. Reading that writeup gives you concrete vocabulary for system design discussions: modular pipeline components, clear service boundaries, composability over monoliths.

Pair that with their post on making the most of a rewrite. Snap's engineering culture openly endorses tearing down and rebuilding systems when the architecture no longer fits, which is rare enough to be a genuine differentiator. When an interviewer asks "why Snap," referencing Bento's design philosophy or the rewrite mindset beats any answer about disappearing messages.

One more angle worth studying: Snap spun its AR glasses into Specs Inc. as a standalone subsidiary in early 2026, with data challenges around spatial intelligence and multimodal AI that look nothing like social app event streams. Even if your role sits on the core Snapchat side, showing awareness of how the company's data surface area is expanding signals you think beyond your immediate scope.

Try a Real Interview Question

| payment_events |
|----------------|

| payment_id | user_id | event_time           | ingest_time          | amount_cents | status    |
|------------|---------|----------------------|----------------------|--------------|-----------|
| p1         | u1      | 2026-02-23 23:59:00  | 2026-02-24 00:05:00  | 500          | completed |
| p2         | u2      | 2026-02-24 01:10:00  | 2026-02-24 01:12:00  | 1200         | pending   |
| p2         | u2      | 2026-02-24 03:20:00  | 2026-02-24 03:21:00  | 1200         | completed |
| p3         | u3      | 2026-02-22 12:00:00  | 2026-02-24 09:00:00  | 700          | completed |
| p4         | u4      | 2026-02-24 22:00:00  | 2026-02-25 00:10:00  | 300          | completed |

-- Write a query for run date d = '2026-02-24' that returns the payments to (re)load.
-- Output: payment_id, user_id, event_time, amount_cents, status

WITH params AS (
  SELECT
    TIMESTAMP '2026-02-24 00:00:00' AS d_start,
    TIMESTAMP '2026-02-25 00:00:00' AS d_end
), latest_per_payment AS (
  SELECT
    pe.payment_id,
    pe.user_id,
    pe.event_time,
    pe.ingest_time,
    pe.amount_cents,
    pe.status,
    ROW_NUMBER() OVER (
      PARTITION BY pe.payment_id
      ORDER BY pe.event_time DESC, pe.ingest_time DESC
    ) AS rn
  FROM payment_events pe
)
SELECT
  l.payment_id,
  l.user_id,
  l.event_time,
  l.amount_cents,
  l.status
FROM latest_per_payment l
CROSS JOIN params p
WHERE l.rn = 1
  AND (
    (l.event_time >= p.d_start AND l.event_time < p.d_end)
    OR (
      l.event_time < p.d_start
      AND l.ingest_time >= p.d_start AND l.ingest_time < p.d_end
    )
  )
ORDER BY l.payment_id;

Practicing problems like this one builds the muscle memory you'll need under time pressure. The coding round is a gate, not the centerpiece of Snap's loop, but a single bomb there ends things early. Sharpen your speed on data-oriented problems at datainterview.com/coding.

Test Your Readiness

Snap's loop includes two separate behavioral rounds, so you'll burn through stories fast. Use datainterview.com/questions to pressure-test whether your story bank is deep enough and whether your technical answers hold up to follow-up questions.