How Datadog interviews — Question to Offer

1. The shape of a Datadog loop

Datadog's loop is shorter than the FAANG average and heavier on raw systems depth. A typical onsite is four rounds: two system design, one coding, one behavioral with a hiring manager. Each round runs 60 minutes. The system design rounds are the ones that decide the offer.

The company is headquartered in New York with a strong satellite engineering presence in Paris. The French engineering heritage shows up in the interviewing style — interviewers are direct, technical, and won't soften the pushback. If your answer is hand-wavy they'll say so in the room.

Levels run roughly L4 to L6 in their internal terminology (titles vary: Software Engineer, Senior, Staff). L4 expects you to design one component well. L5 expects a full system with at least one defended deep dive. L6 expects you to talk about the product surface, the storage layout, and the operational story as one connected thing.

2. What Datadog grades you on

Datadog is an observability company, which means every system they build sits behind the same constraint: extreme write throughput, queries against time-windowed data, customer-facing SLAs on freshness and availability. The design questions reflect that.

Three signals dominate:

Can you reason about write-heavy systems? Most candidates have practiced read-heavy designs (feed, search). Datadog asks the opposite. Millions of metric points per second, petabytes of logs per day. If your instinct is "we'll put it in Postgres," you're done.
Do you understand storage layouts for time-series data? Time-series workloads have a shape — appends ordered by time, queries over time ranges, downsampling for long retention. The right primitives are different from a generic KV.
Can you talk about multi-tenancy at platform scale? Every Datadog system serves thousands of customers from the same fleet. Tenant isolation, fair-share scheduling, per-customer rate limits. Skip this and the interviewer notices.

Hire-strong means you reach for the write-side primitives early — append-only logs, columnar storage, sharded ingest pipelines — and you frame the query path as the secondary problem.

3. What's different here

The bar on storage depth is high. Datadog engineers ship custom storage engines. Interviewers expect you to know the difference between LSM and B-tree at the seven-line depth, name compression schemes for time-series (delta encoding, Gorilla, double-delta), and explain why a column store beats a row store for analytical queries.
Cost shows up as a first-class constraint. At petabyte ingest, storage cost is the product. Hot/warm/cold tiering, retention policies, downsampling for older data — these are not optimizations, they're the design. If you propose keeping a year of raw log data at high resolution, you've failed the round.
The interviewer is often a hands-on engineer. Not a generalist running interviews from a script. They've built the system they're asking about. Vague answers fail fast because they can tell.
French and American interviewing styles mix. New York interviewers tend to be more relationship-driven in the behavioral; Paris interviewers tend to push harder on technical detail. The system design rounds feel similar from either office.
The product surface is the test scenario. Datadog asks you to design their products — TSDB, log search, APM, alerting. You should know what each product does before walking in. Spend 30 minutes on docs.datadoghq.com.

4. The level bar

L4 (engineer) — design one component competently. Throughput estimation expected. One deep dive that survives one push.
L5 (senior engineer) — design the full system with at least one deep dive that survives three pushes. Cost analysis on the storage tier. Multi-tenancy named in the requirements.
L6 (staff engineer) — design the system as a product surface. Migration story from a hypothetical predecessor. Operational considerations named: what the on-call sees, what the alarms are, what the SLA breach looks like. Tradeoffs framed in customer-impact terms.

The seven scenario units in this chapter target L5 by default with explicit notes on what shifts at L6.

5. The Datadog-flavored mistakes

Designing for read-heavy load. The instinct from generic system design practice is to optimize the read path. At Datadog, the write path is the constraint. Most queries hit a small slice of recent data; the cost is in the ingest pipeline and the storage footprint.
Picking Postgres for the storage layer. A row-oriented OLTP database is wrong for every Datadog product. The right answers are columnar (for analytics), time-partitioned wide-column (for metrics), append-only log segments (for logs). Naming Postgres signals you haven't worked with this shape of data.
Ignoring downsampling. A year of raw 1-second metric data is several orders of magnitude more storage than a year of 1-hour aggregates. The downsampling pipeline is half the system. Candidates who don't mention it lose the round.
Treating logs and metrics as the same problem. They share infrastructure shapes but the access patterns are different. Metrics are queried by time range and aggregation. Logs are queried by full-text search or filter. Different indexes, different storage layouts.
Forgetting the customer. Datadog sells to engineers. The product surface is the dashboard. If you can't tie your storage layout back to "the customer opens a dashboard and sees a graph in under 200ms," you're designing in a vacuum.

6. The seven scenarios in this chapter

22.1 Time-series DB for metrics — the foundational product. Write-heavy, compressed, time-partitioned.
22.2 Log ingestion at petabyte scale — schema-on-read, hot/cold tiering, multi-tenancy.
22.3 Distributed trace correlation — stitching spans by trace ID, sampling strategies.
22.4 Real-time alerting and dedup — continuous evaluation, notification fan-out, deduplication.
22.5 Synthetic monitoring and RUM — probes from global locations, browser-side telemetry.
22.6 APM service dependency map — deriving a service graph from trace data.
22.7 Take-home: TSDB with multi-resolution downsampling — design doc, 4 to 8 hours.

7. The next page

The first scenario: a time-series database for metrics. The foundational product Datadog was built on, and the question that decides whether you make it past the first round.