Datadog Interviewfragen für Software Engineers

Datadog betreibt einen der systemlastigsten SWE-Loops der Tech-Branche. Ihr Produkt ist Observability im planetaren Maßstab, und das Interview spiegelt das wider. Rechnen Sie mit tiefgehenden Fragen zu verteilten Systemen, OS-Internals, Concurrency und Telemetrie-Pipelines — neben konventionellen Coding- und System-Design-Runden. Die Latte für On-Call-Ownership ist hoch; Behavioral-Runden ergründen, wie Sie mit echten Incidents umgehen. Dieser Leitfaden fasst öffentliche Glassdoor-Berichte und Datadogs veröffentlichte Engineering-Blogposts zusammen.

Der Datadog-Interviewprozess

Standard-SWE-Loops haben 4–5 Runden. Recruiter-Screening (30 Minuten). Technisches Telefon-Screening (60 Minuten, ein Coding-Problem mit System-Einschlag — z. B. "implementiere einen Rate Limiter" statt "kehre einen Baum um"). Virtuelles Onsite (4–5 Runden: eine Coding-Runde, eine System-Design-Runde, ein OS-/Concurrency-Deep-Dive, eine Behavioral-Runde, eine Hiring-Manager-Runde). Insgesamt: 4–6 Wochen vom Screening bis zum Angebot.

Die OS-/Concurrency-Runde ist das markanteste Element. Datadog-Engineers schreiben Low-Level-Code, der innerhalb der Kundeninfrastruktur läuft (der Datadog Agent) und in ihren eigenen Telemetrie-Pipelines. Rechnen Sie mit Fragen zu Goroutine-Scheduling, File-Descriptor-Limits, Memory-Allocators, cgroups, Syscall-Overhead oder dazu, wie eine bestimmte Datenstruktur mit der Runtime interagiert. Ein generisches "Ich weiß, wie man eine Hashmap benutzt" landet hier nicht.

Die 10 wichtigsten technischen Fragen zur Vorbereitung

Datadog-Fragen belohnen Tiefe in wenigen Themen statt Breite über viele. Das sind die wiederkehrenden Muster.

1. Implementieren Sie einen Rate Limiter — Token Bucket oder Sliding Window. Tipp: Seien Sie auf die Follow-up-Variante für Multi-Process / verteilt vorbereitet.
2. Bauen Sie einen Metrics-Aggregator — Input-Stream aus (Metrik, Timestamp, Wert), Output gefensterte Aggregate. Tipp: Klären Sie Watermarking, verspätete Daten und Memory-Grenzen.
3. LRU-Cache mit Thread-Sicherheit — Locking-Strategien, fein- vs. grobgranular. Tipp: Diskutieren Sie, warum ein einzelner Mutex für viele Workloads in Ordnung ist, entgegen der gängigen Lehrmeinung.
4. Bounded Queue Producer/Consumer — Condition Variables oder Channels. Tipp: Üben Sie Korrektheitsargumente für das Wait/Signal-Muster.
5. Top-K-Streaming — Count-Min-Sketch oder Heavy-Hitters-Algorithmus. Tipp: Seien Sie bereit, den Genauigkeits-/Memory-Tradeoff ausdrücklich zu diskutieren.
6. Log-Line-Parser mit Regex-Performance — fehlerhafte Eingaben souverän handhaben. Tipp: Diskutieren Sie, wann Regex wichtig ist und wann eine State Machine schneller ist.
7. File-Descriptor-Management — was passiert, wenn Sie sie erschöpfen, und wie man das verhindert. Tipp: Knüpfen Sie an echte On-Call-Erfahrung an, falls vorhanden.
8. Verteilter Counter — eventual consistency, Anti-Entropy, Sharding. Tipp: Diskutieren Sie den CAP-Tradeoff konkret, nicht abstrakt.
9. Implementieren Sie einen einfachen Time-Series-Speicher — Write Path, Read Path, Downsampling. Tipp: Diskutieren Sie die Read-/Write-Asymmetrie ausdrücklich.
10. Erkennen Sie Anomalien in einem Stream — Rolling Stats, z-Score, EWMA. Tipp: Üben Sie die Formeln; Sie werden sie ausschreiben müssen.

Die 5 wichtigsten System-Design-Themen

1. Metrics-Ingestion-Pipeline bei Skalierung — Milliarden Punkte pro Sekunde, Partitionierung, Hot-Tag-Handling.
2. Distributed-Tracing-System — Span-Sammlung, Sampling-Entscheidungen, Head-based vs. Tail-based Sampling.
3. Alerting-Engine — Regelauswertung, Deduplizierung, Eskalation, Anti-Flap.
4. Log-Aggregation und -Suche — Ingestion, Indexierung, Query, Retention-Tiers.
5. Agent-Design — Metrics/Logs/Traces von einem Kunden-Host sammeln, batchen, ausliefern, Netzwerk-Aussetzer und Backpressure handhaben.

Datadogs System-Design-Runden erwarten, dass Sie an Kosten denken. Ihr Geschäft ist nutzungsbasiert: Kunden zahlen pro Host, pro Metrik, pro Million Events. Designs, die Stückkosten ignorieren, schneiden schlechter ab. "Wir würden Aggregate cachen, weil Neuberechnung bei jeder Query unsere Compute-Rechnung verzehnfachen würde" landet gut.

Die 5 wichtigsten Behavioral-Fragen

1. Führen Sie mich durch einen Production-Incident, den Sie bewältigt haben. Konkreter Incident, Ihre Rolle, Kommunikation, Root Cause, Follow-up.
2. Erzählen Sie von einer Situation, in der Sie die On-Call-Qualität für Ihr Team verbessert haben. Konkrete Änderung, messbarer Effekt auf Alerts oder MTTR.
3. Beschreiben Sie eine Debugging-Session, die länger dauerte als erwartet. Das Signal ist, wie Sie unter Unsicherheit strukturiert geblieben sind.
4. Wie balancieren Sie das Ausliefern neuer Features gegen Investitionen in Tooling und Reliability? Konkrete Geschichte, in der Sie den Tradeoff getroffen haben.
5. Erzählen Sie von einer Situation, in der Sie ein System vom Design über die langfristige Wartung verantwortet haben. Der Wartungsbogen zählt genauso viel wie der Launch.

Tipps speziell zur Kultur von Datadog

Datadog-Engineers sind On-Call. Die Kultur behandelt On-Call als Ownership, nicht als Strafe. Finden Sie in jeder Behavioral-Runde einen Weg, sichtbar zu machen, dass Sie On-Call waren und es ernst nehmen. Geschichten über das Aufräumen lauter Alerts, das Schreiben von Runbooks oder die Verbesserung der MTTR landen alle gut. Zu sagen "Ich war nicht viel On-Call" ist ehrlich, aber teuer — wenn Sie es wirklich nicht waren, benennen Sie zumindest, wie Sie darüber nachdenken würden.

Kostenbewusstsein ist ein echtes kulturelles Signal. Datadog-Engineers denken über Telemetrie-Volumen, Storage-Retention und Query-Latenz-Kosten nach. Ausdrückliche Kosten-Tradeoffs in System-Design-Runden zu nennen ("wir würden die Cardinality auf 100 pro Tenant deckeln, weil unkontrollierte Tags unsere Index-Größe sprengen") landet deutlich besser, als sie zu ignorieren. Das ist das am wenigsten geübte Senior-Signal bei Datadog.

Kunden betreiben Datadog innerhalb ihrer kritischen Infrastruktur. Reliability ist das Produkt. Engineers, die benennen können "was passiert, wenn unser Dienst degradiert ist", landen besser als Engineers, die nur für den Happy Path designen. Bringen Sie Failure Modes, Graceful Degradation und Backpressure-Handling in Design-Runden proaktiv zur Sprache.

Häufig gestellte Fragen