Take-home : avantages et limites
Le take-home assignment permet au candidat de travailler dans son environnement, à son rythme, et de produire un livrable représentatif. Il est moins stressant qu'un live coding. Mais il est chronophage (8 à 20 heures selon le scope), favorise les candidats qui ont du temps libre (biais parentalité, biais dual-career), et demande beaucoup de temps d'évaluation côté entreprise.
La règle d'or : 3 à 4 heures maximum
Tout take-home qui demande plus de 4 heures est abusif et biaisé. Les candidats seniors refusent, les juniors le font au détriment d'autres process. Scope votre exercice pour qu'un candidat expérimenté le finisse en 3 heures, un junior en 5.
Design de l'exercice
Bon exercice
Un mini-problème métier : "Construire un endpoint REST /users qui retourne la liste paginée des utilisateurs avec filtres nom et date de création." Code réaliste, tests unitaires, 2-3 heures.
Mauvais exercice
"Build a complete marketplace MVP with auth, payment, admin panel". Scope absurde, signale une entreprise qui ne respecte pas le temps des candidats.
Critères d'évaluation transparents
Publiez la grille à l'avance :
- Code quality (lisibilité, structuration, tests).
- Choix techniques (justifiés dans un README).
- Gestion des erreurs et edge cases.
- Performance (si pertinent).
- Qualité du README et de la documentation.
Le debrief oral est crucial
Un take-home sans entretien de debrief est une perte de temps. Organisez un call de 45 minutes où le candidat présente son approche, défend ses choix, répond aux questions. Vous verrez rapidement si le code a été écrit par le candidat ou par IA / un pote.
Alternative : le "mini-coding challenge" de 60 minutes
Pour les stacks où le take-home est trop lourd, un challenge de 60 minutes sur un problème focalisé (ex : implémenter un parser JSON simple) donne 80% de l'information pour 20% du temps.
Rocket4RPO et l'ingénierie d'entretiens
Nous aidons nos clients à designer des process qui respectent le candidat tout en étant discriminants. Parlons.