Site Reliability Engineer at Datadog: Roles, Interviews, and Compensation in 2026

SRE at Datadog in 2026: vendor scale

Datadog was founded in 2010 by Olivier Pomel and Alexis Le-Quoc and shipped its first metrics product in 2012. By 2026 it is the dominant third-party observability vendor, ingesting metrics, distributed traces, logs, real-user-monitoring events, synthetic checks, and security signals from hundreds of thousands of customer environments. The ingestion side runs to trillions of data points per day, and the read side fans those out into dashboards, alerts, and ad-hoc queries that engineers expect to return in seconds.

SREs at Datadog sit at the intersection of two reliability problems. The first is keeping Datadog itself up: a missed scrape on the Datadog side is a missed alert for a customer, so internal SLOs are tighter than what most SaaS companies live with. The second is operating infrastructure at vendor scale - the storage layer for a single large enterprise customer can dwarf the entire observability footprint of a mid-size company, and Datadog runs hundreds of those tenants on shared multi-region clusters.

The SRE org splits across core platform (Kubernetes, service mesh, deployment tooling), data infrastructure (Cassandra clusters, Kafka pipelines, Spark batch jobs, custom time-series stores), ingestion and intake (agents, gateways, pipelines that absorb customer telemetry), and product reliability (embedded SREs paired with metrics, APM, logs, RUM, and security teams).

Datadog operates as a hybrid company with twin headquarters in New York City and Paris. Most engineering ICs work from one of those hubs three days per week, with additional offices in Boston, Dublin, and Tokyo and remote allowed for some senior roles. Datadog has been public on NASDAQ under the ticker DDOG since the September 2019 IPO, which puts equity grants on a transparent quarterly vesting and liquidity path.

Interview process

The Datadog SRE loop runs five to six rounds and takes three to five weeks end to end. The structure is consistent across core platform, data infrastructure, and embedded product SRE teams, with the systems-debugging round weighted heavily for senior candidates and a coding bar that favors clean, correct, debuggable code over algorithmic puzzles.

1. Recruiter screen - role fit, hub location (NYC, Paris, Boston, Dublin, Tokyo, or remote), comp expectations, and a quick read on production experience, on-call exposure, and language fluency.
2. Technical phone screen - one coding problem (Python and Go are most common; Rust is fine for storage and intake teams) plus a short discussion of Linux fundamentals: signals, file descriptors, the memory hierarchy, and how a single request flows through a typical service.
3. Coding round - a medium problem with a concurrency, I/O, or data-structure twist; expect to discuss correctness under failure and observability of your own code, not just complexity.
4. Systems debugging - a live or take-home scenario where a service is misbehaving and you have access to logs, metrics, and a shell. The interviewer is looking for a structured hypothesis-and-test loop: read the symptoms, form a hypothesis, gather evidence, narrow the search. Tools like strace, perf, eBPF, tcpdump, and the Datadog product itself come up.
5. System design - design an observability or infrastructure system at scale. Time-series storage, sharding strategy, Cassandra repair semantics, Kafka partition layout, multi-region replication, and back-pressure under ingestion spikes are fair game.
6. Hiring manager and values - ownership, customer obsession (Datadog leans hard on this), how you handle ambiguity on a fast-moving distributed system, and how you handle a real on-call incident from start to postmortem.

Bar-raisers look for depth on Linux internals (page cache, schedulers, cgroups, namespaces), a clear mental model of how Cassandra and Kafka behave under partition (quorum reads, hinted handoffs, ISR shrinkage, consumer-group rebalances), and a real on-call story with specifics: alert fired, hypothesis path, mitigation, and what was changed afterwards. Open-source contributions to the Datadog Agent, Cassandra, Kafka, or major Kubernetes projects are noticed at screening.

Compensation by level

Compensation at Datadog is a balanced mix of base, equity, and bonus, and the September 2019 IPO means RSU grants vest into liquid DDOG shares on a transparent quarterly schedule. Levels.fyi data for US-based SREs and software engineers at Datadog shows the following ranges as of early 2026.

Production Engineers and embedded product-SRE roles are paid on the same IC ladder as core SRE. Paris offers typically land at 55-70 percent of New York numbers in euros, and Dublin and Tokyo numbers fall in similar bands relative to local market. New York is the most active hiring hub by headcount, with Paris a close second for storage, ingestion, and data-infrastructure SRE roles given the original Paris engineering office.

Tech stack: Apache Cassandra + Kafka + Spark + custom time-series stores + Kubernetes

Datadog SREs work on a stack that is open at the edges (Cassandra, Kafka, Spark, Kubernetes) and proprietary at the center (the custom time-series stores that hold the metric data). Most skills transfer directly to any organization that runs metrics or telemetry at vendor-grade volume.

• Apache Cassandra - the workhorse for metadata, indexing, and tag-cardinality workloads. SREs operate clusters in the hundreds-to-thousands of nodes across multiple regions. Expect to know read and write paths, repair (incremental and full), compaction strategies (size-tiered, leveled, time-window), tombstone hazards, and how quorum reads behave under partition.
• Apache Kafka - the durable bus that absorbs telemetry from agents and gateways and fans it out to stream-processing and storage layers. Partition layout, ISR (in-sync replicas) management, tiered storage, and consumer-group rebalancing under load are operational table stakes; topics commonly run tens-of-thousands of partitions per cluster.
• Apache Spark - used for batch backfills, tag-cardinality analysis, billing reconciliation, and offline analytics on telemetry landed in object storage. Spark on Kubernetes is the deployment model SRE supports.
• Custom time-series stores - the metric storage layer is built in-house, primarily in Go and Rust, optimized for high-cardinality ingestion, range queries, and rollup hierarchies that downsample older data automatically. SREs work with storage engineers on capacity planning, hot-shard mitigation, and failure modes that surface only at trillion-point-per-day volume.
• Kubernetes - the universal compute substrate. Datadog runs its own large multi-region clusters and ships a Helm chart and Operator for customers. SREs are expected to be fluent in scheduler behavior, control-plane scaling, etcd operation, networking (CNI plugins, kube-proxy modes, service mesh), and node-level Linux work (kubelet, containerd, cgroups v2).
• Languages - Go is dominant in the Datadog agent and most platform tooling; Python is common for control-plane services and automation; Rust is used in high-performance ingestion and storage paths; some legacy services remain in Java.
• Observability tooling - Datadog SREs eat their own dog food. The internal monitoring stack runs on the same product customers use, which is a forcing function for product quality. Expect fluency with Datadog APM, Logs, Metrics, and Watchdog, plus Linux-native tooling (perf, bpftrace, eBPF, tcpdump, strace) for cases where the product cannot see deep enough.

Resumes that name specific systems and quantify scale (clusters managed, nodes per cluster, ingestion rate, query p99, on-call rotation size, incidents owned end-to-end) read better than generic 'operated cloud infrastructure' bullets.