Entretien data engineer chez OpenAI : processus et préparation

Vous avez reçu un e-mail d'un recruteur d'OpenAI et vous voulez savoir ce qui vous attend avant d'accepter un calendrier. Cette section présente ce qu'OpenAI affirme lui-même sur son processus, puis les étapes que contient habituellement une boucle d'entretiens en ingénierie des données. Considérez les faits publiés comme des points fixes et tout le reste comme de la préparation.

OpenAI publie un guide d'entretien général plutôt qu'une description poste par poste, et ne publie pas de boucle distincte pour les data engineers. Ce qu'il indique s'applique à l'ensemble de ses recrutements :

• Examen du CV. L'équipe de recrutement met généralement une semaine à examiner un CV et à répondre.
• Décisions après chaque étape. Les candidats sont informés dans la semaine qui suit chaque étape de la suite donnée à leur candidature.
• Entretiens finaux. Les candidats passent généralement 4-6 heures en entretiens finaux avec 4-6 personnes sur 1-2 jours.
• Format. Les entretiens se font à distance par défaut, et les candidats peuvent choisir de venir dans les bureaux de San Francisco.
• Décision finale. Les candidats doivent s'attendre à une réponse dans la semaine suivant leurs entretiens finaux.

OpenAI ne publie pas le nombre d'entretiens qui précèdent les entretiens finaux pour un data engineer, ni leur nom, ni leur ordre. Votre recruteur est la source fiable : demandez quels sujets chaque conversation couvre et si une partie autorise les outils d'IA.

Pour vous organiser, les étapes ci-dessous sont des catégories de préparation générales pour les postes d'ingénierie des données dans les grandes entreprises technologiques, et non les noms des tours d'OpenAI :

• Échange avec le recruteur. Parcours, motivation, équipe, et logistique comme des finales à distance ou sur place.
• Entretien technique. Généralement du SQL et un peu de code, souvent avec des questions sur un pipeline que vous avez exploité en production.
• Échange avec le responsable du recrutement. Les systèmes que vous avez construits, l'ampleur et le désordre des données traitées, et les compromis consentis.
• Entretiens finaux. Code plus approfondi, modélisation de données, conception de pipelines ou de systèmes, et entretiens comportementaux, répartis entre les 4-6 personnes décrites par OpenAI.

Des messages sur Reddit, Glassdoor et des forums similaires décrivent en détail des boucles individuelles. Chacun reflète un candidat, dans une équipe, à un moment donné : servez-vous-en pour mesurer l'éventail des sujets, pas comme d'un calendrier.

Pour les entretiens d'ingénierie, OpenAI dit chercher en général des solutions bien conçues, du code de haute qualité, des performances optimales et une bonne couverture de tests. Ces critères sont écrits pour les ingénieurs en général, mais ils correspondent étroitement au travail sur les données. Les questions d'exemple de cette page sont des sujets d'entraînement, pas des questions qu'OpenAI a confirmé poser.

• Solutions bien conçues : modélisation et conception de pipelines. Choisir la granularité d'une table, séparer faits et dimensions, arbitrer entre batch et streaming, et prévoir les rechargements, les données tardives et les changements de schéma. Une conception qui résiste à l'évolution des besoins est bien conçue ; celle qui ne convient qu'à l'énoncé initial ne l'est pas.
• Code de haute qualité : du Python et du SQL que vous mettriez en production. Des noms clairs, de petites fonctions, une gestion explicite des valeurs nulles et des enregistrements malformés, et des jointures que vous pouvez justifier. Les intervieweurs veulent généralement savoir si vous pouvez expliquer pourquoi une requête est correcte, pas seulement si elle s'exécute.
• Performances optimales : coût et échelle. Partitionnement, éviter les lectures complètes, réduire les shuffles dans les jobs distribués, et savoir quand une réponse approximative est acceptable. Dites où se trouve le goulot d'étranglement avant de proposer un correctif.
• Bonne couverture de tests : la qualité des données comme test. Pour un data engineer, cela signifie des tests unitaires pour les transformations et des contrôles sur les données elles-mêmes : nombre de lignes attendu, clés uniques, fraîcheur, et alertes quand une source change de forme.
• Jugement comportemental. La responsabilité d'une panne de pipeline, les désaccords sur la définition d'une métrique, et la façon dont vous avez décidé de ce qu'il ne fallait pas construire.

OpenAI précise aussi que les attentes concernant l'IA et les autres outils varient selon l'entretien. Certains formats les autorisent volontairement, d'autres sont conçus pour évaluer la résolution de problèmes en autonomie, sans outils d'IA. Dans un format assisté, la compétence évaluée est la façon dont vous dirigez, vérifiez et corrigez la sortie de l'outil ; dans un format sans outil, vous produisez vous-même le SQL et le code. Suivez les règles de chaque intervieweur et posez la question quand elles ne sont pas claires. D'autres exercices classés par compétence se trouvent dans les banques de questions.

OpenAI ne publie pas de différences poste par poste ; la comparaison ci-dessous relève donc de la pratique générale en ingénierie des données et ne dit rien des autres boucles d'OpenAI.

• Par rapport à l'ingénierie logicielle. Moins de poids pour les casse-têtes algorithmiques, plus pour le SQL, la modélisation et la fiabilité des pipelines. Les questions de conception portent plutôt sur la façon dont les données circulent, atterrissent et sont corrigées que sur des services qui répondent à des requêtes. Les critères d'ingénierie qu'OpenAI cite s'appliquent toujours : la qualité du code et les tests comptent autant que dans n'importe quelle boucle d'ingénierie.
• Par rapport à la data science. Moins de statistiques et de conception d'expériences, davantage de construction des tables dont dépendent analystes et chercheurs. On peut tout de même vous demander comment une métrique est définie, car un data engineer est souvent responsable de la table qui la porte.
• Par rapport à l'analytics engineering. La frontière est floue. Les postes d'analytics penchent plutôt vers la modélisation et le SQL pour le reporting, tandis que ceux de data engineer vont plus loin dans l'ingestion, le traitement distribué et l'infrastructure.

Comparé à d'autres grandes entreprises, le processus publié par OpenAI présente des particularités dont il faut tenir compte. Les finales sont concentrées sur 1-2 jours : l'endurance compte, car votre dernier entretien de la journée est examiné avec la même rigueur que le premier. La politique sur les outils change d'un entretien à l'autre : renseignez-vous avant chaque séance au lieu de la supposer. Enfin, l'engagement de répondre dans la semaine qui suit chaque étape vous permet de planifier d'autres entretiens et offres avec plus d'assurance. Des guides sur la façon dont d'autres entreprises structurent leurs boucles se trouvent dans entretiens en entreprise.

OpenAI publie quelques précisions sur les délais, mais pas un calendrier complet. L'équipe de recrutement répond généralement à un CV sous une semaine, les candidats sont informés dans la semaine qui suit chaque étape, et la décision finale arrive en général dans la semaine suivant les entretiens finaux. Les finales elles-mêmes durent généralement 4-6 heures avec 4-6 personnes sur 1-2 jours.

Ce qu'OpenAI ne publie pas, c'est le nombre d'étapes qu'un data engineer franchit avant les finales ; la durée totale d'un processus ne peut donc pas se déduire du seul guide. Demandez à votre recruteur combien d'échanges prévoir et organisez votre préavis et vos autres entretiens en fonction de sa réponse.

La difficulté se décrit plus facilement en termes qualitatifs. Chaque étape est un filtre, puisque vous apprenez après chacune si vous avancez : un mauvais entretien technique met fin au processus avant toute discussion de conception. Le plus dur, pour la plupart des candidats, est la profondeur face aux relances : vous esquissez un pipeline, puis l'intervieweur ajoute des événements tardifs, un changement de schéma dans une source amont, et une question sur la façon dont vous sauriez que le résultat est faux. Les candidats qui ont exploité des pipelines en production gèrent généralement mieux cette dérive que ceux qui les ont seulement construits.

Les candidats seniors doivent s'attendre à davantage de poids sur le jugement : ce qu'il ne faut pas construire, comment expliquer un compromis à un chercheur ou à un partenaire produit, et comment ils ont géré une erreur dont ils étaient responsables.

Construisez votre préparation autour des critères qu'OpenAI cite pour les entretiens d'ingénierie, puis ajoutez la question des outils et le volet comportemental.

• Solutions bien conçues. Choisissez un domaine que vous connaissez, comme des journaux d'événements ou la mesure de la consommation, et esquissez les tables, leur granularité et le pipeline qui les alimente. Puis mettez la conception à l'épreuve : relance après échec partiel, rechargement, données tardives, colonne renommée.
• Code de haute qualité. Écrivez des transformations Python sur des enregistrements imbriqués et désordonnés, en gardant le code lisible. Entraînez-vous aux fonctions de fenêtrage, à la déduplication et à la sessionisation en SQL jusqu'à pouvoir les écrire sans aide-mémoire, et énoncez la granularité de chaque résultat avant de l'exécuter.
• Performances optimales. Pour chaque conception, nommez l'étape coûteuse et la façon de la rendre moins chère : élagage de partitions, traitement incrémental ou pré-agrégation.
• Bonne couverture de tests. Ajoutez des tests à chaque solution d'entraînement et décrivez les contrôles de qualité de données que vous exécuteriez en production. Ajouter des tests sans qu'on vous le demande montre l'habitude que décrit ce critère.
• Avec et sans outils d'IA. Entraînez-vous sur certains problèmes avec un assistant et sur d'autres sans, pour qu'aucun format ne vous surprenne. Dans le format assisté, expliquez à voix haute comment vous vérifiez ce que l'outil a produit.
• Endurance pour les finales. Répétez des entretiens simulés enchaînés d'une seule traite, car les finales concentrent 4-6 heures d'échanges sur 1-2 jours.
• Récits comportementaux. Préparez une panne de pipeline dont vous étiez responsable, un désaccord sur la définition d'une métrique, et un compromis que vous feriez autrement aujourd'hui.

Prenons un data engineer dont l'expérience se limite surtout à des jobs batch nocturnes dans une entreprise de paiement. Il consacre ses premières séances aux fonctions de fenêtrage SQL, puis s'exerce à expliquer comment rendre un rechargement sûr à relancer, car c'est là que se trouvent ses vrais récits. Il résout aussi certains problèmes avec un assistant d'IA et d'autres sans, afin que la politique d'outils d'un entretien donné ne change pas sa façon de raisonner.

La dernière étape consiste à dire tout cela à voix haute, car chaque étape est une conversation. La page d'entretien simulé de SubcueAI vous permet de vous entraîner à voix haute aux questions de data engineering avant le véritable entretien technique.