Un CV pour un poste d'analyste ou de data scientist diffère d'un CV d'ingénieur logiciel généraliste surtout par ce qui est mis en avant, pas par sa forme de base. L'expérience en ordre antéchronologique, un résumé court et des puces axées sur les résultats s'appliquent toujours, mais un CV axé sur la donnée commence par la question à laquelle une analyse a répondu et la décision qu'elle a changée, et indique honnêtement la taille et la source des données, plutôt que de s'appuyer sur le pipeline ou le modèle qui a produit la réponse. Un tableau de bord terminé, un modèle entraîné ou un pipeline propre n'est pas en soi le résultat qui mérite d'être mentionné dans un CV ; la décision qu'une équipe a prise différemment grâce à cela l'est.
Pourquoi l'accent se déplace pour le travail axé sur la donnée
Un CV d'ingénieur logiciel généraliste est habituellement valorisé pour ce qui a été livré : une fonctionnalité, un service, un système qui tourne désormais en production et qu'un utilisateur peut désigner. Le travail axé sur la donnée apporte souvent un autre type de bénéfice. Un rapport qu'une équipe dirigeante a utilisé pour choisir entre deux plans, une segmentation qui a changé la répartition d'un budget marketing, un contrôle qui a signalé un vrai problème dans un jeu de données avant qu'il n'atteigne un système en aval, rien de tout cela n'apparaît comme une fonctionnalité livrée. Un CV pour ce type de poste doit énoncer la décision explicitement, plutôt que de supposer que le lecteur associera lui-même un graphique ou un modèle à ce qui s'est passé ensuite. Ce cadrage compte particulièrement pour les postes d'analyste et de data scientist, où le résultat au quotidien est souvent une réponse à une question que quelqu'un a réellement posée, et non une fonctionnalité avec laquelle un utilisateur interagit directement.
Nommer la question à laquelle un projet a répondu, pas seulement l'outil utilisé
Une puce qui commence par l'outil, « Construit un modèle de prédiction de l'attrition en Python avec scikit-learn », indique au lecteur la technologie impliquée avant de lui dire quoi que ce soit sur l'importance du travail. Une puce qui commence par la question à laquelle le travail répond donne d'abord le bénéfice au lecteur : quelle étape d'intégration, parmi plusieurs, prédisait le mieux la résiliation d'un client dans les deux mois, si un changement de tarification envisagé réduirait vraisemblablement les inscriptions dans une région donnée, laquelle de deux évolutions produit concurrentes une équipe devrait prioriser. L'outil garde sa place dans la puce, mais plus tard, une fois que le lecteur sait déjà pourquoi l'analyse existait au départ. Cet ordre compte davantage pour le travail axé sur la donnée que pour une grande partie du travail d'ingénierie général, car la question à laquelle une analyse a été conçue pour répondre est souvent l'élément le plus lisible pour un lecteur extérieur à l'équipe.
Décrire les données honnêtement : taille, sources et périmètre
Indiquer la taille et la forme des données sur lesquelles un projet a réellement travaillé donne au lecteur une idée de l'échelle sans avoir besoin d'un chiffre de précision inventé. Une description honnête mentionne des éléments dont vous pouvez réellement vous souvenir ou que vous pouvez vérifier : environ combien d'enregistrements ou de lignes étaient concernés, combien de sources distinctes ont été rassemblées pour construire le jeu de données, jusqu'où les données remontaient, et si le travail a tourné une seule fois comme une analyse ponctuelle ou selon un calendrier récurrent. Énoncer un périmètre honnêtement, par exemple « rassemblé des données de trois systèmes internes couvrant environ deux ans d'activité », résiste à une question de suivi d'une façon qu'une statistique inventée et invérifiable sur l'impact de l'analyse ne le peut pas. Là où une analyse a réellement changé une métrique suivie et que ce chiffre reste vérifiable, il a sa place dans le CV énoncé directement ; là où ce n'est pas le cas, le périmètre et la décision qu'il a éclairée portent la puce tout aussi bien à eux seuls.
Regrouper les outils selon leur place dans le pipeline
La liste d'outils d'un poste axé sur la donnée couvre souvent à la fois un langage de requête, une bibliothèque de modélisation, un outil de visualisation et un système de planification ou d'orchestration, et regrouper cette liste selon la place de chaque outil dans le pipeline, collecte, transformation, analyse et modélisation, puis reporting ou visualisation, donne au lecteur une lecture plus rapide de la forme de l'expérience d'un candidat qu'une longue ligne non triée. Un lecteur qui cherche quelqu'un à l'aise pour porter un pipeline de bout en bout peut voir cette forme immédiatement grâce à quatre groupes courts par étape du pipeline, et un lecteur qui cherche spécifiquement de l'expérience en modélisation peut aller directement à ce groupe plutôt que de lire un outil de planification et un outil de visualisation pour la trouver.
Exemple illustratif : une puce construite autour d'une décision qu'elle a éclairée
Exemple illustratif, avant et après. Avant, mené par l'outil : « Utilisé SQL et Python pour analyser les données d'usage des clients et construire un modèle d'attrition. » Après, mené par la question et la décision : « Analysé environ dix-huit mois de données d'usage sur deux gammes de produits pour identifier quelle étape d'intégration prédisait le mieux une résiliation sous soixante jours ; ce résultat a conduit l'équipe produit à repenser cette seule étape plutôt que l'ensemble du parcours d'intégration. » Rien dans la version réécrite n'invente un pourcentage ou un résultat que la personne n'aurait pas pu réellement décrire ; elle énonce la question, le périmètre approximatif des données et la décision que le résultat a changée, autant d'éléments que la personne a réellement vécus.
Où quantifier l'impact s'applique encore
La même prudence contre l'invention d'un chiffre s'applique ici comme partout ailleurs dans un CV : un chiffre réel, actuellement vérifiable, issu d'un tableau de bord ou d'un rapport, mérite d'être énoncé directement, une impression rappelée et arrondie en un pourcentage propre ne le mérite pas. Quantifier l'impact en ingénierie sur un CV sans inventer de chiffres traite cette distinction plus en détail, et la même approche par périmètre et décision s'applique aussi bien à une puce axée sur la donnée qu'à une puce d'ingénierie générale.
Créez le vôtre
Le modèle Developer de CVBuilderKit est construit autour d'entrées menées par les projets et les résultats, ce qui convient à la liste de projets d'un analyste ou d'un data scientist tout autant qu'au code applicatif. Partez de ce modèle, ou d'un document vierge, dans l'éditeur, et faites commencer chaque puce par la question à laquelle un projet a répondu avant de nommer l'outil qui y a répondu.