Slack · Primly Community

Slack data engineer interview, pipelines and SQL, here's what they actually test

analyst_ana (Primly starter) · 6 replies

Did the Slack data engineer interview loop last quarter. Specifically for the data infrastructure team. Writing this up because the data eng interview content online for Slack is thin and most of what exists is stale.

Five rounds total. The breakdown:

SQL/Data Modeling (45 min). Hardest technical round for me. Not CRUD queries. They wanted: schema design for an event-sourced system (given a set of Slack-like events, design a data model), then write queries against that schema. Window functions, nested aggregations, performance considerations. They specifically asked why I'd choose a particular partitioning strategy on a large events table. The answer they want involves thinking about query patterns, not just storage.

Data Pipeline Design (60 min). Describe an end-to-end pipeline for ingesting, processing, and serving a high-volume event stream. They asked about: batch vs. streaming tradeoffs for different use cases, late-arriving data handling, idempotency in pipeline steps, backfill strategy. Slack uses Kafka, Spark, and Airflow internally (this is somewhat public knowledge from their eng blog). Knowing those won't get you a pass but not knowing them will get you a fail.

Coding (45 min). Python or Scala. I did Python. A data manipulation problem: given a set of records with some cleaning requirements, write transformation logic. Felt more like the kind of code a DE would actually write in a job than a leetcode medium.

Systems/Scalability (45 min). Overlap with the pipeline round but more focused on infra choices. How do you design storage for time-series event data at petabyte scale? What are the tradeoffs between columnar storage (Parquet/ORC) and row-based? When does a data lake beat a data warehouse?

Behavioral (45 min). Standard. Cross-team work, project failures, technical ownership.

Total time: about 4.5 hours of interviews. Prep accordingly. The SQL and pipeline rounds are where candidates get cut.

6 replies

analyst_ana (Primly starter)

The partition strategy question is one I always stumble on because I can talk about partitioning but not always articulate why for a specific query pattern. Any resources you found useful for that depth?

de_derek (Primly starter)

Honestly just building things in practice. But for interview prep: the Databricks blog has good write-ups on Delta Lake and Z-ordering that get into this. Fundamentals of Data Engineering (the O'Reilly book) covers partition strategy in context too.

marketer_mei (Primly starter)

Late-arriving data handling is such a classic DE interview topic and it's genuinely hard to handle well in production. Did they want a specific solution (watermarks, bounded late arrival windows) or just wanted to see you knew the problem existed?

de_derek (Primly starter)

Mostly wanted to see I understood the tradeoffs. I talked about event-time vs. processing-time, watermark strategies in Flink/Spark Streaming, and when you just accept the data loss and move on. They seemed happy with that framing. No one right answer.

pivot_pat (Primly starter)

The SQL rounds at Slack are no joke whether you're going for DS or DE. The level of expectation on window functions and schema design is noticeably above average.

Primly Team

One stage candidates often underestimate in DE loops like this is framing and scoping before solving. When the prompt is “design an event-sourced schema” or “build an end-to-end pipeline,” the fastest way to stand out is to spend the first 2 to 3 minutes clarifying: primary query patterns, freshness SLA, expected cardinalities, and the top failure modes you are optimizing for.

A useful structure is: (1) list the consumers and their questions, (2) propose the minimal set of entities and keys, (3) call out grain and dedupe strategy explicitly, (4) only then talk partitions, clustering, and backfills. A common failure mode is jumping straight to tools or “streaming vs batch” opinions without stating how you will guarantee correctness under retries, late events, and schema evolution.

What’s one clarification question you’ve found reliably changes the direction of a data modeling or pipeline design interview?