Questions d'entretien Datadog pour software engineers

Datadog mène l'une des boucles SWE les plus orientées systèmes de la tech. Leur produit, c'est l'observabilité à l'échelle planétaire, et l'entretien le reflète. Attendez-vous à des questions pointues sur les systèmes distribués, les internes de l'OS, la concurrence et les pipelines de télémétrie — aux côtés des tours classiques de coding et de system design. L'exigence en matière de responsabilité on-call est élevée ; les tours comportementaux sondent votre gestion des incidents réels. Ce guide synthétise les rapports publics Glassdoor et les articles d'ingénierie publiés sur le blog de Datadog.

Le processus d'entretien Datadog

Les boucles SWE standard comptent 4 à 5 tours. Screen recruteur (30 minutes). Screen technique téléphonique (60 minutes, un problème de coding à saveur systèmes — par exemple « implémentez un rate limiter » plutôt que « inversez un arbre »). Onsite virtuel (4-5 tours : un coding, un system design, un deep-dive OS / concurrence, un comportemental, un hiring manager). Total : 4 à 6 semaines du screen à l'offre.

Le tour OS / concurrence est l'élément le plus distinctif. Les ingénieurs Datadog écrivent du code bas niveau qui tourne au sein de l'infrastructure des clients (le Datadog Agent) et au cœur de leurs propres pipelines de télémétrie. Attendez-vous à des questions sur l'ordonnancement des goroutines, les limites de file descriptors, les allocateurs mémoire, les cgroups, le coût des appels système (syscall overhead), ou la façon dont une structure de données précise interagit avec le runtime. Le générique « je sais utiliser une hashmap » ne suffit pas ici.

Top 10 des questions techniques à préparer

Les questions Datadog récompensent la profondeur sur quelques sujets plutôt que l'étendue sur beaucoup. Voici les patterns récurrents.

1. Implémentez un rate limiter — token bucket ou sliding window. Astuce : soyez prêt pour la variante de relance multi-processus / distribuée.
2. Construisez un agrégateur de métriques — flux d'entrée de (métrique, timestamp, valeur), sortie d'agrégats fenêtrés. Astuce : clarifiez le watermarking, les données tardives et les bornes mémoire.
3. Cache LRU thread-safe — stratégies de verrouillage, fine-grained vs coarse-grained. Astuce : expliquez pourquoi un seul mutex convient à de nombreuses charges malgré la sagesse conventionnelle qui le déconseille.
4. Producteur/consommateur avec file bornée — variables de condition ou channels. Astuce : répétez les arguments de correction pour le pattern wait/signal.
5. Top-K en streaming — count-min sketch ou algorithme heavy hitters. Astuce : soyez prêt à discuter explicitement de l'arbitrage précision/mémoire.
6. Parseur de lignes de log avec performance regex — gérez les entrées malformées avec élégance. Astuce : expliquez quand la regex compte et quand une machine à états est plus rapide.
7. Gestion des file descriptors — ce qui se passe quand vous les épuisez, comment l'éviter. Astuce : reliez-le à une vraie expérience on-call si vous en avez une.
8. Compteur distribué — cohérence à terme, anti-entropie, sharding. Astuce : discutez de l'arbitrage CAP en termes concrets, pas abstraitement.
9. Implémentez un stockage time-series basique — chemin d'écriture, chemin de lecture, downsampling. Astuce : discutez explicitement de l'asymétrie lecture/écriture.
10. Détectez des anomalies dans un flux — statistiques glissantes, z-score, EWMA. Astuce : répétez les formules ; vous devrez les écrire.

Top 5 des sujets de system design

1. Pipeline d'ingestion de métriques à grande échelle — milliards de points par seconde, partitionnement, gestion des hot-tags.
2. Système de distributed tracing — collecte des spans, décisions d'échantillonnage, sampling head-based vs tail-based.
3. Moteur d'alerting — évaluation des règles, déduplication, escalade, anti-flap.
4. Agrégation et recherche de logs — ingestion, indexation, requête, paliers de rétention.
5. Design de l'agent — collecte de metrics/logs/traces depuis un host client, batch, expédition, gestion des coupures réseau et de la backpressure.

Les tours de system design Datadog attendent que vous pensiez au coût. Leur activité est facturée à l'usage : les clients paient au host, à la métrique, au million d'événements. Les designs qui ignorent l'économie unitaire sous-performent. « On mettrait en cache les agrégats parce que tout recalculer à chaque requête multiplierait par 10 notre facture de compute » passe bien.

Top 5 des questions comportementales

1. Décrivez-moi un incident de production que vous avez géré. Incident précis, votre rôle, la communication, la cause racine, le suivi.
2. Parlez-moi d'une fois où vous avez amélioré la qualité de l'on-call de votre équipe. Changement concret, impact mesurable sur les alertes ou le MTTR.
3. Décrivez une session de debug qui a pris plus de temps que prévu. Le signal, c'est votre capacité à rester structuré face à l'incertitude.
4. Comment équilibrez-vous la livraison de nouvelles fonctionnalités et l'investissement dans le tooling et la fiabilité ? Une histoire précise où vous avez fait l'arbitrage.
5. Parlez-moi d'une fois où vous avez porté un système du design jusqu'à la maintenance à long terme. L'arc de maintenance compte autant que le lancement.

Conseils propres à la culture Datadog

Les ingénieurs Datadog sont on-call. La culture traite l'on-call comme une responsabilité, pas une punition. À chaque tour comportemental, trouvez un moyen de montrer que vous avez été on-call et que vous le prenez au sérieux. Les histoires sur le nettoyage d'alertes bruyantes, l'écriture de runbooks ou l'amélioration du MTTR passent toutes bien. Dire « je n'ai pas beaucoup été on-call » est honnête mais coûteux — si réellement vous ne l'avez pas été, articulez au moins comment vous l'aborderiez.

La conscience des coûts est un vrai signal culturel. Les ingénieurs Datadog pensent au volume de télémétrie, à la rétention du stockage, au coût en latence des requêtes. Mentionner des arbitrages de coûts explicites dans les tours de system design (« on plafonnerait la cardinalité à 100 par tenant parce que des tags incontrôlés font exploser la taille de notre index ») passe bien mieux que de les ignorer. C'est le signal senior le moins répété chez Datadog.

Les clients font tourner Datadog au cœur de leur infrastructure critique. La fiabilité est le produit. Les ingénieurs capables d'articuler « ce qui se passe quand notre service est dégradé » s'en sortent mieux que ceux qui ne conçoivent que pour le happy path. Faites ressortir proactivement les modes de défaillance, la dégradation gracieuse et la gestion de la backpressure dans les tours de design.

Questions fréquentes