Skip to main content

Stripe

Analytics engineer at Stripe

Stripe is known for real-world, rigorous coding rather than abstract puzzles. Onsite rounds include practical implementation work and a bug-bash style round where you fix and extend a small codebase. The written-communication bar is high across every role, and system design rounds expect production realism.

Process timeline

  1. 1

    Recruiter screen

    Background and role fit.

  2. 2

    Practical coding

    Implementing real features rather than solving riddles.

  3. 3

    Bug squash

    Debugging and extending an existing codebase under time.

  4. 4

    System design

    Production-grade design with real failure handling.

  5. 5

    Behavioral

    Collaboration, judgment, and written-communication signal.

What Stripe looks for

What they value

  • Writing clean, working code in a realistic setting
  • Fast, careful debugging of unfamiliar code
  • Clear writing and reasoning under pressure

Culture signals

  • Rigor and getting the details exactly right
  • Strong written communication as a core skill
  • Caring about developers and end users of the API

Interview questions

Analytics engineer questions worth preparing alongside the Stripe rounds described above, drawn from our analytics engineer question bank.

As asked

Tell me about a data quality incident where a downstream consumer noticed before you did. What happened and what changed?

Sample answer outline

Pick a real example with measurable impact (wrong financial number in a dashboard, broken ML training set, misallocated marketing spend). Walk through detection (and the embarrassment of being told by a stakeholder), diagnosis, and remediation. The strong answer ends with structural fixes: tests at the contract boundary, freshness alerts, schema change detection, a data SLA with the consuming team. Show that you treat data quality as a system property, not a 'be more careful' exhortation.

Expect these follow-ups

  • What test would have caught this earlier?
  • How did you communicate the impact to downstream teams?
  • How do you decide what to monitor vs what to alert on?
data-qualityincidentownership

As asked

You inherit a dbt project with 200 models and no consistent structure. How would you reorganise it?

Sample answer outline

Standard layering: staging (one-to-one with source tables, light renaming and casting), intermediate (joins and reshaping, no business logic), marts (business-facing, one row per business concept). Group marts by domain (finance, marketing, product) not by source. Name models predictably: stg_, int_, fct_, dim_. Tag models for selection in CI and prod. Document at the model and column level so the warehouse is browsable. Enforce structure with project linters (dbt-project-evaluator). Migrate the existing 200 models in waves, not all at once.

Expect these follow-ups

  • How do you handle a one-off analytics question that does not fit any mart?
  • What is your testing strategy: every model or just marts?
  • When is a model worth materialising as a table vs a view?
dbtmodellingwarehouse-structure

As asked

Write SQL to find each user's first and last purchase date and the days between them. Use window functions.

Sample answer outline

Use FIRST_VALUE and LAST_VALUE partitioned by user_id, ordered by purchase_date. Be careful with the LAST_VALUE default frame, which is ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW; you need ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING to get the actual last. Alternative: MIN/MAX in an aggregation, then join back. Window function version is more flexible if you need other per-user attributes alongside.

Reference implementation (sql)

SQL
select distinct
  user_id,
  first_value(purchase_date) over (
    partition by user_id order by purchase_date
    rows between unbounded preceding and unbounded following
  ) as first_purchase,
  last_value(purchase_date) over (
    partition by user_id order by purchase_date
    rows between unbounded preceding and unbounded following
  ) as last_purchase,
  date_diff(
    last_value(purchase_date) over (
      partition by user_id order by purchase_date
      rows between unbounded preceding and unbounded following
    ),
    first_value(purchase_date) over (
      partition by user_id order by purchase_date
      rows between unbounded preceding and unbounded following
    ),
    day
  ) as days_between
from purchases;

Expect these follow-ups

  • What is the difference between RANK, DENSE_RANK, and ROW_NUMBER?
  • How would you compute a 7-day rolling sum of revenue per user?
  • When is a self-join cleaner than a window function?
sqlwindow-functions

As asked

The CFO asks: 'What was our revenue last month by product, and how does that compare to the same month last year?' Write the SQL.

Sample answer outline

Aggregate revenue by product and month from the orders fact table. Compute current month and same-month-last-year in one query with conditional aggregation, then derive the year-over-year delta. Watch for: time zone handling, refunds and chargebacks (do they count), product hierarchy (do we group at SKU or category), and the difference between booking date and recognition date. The strong answer asks one or two clarifying questions before writing the query.

Reference implementation (sql)

SQL
with monthly_revenue as (
  select
    date_trunc(order_date, month) as month,
    product_id,
    sum(net_revenue) as revenue
  from {{ ref('fct_orders') }}
  where order_date >= date_sub(current_date(), interval 13 month)
  group by 1, 2
)
select
  curr.product_id,
  curr.revenue as current_month_revenue,
  prev.revenue as same_month_last_year,
  safe_divide(curr.revenue - prev.revenue, prev.revenue) as yoy_change
from monthly_revenue curr
left join monthly_revenue prev
  on prev.product_id = curr.product_id
 and prev.month = date_sub(curr.month, interval 1 year)
where curr.month = date_trunc(date_sub(current_date(), interval 1 month), month)
order by current_month_revenue desc;

Expect these follow-ups

  • How do you handle a product that did not exist a year ago?
  • What if revenue recognition is on a multi-month schedule (subscriptions)?
  • What sanity check do you run on this number before sending it to the CFO?
sqlreportingyoy

As asked

Sales, finance, and product all have different revenue numbers in dashboards. How would you build a semantic layer that people trust?

Sample answer outline

Start by reconciling definitions with stakeholders: booked revenue, recognized revenue, net revenue, refunds, tax, and currency conversion are different metrics. Encode canonical definitions in a semantic layer or governed BI model rather than in dashboard-specific SQL. Add ownership, documentation, tests, certification status, and a change process so metric changes are deliberate. Keep enough flexibility for exploratory analysis without letting every team redefine company metrics. Strong BI engineers know this is partly technical and partly governance, because trust is lost through unclear ownership as much as bad SQL.

Expect these follow-ups

  • How do you handle a board dashboard that uses an old definition?
  • When should a metric be certified?
  • How do you stop the semantic layer becoming a bottleneck?
metricssemantic-layergovernance

As asked

Walk me through the difference between ref() and source() in dbt. When would you use one over the other, and what does dbt actually do under the hood when it resolves a ref() call?

Sample answer outline

source() points to raw tables in the warehouse that are managed outside dbt (ingested by Fivetran, Airbyte, etc.), while ref() points to dbt models within the same project or a dbt package. Under the hood, ref() resolves to the fully qualified table or view name for the current target schema and injects a dependency edge into the DAG so dbt orders execution correctly. A strong answer also mentions that source() enables freshness checks via dbt source freshness and that ref() enables cross-project references in dbt Mesh.

Expect these follow-ups

  • What happens if you use a hardcoded table name instead of ref() in a model?
  • How do source freshness checks work, and what do you configure to make them meaningful?
dbtdagsourcesreflineage

Analytics engineer interview detail at Stripe

How the Stripe loop applies to Analytics engineer candidates

Stripe is a late-stage unicorn headquartered in South San Francisco, and the same 5-stage process described above is what a analytics engineer candidate walks through, with the technical stages tuned to the data discipline. Stripe is known for real-world, rigorous coding rather than abstract puzzles. Onsite rounds include practical implementation work and a bug-bash style round where you fix and extend a small codebase. The written-communication bar is high across every role, and system design rounds expect production realism.

For a analytics engineer, the load concentrates on practical coding and system design. Those are the stages where the data signal is read most closely, so they are where preparation pays off most. The non-technical stages (recruiter screen, bug squash, and behavioral) still gate the offer, but they assess fit and communication rather than role-specific depth.

What the analytics engineer question mix signals

The 6 most-reported analytics engineer questions cluster around databases (2), role-specific (2), analytics (1). That distribution is the clearest read on what Stripe actually probes for this role: the more a topic recurs, the more reliably it shows up in the loop, so it is worth weighting practice the same way.

The set spans a easy-to-medium difficulty range, topping out at medium problems. Beyond the headline topics, the long tail touches behavioral, so a analytics engineer who only drills the top area will still hit unfamiliar ground in the onsite.

What moves a analytics engineer offer forward at Stripe

Across the loop, the traits that consistently move a Stripe analytics engineer offer forward are writing clean, working code in a realistic setting, fast, careful debugging of unfamiliar code, and clear writing and reasoning under pressure. These are not abstract values; interviewers score against them, so a analytics engineer who demonstrates them explicitly - naming the tradeoff, stating the assumption, checking the edge case out loud - reads stronger than one who only reaches the right answer silently.

The behavioral and culture stages are checking for rigor and getting the details exactly right, strong written communication as a core skill, and caring about developers and end users of the api. For a analytics engineer, the most credible way to show these is through specific, recent examples from real data work rather than rehearsed generalities.

Salary band

Use the salary page linked below for analytics engineer bands by city, modeled from BLS, ONS, and Levels.fyi reference medians.

View salary detail

Similar companies