Guide recrutement data
Test technique Git pour la data : ce qu'on évalue vraiment
Git n'est pas qu'un outil de développeur : versionner du SQL, du dbt et des notebooks change la fiabilité d'une équipe data. L'écart se creuse vite entre celui qui commit sur main et celui qui maîtrise un vrai workflow de revue. Voici ce qu'on évalue.
Data Builder·Juillet 2025·9 min de lecture·Data Engineer / Analytics Engineer
Un profil data qui ne maîtrise pas Git ralentit toute l'équipe et met la production en risque. On évalue moins la virtuosité que les bons réflexes et la sécurité. Cinq dimensions.
1Branches et workflow
Question discriminante
Décrivez un workflow de branches sain pour une équipe data.
- Branches de fonctionnalité +
main protégée, jamais de commit direct sur main. - Pull/Merge Requests pour la revue de code avant fusion.
- Trunk-based vs Gitflow selon la taille et le rythme de l'équipe.
- Branches courtes pour limiter les conflits.
2Merge vs rebase
Question discriminante
Quelle est la différence entre merge et rebase, et quand utiliser l'un plutôt que l'autre ?
merge — préserve l'historique réel, crée un commit de fusion.rebase — linéarise l'historique en rejouant les commits.rebase -i pour nettoyer ses commits avant la revue.- Ne jamais rebaser une branche déjà partagée avec d'autres.
Signal d'alerte : un git push --force sur une branche partagée (surtout main) peut effacer le travail des autres — c'est éliminatoire.
3Annuler proprement
Question discriminante
Comment annulez-vous un commit déjà poussé sur une branche partagée ?
git revert — sûr et public : crée un commit qui annule (n'efface rien).git reset — pour du local non partagé uniquement.git cherry-pick pour reprendre un commit précis ailleurs.git reflog pour retrouver un état perdu.
4Conflits et historique
Question discriminante
Comment gérez-vous un conflit de fusion et gardez-vous un historique lisible ?
- Comprendre un conflit et le résoudre à la main sans casser la logique.
- Commits atomiques avec des messages clairs.
.gitignore propre (données, secrets, artefacts hors du repo).git blame/log pour comprendre le contexte d'un changement.
5Bonnes pratiques en équipe data
Question discriminante
Pourquoi Git est-il déterminant pour un profil data en particulier ?
- Versionner SQL, modèles dbt et notebooks — reproductibilité et revue.
- Intégration à la CI/CD (tests dbt, linting) déclenchée sur PR.
- Revue de code : améliorer la qualité et diffuser la connaissance.
- Aucune donnée ni secret dans le repo, jamais.
Signal d'alerte : committer des identifiants ou un fichier de données dans le repo est un incident de sécurité — un réflexe à bannir absolument.
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, revert, résolution de conflits | Choisit revert plutôt que reset sur du partagé | Force-push sur une branche partagée |
| Senior | Historique propre, CI/CD, sécurité du repo | Maintient un historique lisible, protège les secrets | Committe des secrets ou des données |
| Lead | Conventions d'équipe, stratégie de branches, revue | Définit le workflow et les règles de protection | N'a aucune politique de revue ni de protection de main |
Home›Blog›Git technical interview for data
Data hiring guide
Git technical interview for data: what we really assess
Git isn't just a developer tool: versioning SQL, dbt and notebooks changes a data team's reliability. The gap widens fast between someone who commits to main and someone who masters a real review workflow. Here's what we assess.
Data Builder·July 2025·9 min read·Data Engineer / Analytics Engineer
A data profile who doesn't master Git slows the whole team and risks production. We assess good reflexes and safety more than virtuosity. Five dimensions.
1Branches and workflow
Key question
Describe a healthy branching workflow for a data team.
- Feature branches + protected
main, never a direct commit to main. - Pull/Merge Requests for code review before merging.
- Trunk-based vs Gitflow depending on team size and cadence.
- Short-lived branches to limit conflicts.
2Merge vs rebase
Key question
What's the difference between merge and rebase, and when do you use each?
merge — preserves the real history, creates a merge commit.rebase — linearizes history by replaying commits.rebase -i to clean up commits before review.- Never rebase a branch already shared with others.
Warning signal : a git push --force on a shared branch (especially main) can erase others' work — that's disqualifying.
3Undoing cleanly
Key question
How do you undo a commit already pushed to a shared branch?
git revert — safe and public: creates a commit that undoes it (erases nothing).git reset — for local, unshared work only.git cherry-pick to bring a specific commit elsewhere.git reflog to recover a lost state.
4Conflicts and history
Key question
How do you handle a merge conflict and keep a readable history?
- Understand a conflict and resolve it by hand without breaking the logic.
- Atomic commits with clear messages.
- Clean
.gitignore (data, secrets, artifacts out of the repo). git blame/log to understand the context of a change.
5Best practices in a data team
Key question
Why is Git decisive for a data profile in particular?
- Version SQL, dbt models and notebooks — reproducibility and review.
- CI/CD integration (dbt tests, linting) triggered on PR.
- Code review: improve quality and spread knowledge.
- No data and no secrets in the repo, ever.
Warning signal : committing credentials or a data file to the repo is a security incident — a reflex to ban outright.
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, revert, conflict resolution | Chooses revert over reset on shared work | Force-pushes a shared branch |
| Senior | Clean history, CI/CD, repo security | Keeps a readable history, protects secrets | Commits secrets or data |
| Lead | Team conventions, branch strategy, review | Defines the workflow and protection rules | Has no review policy or main protection |