Un build engineer C/C++ tient la chaîne qui transforme le code en binaires livrables : la configuration CMake ou Bazel, les dépendances Conan ou vcpkg, les compilateurs de chaque plateforme, le cache et le build distribué, puis le packaging et la signature. On le trouve partout où le produit sort en binaire natif, pour Windows, Linux, macOS ou une carte embarquée. Il travaille pour les développeurs et n'écrit pas les fonctionnalités.
CMake figure sur presque tous les CV de développeurs C++. Avoir ajouté un fichier à un CMakeLists.txt existant ne dit rien sur la capacité à réorganiser un projet en cibles, à exporter une bibliothèque ou à expliquer pourquoi un cache distant ne sert à rien. Les profils qui ont fait le métier donnent des temps de build avant et après, et la façon dont ils les ont mesurés.
Avant l'entretien, il faut connaître le système de build en place, les plateformes cibles et la durée actuelle d'un build complet et d'un build incrémental. Si une migration vers Bazel est prévue, l'expérience d'une migration déjà conduite, et sa durée, comptent beaucoup. Le PDF contient 30 questions, un cas de 20 minutes et une grille de 1 à 4.
Les outils de build C/C++ à connaître pour ce poste
CMake
Le générateur de build le plus répandu en C++. Il décrit des cibles (bibliothèques, exécutables) et leurs dépendances, puis produit des fichiers pour Ninja, Make ou Visual Studio. CMake 4.0 a retiré la compatibilité avec les projets qui déclarent une version minimale antérieure à 3.5, ce qui a cassé de vieux projets lors des mises à jour.
Ninja
Le petit outil qui exécute réellement les commandes de compilation, plus vite que Make sur les gros projets. Il est généré par CMake et utilisé en dessous par d'autres outils. Son journal (.ninja_log) sert à voir quels fichiers coûtent le plus cher.
Bazel
Le système de build de Google, choisi pour les gros monorepos multi-langages. Chaque action est décrite avec ses entrées et ses sorties, ce qui permet un cache partagé et l'exécution sur des machines distantes. Depuis Bazel 9, les dépendances externes passent obligatoirement par Bzlmod (fichier MODULE.bazel), l'ancien fichier WORKSPACE est retiré.
Conan et vcpkg
Les deux gestionnaires de paquets du monde C++. Conan, écrit en Python, distribue des binaires précompilés par configuration (compilateur, version, Debug ou Release) depuis des serveurs privés. vcpkg, porté par Microsoft, compile les dépendances depuis les sources avec un cache binaire. La plupart des CV récents parlent de Conan 2.
ccache, sccache et cache distant
Des outils qui mémorisent le résultat d'une compilation et le resservent quand le même fichier est recompilé avec les mêmes options. Bien réglés et partagés entre agents de CI, ils font tomber un build de plusieurs dizaines de minutes à quelques minutes. Mal réglés, ils ne servent à rien, souvent à cause des chemins absolus.
Toolchains et compilation croisée
GCC, Clang et MSVC, avec leurs versions, et la capacité à compiler sur un PC x86 pour une carte ARM à partir d'un sysroot. Les problèmes d'ABI entre versions de compilateurs et de glibc font partie du quotidien. Le candidat doit pouvoir dire d'où venaient ses toolchains et comment elles étaient figées.
Build distribué
distcc, icecream ou l'exécution distante de Bazel (Buildbarn, BuildBuddy, EngFlow) répartissent les compilations sur plusieurs machines. C'est utile quand le parallélisme est réel, coûteux à exploiter, et sans effet sur l'édition de liens.
Perforce P4 et Git LFS
Les dépôts qui contiennent beaucoup de gros fichiers binaires restent souvent sur Perforce, renommé P4 (ex-Helix Core), ou sur Git avec LFS. Le choix pèse sur la durée des checkouts en CI et sur la façon de verrouiller les fichiers.
Signature et packaging
Authenticode et signtool sous Windows, codesign et notarisation par notarytool sous macOS, paquets DEB, RPM ou MSI produits par CPack ou un outil dédié. Les clés de signature vivent sur un HSM ou dans un service managé, jamais dans le dépôt.
Le poste change selon le système de build. Sur un monorepo Bazel, le travail porte sur les règles Starlark, la toolchain hermétique et le cache ou l'exécution distante. Sur un parc de dépôts CMake, il porte sur la propreté des cibles, les paquets Conan ou vcpkg partagés entre équipes et la matrice Windows, Linux et macOS. Dans l'embarqué, la compilation croisée, le sysroot et Yocto prennent le dessus. Le titre varie aussi : build engineer, ingénieur build, ingénieur usine logicielle, parfois ingénieur outillage. Un développeur C++ qui a pris en charge le build de son équipe peut faire un bon candidat, à condition de pouvoir expliquer ses choix et leur effet mesuré sur les temps de build.
Les compétences attendues d'un build engineer C/C++
- CMake moderne : cibles, export, presets
- Bazel : Bzlmod, Starlark et hermétisme
- Dépendances C++ avec Conan ou vcpkg
- Cache, mesure et réduction des temps de build
- Compilation croisée, toolchains et ABI
- Signature, paquets et builds reproductibles
Cinq questions pour un build engineer C/C++, réponses attendues comprises
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un build complet prend 50 minutes sur la CI. Comment trouvez-vous où passe le temps ?
Une bonne réponseIl mesure avant de toucher à quoi que ce soit : .ninja_log (lisible avec ninjatracing), -ftime-trace de Clang et ClangBuildAnalyzer pour les fichiers les plus coûteux, --profile côté Bazel. Il sépare configuration, compilation, édition de liens et tests. Il cherche les en-têtes inclus partout, les templates lourds, une édition de liens qui tourne seule à la fin, un parallélisme mal réglé. Viennent ensuite le cache, les en-têtes précompilés ou un éditeur de liens plus rapide.
Signal d'alerteDoubler les cœurs des agents d'emblée, ou couper des tests pour gagner du temps.
Question 2 · confirmé
Un CMakeLists.txt pose include_directories() et add_definitions() en haut du fichier, pour tout le projet. Que changez-vous ?
Une bonne réponseIl passe à une écriture par cibles : target_include_directories, target_compile_definitions, target_compile_options et target_link_libraries, chacun avec PUBLIC, PRIVATE ou INTERFACE. Une propriété PRIVATE reste dans la cible, une propriété PUBLIC ou INTERFACE passe aux cibles qui la consomment. Une option ne fuit plus dans tout le projet, et la bibliothèque devient exportable telle quelle.
Signal d'alerte« Ça marche comme ça depuis des années », ou des chemins absolus ajoutés en plus. Un candidat qui ne sait pas dire ce que change PUBLIC par rapport à PRIVATE.
Question 3 · senior
Le cache distant Bazel donne très peu de hits entre la CI et les postes des développeurs. Où cherchez-vous ?
Une bonne réponseIl compare les clés d'action de deux builds avec le journal d'exécution (--execution_log_compact_file ou sa version JSON). Les causes habituelles : des variables d'environnement qui entrent dans les actions (PATH, --action_env, d'où --incompatible_strict_action_env), un compilateur pris sur la machine au lieu d'une toolchain déclarée, des options différentes entre le .bazelrc de la CI et celui des postes, des chemins absolus ou des dates dans les sorties. Il rappelle que seule la CI écrit dans le cache et que les postes le lisent (--remote_upload_local_results=false).
Signal d'alerte« On agrandit le cache », ou on le vide et on relance, sans jamais comparer deux actions.
Question 4 · confirmé
Trois équipes compilent en Debug et en Release, avec GCC 12 et Clang 17. Comment Conan sait-il quel binaire d'une dépendance leur donner ?
Une bonne réponsePar le package_id, calculé à partir des settings (os, arch, compiler, compiler.version, compiler.cppstd, build_type), des options et des dépendances. En Conan 2, chaque build utilise un profil host et un profil build. Si aucun binaire ne correspond, Conan échoue ou le compile avec --build=missing. Les binaires sont publiés sur un remote interne, et un lockfile fige les révisions utilisées.
Signal d'alerteUne archive unique de .so copiée à la main, ou une réponse qui ignore que Debug et Release donnent deux binaires distincts.
Question 5 · confirmé
Un fichier de toolchain CMake pour aarch64 marche sur votre poste et échoue sur la CI, qui trouve les bibliothèques x86 de l'hôte. Que vérifiez-vous ?
Une bonne réponseCMAKE_SYSTEM_NAME et CMAKE_SYSTEM_PROCESSOR, les compilateurs croisés, CMAKE_SYSROOT vers un sysroot versionné, et CMAKE_FIND_ROOT_PATH_MODE_LIBRARY, _INCLUDE et _PACKAGE à ONLY, _PROGRAM à NEVER. pkg-config doit chercher dans le sysroot (PKG_CONFIG_SYSROOT_DIR, PKG_CONFIG_LIBDIR). La toolchain et le sysroot sont livrés dans une image ou un paquet figé, pas installés à la main sur chaque machine.
Signal d'alerteDes chemins de l'hôte dans le fichier de toolchain, ou des .so copiés depuis la carte au hasard.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Build engineer C/C++ : les questions fréquentes
Quelle différence entre un build engineer C/C++ et un ingénieur DevOps ?
L'ingénieur DevOps s'occupe surtout de pipelines, de conteneurs et de déploiement sur une infrastructure. Le build engineer C/C++ descend dans la compilation : organisation des cibles CMake ou des règles Bazel, compilateurs et leurs options, dépendances natives, cache, édition de liens, ABI. Il utilise Jenkins ou GitLab CI comme un DevOps, mais il passe la plupart de son temps dans les fichiers de build et sur ce que coûte chaque compilation.
Bazel est-il indispensable quand l'équipe travaille avec CMake ?
Non, sauf si une migration est prévue. Un très bon profil CMake connaît la structure par cibles, l'export de paquets, les presets, les toolchains et le cache, et c'est ce que l'équipe utilisera tous les jours. Bazel devient utile à évaluer si le dépôt doit y passer ou s'il y est déjà. Dans ce cas, compte une migration vécue et ce qu'elle a coûté, pas une simple connaissance de la syntaxe.
Quel test technique pour un build engineer C/C++ ?
Un petit projet volontairement mal construit fonctionne bien : un CMakeLists.txt avec des include_directories globaux, une dépendance copiée dans le dépôt et un build qui recompile tout à chaque modification. Le candidat propose les corrections dans l'ordre et dit comment il mesurerait le gain. Une heure suffit, en direct, avec un partage d'écran.
Quel niveau de C++ attendre d'un build engineer ?
Il n'a pas besoin d'écrire du C++ avancé tous les jours, mais il doit lire le code, comprendre ce qui coûte à la compilation (templates, en-têtes, inclusions transitives) et diagnostiquer une erreur d'édition de liens ou une violation de l'ODR. Une bonne connaissance des options de GCC, Clang et MSVC compte davantage que la maîtrise des dernières nouveautés du langage. Python ou Bash servent pour les scripts.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
