Accueil›Blog›Git en entretien data

Recruter en data

Git en entretien data : ce que le recruteur doit vérifier

Git passe souvent inaperçu au recrutement data — on le suppose acquis. C'est une erreur : un profil data qui ne maîtrise pas Git ralentit toute l'équipe et met la production en risque (secrets exposés, code écrasé). Or on peut vérifier les bons réflexes sans être soi-même développeur. Voici comment.

Data Builder·Juillet 2025·8 min de lecture·Cible : RH & recruteurs · tout profil data

Sommaire

À quoi sert Git en data
Les signaux d'un bon réflexe Git
Les red flags à repérer
La question à poser (sans être technique)
Quand faire appel à un expert
Grille par niveau

En data, Git sert à versionner et collaborer sur du SQL, des modèles dbt et des notebooks. Ce qui compte n'est pas la virtuosité, mais les bons réflexes de sécurité et de travail en équipe — et là, un seul mauvais réflexe (commit sur main, secret dans le repo) est un vrai signal.

1À quoi sert Git en data

À demander au candidat

Demandez : « À quoi vous sert Git dans votre travail data ? »

Git permet de garder l'historique du code, de travailler à plusieurs sans s'écraser, et de revenir en arrière en cas d'erreur. En data, il sécurise le SQL, les transformations dbt et les notebooks — tout ce qui, sans versioning, devient vite un chaos ingérable. Un bon candidat relie Git à la fiabilité de l'équipe.

Versionner le code : SQL, modèles dbt, notebooks — garder l'historique.
Collaborer à plusieurs sans écraser le travail des autres.
Revenir en arrière proprement en cas d'erreur.
Faire relire son code avant de le fusionner (revue de code).
Garder les secrets et les données hors du dépôt.

2Les signaux d'un bon réflexe Git

À demander au candidat

Écoutez comment il travaille en équipe, pas les commandes qu'il connaît.

La maîtrise de Git en data se voit dans l'hygiène de travail : branches, revues, pas de secret dans le repo. Un bon profil en parle comme d'une évidence, parce qu'il a déjà vu ce qui arrive quand ces règles ne sont pas respectées.

Il travaille en branches et ouvre des pull requests, jamais directement sur main.
Il parle de revue de code comme d'un réflexe d'équipe.
Il versionne son SQL et ses modèles dbt, pas seulement du « code applicatif ».
Il sait qu'on ne met jamais de secret ni de données dans un dépôt.
Il sait revenir en arrière proprement (sans effacer le travail des autres).

3Les red flags à repérer

À demander au candidat

Repérables sans savoir coder.

Les mauvais réflexes Git sont dangereux parce qu'ils touchent la sécurité et le travail des autres. Ils se repèrent facilement dès qu'on demande au candidat comment il collabore.

Il commit directement sur main sans branche ni revue.
Il a déjà mis (ou ne voit pas le problème à mettre) un secret ou des données dans un dépôt.
Il ne connaît que « git push » et panique dès qu'il y a un conflit.
Il ne travaille jamais en branches ni en revue de code.
Il ne versionne pas son SQL/ses transformations (« je garde ça sur mon poste »).

Signal d'alerte : un candidat qui ne voit pas de problème à committer un mot de passe ou un fichier de données dans un dépôt représente un vrai risque de sécurité — c'est un signal fort, quel que soit son niveau technique par ailleurs.

4La question à poser (sans être technique)

À demander au candidat

« Comment travaillez-vous à plusieurs sur le même code sans vous marcher dessus ? »

Cette question révèle l'hygiène de travail. Un bon profil décrit des branches, des revues et une main protégée. Un profil faible répond « on se prévient » ou n'a pas de méthode — signe qu'il n'a pas travaillé dans une équipe structurée.

Un bon profil décrit branches, pull requests et revue de code.
Il mentionne une main protégée et des règles d'équipe.
Il montre qu'il pense sécurité (pas de secret dans le repo).
Une absence de méthode révèle un travail solitaire, non structuré.

5Quand faire appel à un expert

À demander au candidat

Il y a une limite claire à ce qu'un recruteur non technique peut trancher seul.

Les signaux et la question ci-dessus vous permettent d'écarter les profils qui surjouent et de repérer les bons candidats. Mais confirmer finement un niveau Git — surtout sur un poste senior ou un profil rare — demande un regard technique. C'est là qu'un entretien mené par un expert fait la différence.

Vous hésitez entre deux candidats et l'enjeu (séniorité, salaire) est élevé.
Personne en interne ne peut évaluer techniquement la compétence en question.
Vous voulez un rapport objectif, comparable d'un candidat à l'autre.
Vous recrutez en volume et voulez fiabiliser votre présélection.

6Grille par niveau

Niveau	Maîtrise attendue	Signal GO	NO-GO
Junior	commit, push, pull, branches, PR	Travaille en branches, ouvre des PR	Commit directement sur main
Confirmé	Merge/rebase, résolution de conflits, revue	Décrit une méthode de collaboration claire	Panique au premier conflit
Senior	Historique propre, CI, sécurité du dépôt	Protège les secrets, versionne SQL/dbt	Committe des secrets ou des données
Lead	Conventions d'équipe, règles de protection	Définit le workflow et forme l'équipe	N'a aucune règle de collaboration

Home›Blog›Git in a data interview

Data hiring

Git in a data interview: what the recruiter should check

Git often goes unchecked in data hiring — it's assumed. That's a mistake: a data profile who doesn't master Git slows the whole team and risks production (exposed secrets, overwritten code). Yet you can check the right reflexes without being a developer yourself. Here's how.

Data Builder·July 2025·8 min read·For: HR & recruiters · any data profile

Contents

What Git is for in data
Signals of good Git reflexes
The red flags to spot
The question to ask (without being technical)
When to bring in an expert
Level grid

In data, Git is used to version and collaborate on SQL, dbt models and notebooks. What matters isn't virtuosity, but the right safety and teamwork reflexes — and there, a single bad reflex (committing to main, a secret in the repo) is a real signal.

1What Git is for in data

Ask the candidate

Ask: ‘What do you use Git for in your data work?’

Git keeps the history of code, lets several people work without overwriting each other, and lets you roll back on error. In data, it secures SQL, dbt transformations and notebooks — everything that, without versioning, quickly becomes unmanageable chaos. A good candidate ties Git to team reliability.

Version code: SQL, dbt models, notebooks — keep the history.
Collaborate without overwriting others' work.
Roll back cleanly on error.
Get code reviewed before merging (code review).
Keep secrets and data out of the repository.

2Signals of good Git reflexes

Ask the candidate

Listen to how they work in a team, not the commands they know.

Git mastery in data shows in work hygiene: branches, reviews, no secrets in the repo. A good profile talks about it as obvious, because they've seen what happens when these rules aren't followed.

They work in branches and open pull requests, never directly on main.
They talk about code review as a team reflex.
They version their SQL and dbt models, not only ‘application code’.
They know you never put secrets or data in a repo.
They know how to roll back cleanly (without erasing others' work).

3The red flags to spot

Ask the candidate

Spottable without coding.

Bad Git reflexes are dangerous because they touch security and others' work. They're easy to spot the moment you ask how the candidate collaborates.

They commit straight to main with no branch or review.
They've put (or see no problem putting) a secret or data in a repo.
They only know ‘git push’ and panic at the first conflict.
They never work in branches or code review.
They don't version their SQL/transformations (‘I keep that on my machine’).

Warning signal : a candidate who sees no problem committing a password or a data file to a repo is a real security risk — that's a strong signal, whatever their technical level otherwise.

4The question to ask (without being technical)

Ask the candidate

‘How do you work with others on the same code without stepping on each other?’

This question reveals work hygiene. A good profile describes branches, reviews and a protected main. A weak profile answers ‘we tell each other’ or has no method — a sign they haven't worked in a structured team.

A strong profile describes branches, pull requests and code review.
They mention a protected main and team rules.
They show they think security (no secrets in the repo).
A lack of method reveals solitary, unstructured work.

5When to bring in an expert

Ask the candidate

There's a clear limit to what a non-technical recruiter can decide alone.

The signals and question above let you filter out inflated profiles and spot good candidates. But finely confirming a Git level — especially for a senior role or a rare profile — needs a technical eye. That's where an expert-led interview makes the difference.

You hesitate between two candidates and the stakes (seniority, salary) are high.
No one in-house can technically assess the skill in question.
You want an objective report, comparable from one candidate to the next.
You're hiring at volume and want to make your shortlisting reliable.

6Level grid

Level	Expected proficiency	Signal GO	NO-GO
Junior	commit, push, pull, branches, PR	Works in branches, opens PRs	Commits directly to main
Mid-level	Merge/rebase, conflict resolution, review	Describes a clear collaboration method	Panics at the first conflict
Senior	Clean history, CI, repo security	Protects secrets, versions SQL/dbt	Commits secrets or data
Lead	Team conventions, protection rules	Defines the workflow and trains the team	Has no collaboration rules

Git en entretien data : ce que le recruteur doit vérifier

1À quoi sert Git en data

2Les signaux d'un bon réflexe Git

3Les red flags à repérer

4La question à poser (sans être technique)

5Quand faire appel à un expert

6Grille par niveau

Git in a data interview: what the recruiter should check

1What Git is for in data

2Signals of good Git reflexes

3The red flags to spot

4The question to ask (without being technical)

5When to bring in an expert

6Level grid

Vous recrutez un profil data ?