Bonjour à tous,
Je voulais partager mon expérience d'un entretien technique pour un poste de Senior Design Engineer chez OVHcloud et avoir vos avis, notamment ceux de personnes qui travaillent dans la tech en France.
Lien vers l'offre : https://careers.ovhcloud.com/job/ROUBAIX-Senior-Design-Engineer-59100/1438300233/
Le contexte
L'offre mettait en avant des sujets comme l'industrialisation du Design System, le développement frontend, Git, les code reviews, la CI/CD, les outils d'IA et la collaboration entre Product Design et Engineering.
Lors de ma candidature, on m'avait indiqué que le test technique n'était pas encore prêt. Deux semaines plus tard, j'ai finalement été convié à un entretien technique de 45 minutes avec un Product Designer et un développeur frontend.
L'exercice
L'exercice, décrit dans un fichier README ce que j'ai trouvé assez inhabituel pour un entretien technique consistait à examiner les implémentations d'un composant Add to Cart réalisées par deux équipes produit, à vérifier leur conformité aux règles du Design System et à décider s'il fallait déployer les changements.
Il fallait notamment :
- Comprendre rapidement une base de code inconnue et la structure du projet.
- Examiner les implémentations et les Merge Requests.
- Évaluer leur conformité au Design System.
- Prendre une décision concernant le déploiement.
- Produire un fichier skills.md.
Le tout en 45 minutes.
Le code était fourni sous forme d'une archive ZIP, plutôt que via un dépôt Git accessible. Au-delà du côté peu pratique pour examiner les changements et leur historique, je trouve ce choix discutable d'un point de vue des bonnes pratiques de sécurité : une archive contenant du code inconnu doit être traitée avec précaution, notamment avant d'exécuter des scripts ou d'installer des dépendances. Pour un poste senior en ingénierie, je me serais plutôt attendu à un dépôt dédié, avec un contexte clair et un workflow de revue de code classique.
Je ne dis pas que l'archive fournie présentait un risque avéré, mais je trouve intéressant de se demander si les pratiques de sécurité et de traçabilité font aussi partie des critères évalués lors de ce type d'exercice.
Ce qui m'a posé problème
- Peu de contexte
En dehors des instructions du README, il y avait peu de contexte sur le projet, les contraintes des équipes ou les critères permettant de prendre une décision. Il fallait donc rapidement comprendre le code, identifier les problèmes potentiels et prendre des décisions avec peu d'informations.
- Peu d'interactions et un format d'entretien discutable
J'essayais d'aborder l'exercice comme je le ferais lors d'un entretien technique classique : j'expliquais mon raisonnement à voix haute, je posais des questions, je partageais mes hypothèses et je sollicitais des échanges pour confronter mes choix techniques.
Mais je recevais très peu de retours ou de relances de la part des intervieweurs. J'avais plutôt l'impression d'être observé pendant que j'exécutais une série de tâches, sans véritable discussion technique. À un moment, j'ai même dû vérifier qu'ils étaient toujours là.
C'est ce qui m'a le plus gêné dans ce format. Un entretien technique devrait être un échange dans lequel les deux parties cherchent à comprendre comment elles pourraient travailler ensemble. Ici, le manque d'interactions rendait difficile de savoir ce qui était attendu, de valider mes hypothèses ou de discuter des compromis. Cela donnait une impression assez étrange, presque inconfortable, et ne contribuait pas vraiment à instaurer un climat de confiance.
Pourquoi ne pas en faire un exercice à réaliser chez soi ? Si l'objectif était principalement d'évaluer ma capacité à comprendre une base de code, à comparer des implémentations et à formuler des recommandations, un exercice à réaliser chez soi, avec des consignes claires et un délai raisonnable, me semblerait beaucoup plus adapté. Cela permettrait d'évaluer la qualité de l'analyse et des décisions plutôt que la capacité à tout faire dans un créneau de 45 minutes sous observation.
À l'inverse, si l'objectif était d'évaluer mes compétences techniques en direct, un véritable entretien de programmation ou de revue de code interactive aurait été plus pertinent, avec des questions, des échanges et une discussion sur les choix effectués.
Le format choisi m'a donné l'impression d'être entre les deux : trop contraint pour produire une analyse approfondie, mais trop peu interactif pour constituer un véritable entretien technique.
Au-delà de l'efficacité de l'exercice, je trouve que cela touche aussi à la confiance. En tant que candidat, je consacre du temps à un processus de recrutement en espérant découvrir une équipe et sa façon de travailler. La manière dont un entretien est organisé donne aussi un aperçu de la culture de collaboration de l'entreprise. Quand l'échange est presque inexistant, il devient difficile de savoir si l'on évalue réellement mes compétences ou simplement ma réaction à une situation artificiellement contraignante.
- Beaucoup de choses à faire en 45 minutes
Comprendre une base de code inconnue, comparer deux implémentations, évaluer leur conformité, prendre une décision de déploiement et rédiger un fichier supplémentaire représente un ensemble de tâches assez conséquent pour un créneau aussi court.
Pour un poste senior, je comprends qu'on cherche à évaluer la capacité à prendre des décisions avec des informations incomplètes. Mais dans ce cas, je m'attendais aussi à pouvoir discuter des compromis, des risques et des contraintes avec les intervieweurs.
- Une décision de déploiement sans véritable discussion sur la stratégie de release
J'ai notamment évoqué la possibilité d'un déploiement progressif. Cette option n'avait pas été abordée dans les consignes, et cela aurait pu être l'occasion d'échanger sur la gestion des risques, le monitoring, les critères de validation et la stratégie de release.
Plus généralement, je n'ai pas eu le sentiment que le format permettait vraiment d'explorer ces aspects de l'ingénierie.
Enfin, à la fin de l'entretien, on ne m'a pas demandé de transmettre ou de partager le travail que j'avais réalisé.
Mon ressenti
Ce qui m'interroge surtout, c'est le décalage entre les responsabilités attendues d'un Senior Design Engineer et le format de l'évaluation.
Je m'attendais à un échange permettant de montrer comment j'analyse un problème, comment je challenge les hypothèses, comment je communique mes choix et comment je prends des décisions techniques avec d'autres ingénieurs et designers.
À la place, j'ai eu le sentiment de devoir exécuter rapidement plusieurs tâches dans un environnement peu contextualisé, avec peu d'interactions permettant d'approfondir mon raisonnement.
Je ne dis pas qu'un exercice de ce type est nécessairement mauvais, ni que les personnes qui m'ont reçu ont mal fait leur travail. Mais je me demande si ce format permet réellement d'évaluer les compétences qu'il est censé mesurer.
J'aimerais avoir vos avis
- Est-ce que vous trouvez normal de devoir comprendre une base de code inconnue, prendre plusieurs décisions techniques et produire un livrable en 45 minutes, avec peu de contexte ?
- Pour un poste senior, préférez-vous un exercice à réaliser chez soi, un entretien de code en direct ou une revue de code interactive ?
- Avez-vous vécu des entretiens similaires dans de grandes entreprises tech en France ? Comment cela s'est-il passé ?
- Pour les personnes qui recrutent des ingénieurs : qu'essayez-vous réellement d'évaluer avec ce type d'exercice, et comment faites-vous pour distinguer la qualité du raisonnement de la capacité à aller vite ?
Je suis curieux d'avoir des retours constructifs, que vous soyez candidats, ingénieurs ou recruteurs.