← Datadog Interview Insights

Datadog·Machine Learning Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say
May 2026Remote

Summary

Datadog ML engineer interview that went deep into monitoring system design, specifically around alerting pipelines for web server latency. The question was meaty and I don't think I fully nailed the on-call policy portion, but the technical detection side felt okay.

Questions Asked (1)

Q1

Design a pipeline to monitor latency across dozens of web servers (each reporting average response time per second), including algorithms to detect degraded performance and a paging policy for on-call engineers that handles ack, snooze, and re-page intervals to reduce alert fatigue without missing real regressions.

System DesignTechnical Trade-offsProduct Analytics & Metrics
Author's notes

This is basically two questions stitched together and I treated them separately which I think hurt me.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a data pipeline that ingests per-second metrics from dozens of servers, computes robust baselines, and applies anomaly detection algorithms. Finally, define a paging policy with ack, snooze, and re-page intervals that balances alert fatigue and regression detection, and discuss trade-offs.

Pro tip: Emphasize that alerting should be based on sustained deviations and use techniques like EWMA or change point detection to avoid false positives from transient spikes. Also, mention that the paging policy should include escalation and auto-resolution to further reduce noise.

1. Clarify Requirements and Scale

Ask questions to understand the number of servers, expected latency patterns, acceptable false positive/negative rates, and on-call expectations. This ensures the design meets business needs.

2. Design Data Pipeline

Outline a pipeline that collects per-second average latency from each server, aggregates them (e.g., per service or globally), and stores time-series data for analysis. Consider using a stream processor for real-time detection.

3. Choose Detection Algorithms

Select algorithms to detect degraded performance, such as statistical process control (e.g., EWMA, CUSUM), change point detection, or ML-based anomaly detection. Discuss how to set thresholds dynamically based on historical data.

4. Define Paging Policy

Specify the alerting workflow: when an anomaly is detected, page the on-call engineer. Include ack (acknowledge), snooze (temporarily silence), and re-page intervals (e.g., re-alert if not acked within X minutes). Define escalation paths and auto-resolution.

5. Discuss Trade-offs and Iteration

Address trade-offs between sensitivity and alert fatigue, and how to tune parameters. Mention the importance of feedback loops and continuous improvement.

Key Points to Mention

  • Use of robust baselines (e.g., median, trimmed mean) to handle outliers and seasonal patterns.
  • Algorithms: EWMA, CUSUM, change point detection, or ML models for anomaly detection.
  • Alert grouping and deduplication to reduce noise from multiple servers.
  • Paging policy details: ack timeout, snooze duration, re-page interval, escalation, and auto-resolution.
  • Trade-offs: balancing false positives vs. false negatives, and how to tune thresholds.
  • Integration with existing monitoring tools (e.g., Datadog) and feedback mechanisms.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.