Un test technique PHP destiné aux candidats est utile lorsqu’il aide à répondre à une question concrète sur le travail : la personne peut-elle maintenir une API, diagnostiquer un bug ou contribuer à une application existante ? Il ne devrait pas mesurer qui dispose du plus de temps libre, maîtrise un outil particulier ou devine les préférences personnelles de la personne qui évalue.
Pour que le résultat soit utile, l’équipe doit d’abord définir les compétences pertinentes, choisir un format proportionné et évaluer à l’aide de critères observables. Le test est une étape du processus, pas un substitut à la discussion sur l’expérience, la collaboration et le contexte.
Commencez par les tâches réelles du poste
Avant de rédiger un énoncé, précisez ce que la personne fera au cours de ses premiers mois. Un poste axé sur la maintenance d’une application existante requiert des compétences différentes de celles d’un poste consacré au développement de nouveaux services. Dans le premier cas, la lecture du code, le diagnostic des erreurs et la sécurité des changements de faible ampleur peuvent être importants ; dans le second, la conception d’une API ou la définition des limites entre composants.
Choisissez deux ou trois compétences prioritaires et associez chacune à une tâche observable. Par exemple, si le poste exige de maintenir une API PHP, vous pouvez évaluer la manière dont une entrée est validée et dont le comportement face à des données invalides est expliqué. Il n’est pas nécessaire de couvrir l’ensemble du langage, du framework et de l’architecture dans un seul test.
Il convient également de distinguer les exigences indispensables des connaissances qui peuvent s’acquérir. Si l’équipe peut enseigner un outil après l’intégration, en faire une condition d’accès risque d’exclure des profils compétents sans améliorer la prédiction de leurs performances.
Choisissez le format selon ce que vous devez observer
Une revue de code est adaptée lorsque le travail consiste à maintenir une base de code existante. Vous pouvez fournir un court extrait comportant un défaut ou un choix discutable, puis demander à la personne de repérer les risques, de proposer des changements et d’indiquer ce qu’elle testerait. Cela permet d’observer ses capacités de lecture et son jugement sans lui demander de construire une application à partir de zéro.
Un entretien technique est utile pour explorer les choix, l’expérience et la communication. Il fonctionne mieux avec des questions ancrées dans des situations concrètes et en laissant à la personne le temps de présenter ses hypothèses, les solutions possibles et leurs conséquences. Il ne doit pas se transformer en interrogation de mémoire sur la syntaxe ou des détails peu pertinents.
Un exercice pratique de portée limitée peut fournir des éléments sur la mise en œuvre lorsque cette compétence est essentielle. Limitez-le à une petite tâche, comme compléter une validation ou corriger un cas d’erreur dans un exemple autonome. Si une solution de grande ampleur est nécessaire, il peut être plus raisonnable de répartir l’évaluation entre une revue guidée et un entretien plutôt que d’exiger des heures de travail à domicile.
Le format doit permettre de démontrer la compétence évaluée, et non récompenser la maîtrise d’un environnement particulier. Si le poste dépend d’un framework spécifique, indiquez lequel et pourquoi ; dans le cas contraire, acceptez des solutions équivalentes et évaluez le raisonnement.
Définissez un exercice avec un contexte et des limites explicites
Un bon énoncé explique l’objectif, le contexte minimal, les contraintes et la manière de remettre le résultat. Indiquez le comportement attendu, les parties du code qui peuvent être modifiées, si des dépendances sont disponibles et combien de temps la tâche devrait prendre. Précisez également si la consultation de la documentation est autorisée et quels outils peuvent être utilisés.
L’exercice doit être représentatif, sans pour autant constituer une fonctionnalité prête à intégrer au produit. Évitez de demander une intégration complète, une migration de grande ampleur ou une fonctionnalité que l’entreprise doit publier. Si le cas ressemble à une tâche réelle, utilisez un scénario réduit et fictif, sans données ni code confidentiels. Le résultat du processus de recrutement ne doit pas se transformer en travail de production gratuit.
La durée estimée est une limite de conception, pas une épreuve de vitesse. Indiquez quoi faire si tout n’est pas terminé et encouragez les candidats à établir des priorités. Il est préférable d’observer une solution partielle bien expliquée que de favoriser la personne qui a pu consacrer de nombreuses heures au test en dehors du processus.
Évaluez à l’aide d’une grille fondée sur des éléments observables
Définissez la grille d’évaluation avant d’examiner les candidatures. Une échelle courte — par exemple, insuffisant, satisfaisant et solide — peut suffire si chaque niveau décrit des éléments concrets. Évitez les critères vagues comme « bonne adéquation » ou « code élégant », qui peuvent dissimuler des préférences personnelles.
- Raisonnement : la personne repère les hypothèses, explique ses choix et reconnaît les limites ou les solutions possibles.
- Correction et lisibilité : elle résout le cas proposé à l’aide d’un code compréhensible et de changements proportionnés.
- Sécurité : elle traite correctement les entrées, les erreurs et les données sensibles selon le contexte de l’exercice.
- Tests : elle choisit des cas pertinents et explique le comportement qu’ils couvrent, même si elle n’écrit pas une suite complète.
- Collaboration : elle pose des questions pertinentes, communique ses incertitudes et répond aux remarques sans dissimuler ses désaccords.
Les critères n’ont pas tous le même poids pour chaque poste. Un poste de maintenance peut donner la priorité à la compréhension et à la prudence ; un autre, à la conception d’interfaces. Précisez ces priorités et distinguez les erreurs critiques — comme une exposition manifeste de données — des détails stylistiques qui ne changent pas le résultat.
Examinez le travail et interrogez la personne sur ses choix
L’évaluation doit suivre une séquence commune. Les personnes chargées de l’examen peuvent d’abord attribuer une note de manière indépendante, puis comparer les éléments observés. Cela réduit l’effet de la première impression et permet de repérer les critères ambigus. En cas de désaccord, la discussion doit porter sur des extraits précis et sur la grille, et non sur des intuitions concernant la personnalité.
Lors du suivi, posez une question sur un choix précis : que changerait la personne avec plus de temps, quel cas de test ajouterait-elle ou quel risque a-t-elle jugé prioritaire ? Les questions doivent permettre de clarifier le raisonnement, et non introduire soudainement des exigences qui ne figuraient pas dans l’énoncé. Laissez à la personne la possibilité d’expliquer des choix différents de ceux qu’aurait faits l’équipe.
Considérez la réaction à une remarque comme un indice de capacité à collaborer, et non comme une preuve d’obéissance. Une personne peut défendre une autre solution de manière argumentée. La capacité à expliquer des compromis et à revoir une solution à la lumière de nouvelles informations est souvent plus révélatrice que le fait d’adhérer à une préférence de la personne qui mène l’entretien.
Réduisez les biais et proposez des options raisonnables
Utilisez les mêmes consignes, critères et délais pour toutes les personnes qui postulent au même poste. Lorsque c’est possible, masquez les informations non pertinentes lors du premier examen et limitez les commentaires non structurés. Acceptez des formats équivalents s’ils évaluent la même compétence : un entretien guidé peut remplacer un exercice à domicile lorsque l’objectif est de comprendre le raisonnement.
Demandez à l’avance si un aménagement du format ou une mesure d’accessibilité est nécessaire et convenez d’une option de remplacement sans pénalité. Ne supposez pas que les pauses, la rapidité d’élocution ou un style de communication informel indiquent le niveau technique. De même, l’utilisation de la documentation doit être traitée de manière cohérente : dans le travail habituel, consulter des références peut être normal.
Repérez les tests disproportionnés avant leur publication
Examinez la tâche du point de vue d’une personne candidate. La portée correspond-elle au temps annoncé ? Les informations permettent-elles de commencer sans devoir deviner les exigences ? Évalue-t-on les compétences requises pour le poste ou la familiarité avec une convention interne qui n’a pas été expliquée ? L’équipe pourrait-elle exploiter directement le résultat à des fins commerciales ? Une réponse préoccupante à cette dernière question exige de réduire ou de remplacer l’exercice.
Parmi les autres signaux d’alerte figurent une longue liste d’exigences, une évaluation fondée sur les goûts personnels, des consignes contradictoires ou la promesse implicite qu’une solution parfaite est nécessaire. Si l’équipe a besoin de plusieurs heures pour résoudre la tâche, celle-ci n’est probablement pas assez bien délimitée pour une première étape de recrutement.
Liste de contrôle pour améliorer le processus
- Associer chaque critère à une responsabilité réelle du poste.
- Choisir le format le plus court qui permette d’observer la compétence recherchée.
- Communiquer le contexte, les outils, les limites de temps et les modalités de remise.
- Définir les niveaux d’évaluation à l’aide d’exemples concrets avant de recevoir les résultats.
- Poser des questions de suivi comparables et permettre l’explication d’autres solutions.
- Recueillir les commentaires des candidats et des personnes chargées de l’évaluation pour repérer les incompréhensions ou la charge inutile.
Un test technique PHP destiné aux candidats n’a pas besoin d’être complexe pour être rigoureux. Sa qualité dépend de sa capacité à mesurer un élément pertinent, avec une charge raisonnable et une évaluation cohérente. Si, après plusieurs campagnes de recrutement, les résultats ne permettent pas de distinguer les compétences requises pour le poste, revoyez la conception avant d’augmenter la difficulté.
