Avant propos

Je vais décrire ici mon process. Il n’est sûrement pas parfait, mais il me permet de comparer les candidats et candidates sur des éléments communs, en accord avec nos attentes et notre stack technique.

Afin d’alléger le texte, je vais utiliser « un développeur », « un candidat », etc. mais il faut bien lire « un(e) développeur(se) », « un(e) candidat(e) », etc.

Pour donner quelques chiffres, j’ai dû faire passer une petite centaine d’entretiens, pour un recrutement d’environ 25-30 dev, CDI, CDD, alternance ou stage confondus.

Je découpe mon process en 6 étapes :

  • La rédaction de l’offre
  • Le tri des candidatures
  • Le premier entretien, de « découverte », en distanciel
  • Le test technique
  • Le second entretien, technique, en présentiel
  • La décision finale

Je vais tenter de vous décrire ce que contiennent ces étapes et surtout les points auxquels je suis attentif. J’espère que cela pourra vous donner des clés pour vos prochaines candidatures et prochains entretiens.

La rédaction de l’offre

Compétences requises et compétences appréciées.

Compétences requises

Les compétences décrites ici sont celles qu’il est nécessaire de maîtriser pour un poste Junior chez nous. Elles ne sont pas forcément suffisantes pour être efficaces dès le premier jour, mais elles le sont pour prendre en main et progresser sur notre environnement technique :

  • PHP et un framework PHP : Pour prendre en main un framework PHP, il faut maîtriser la Programmation Orientée Objet. Même si notre stack s’articule autour de CakePHP, on ne demande pas spécifiquement ce framework. Le passage de Symfony, Laravel, CodeIgniter ou autre vers CakePHP est possible, les grandes mécaniques (MVC, etc.) restant les mêmes.
  • Le SQL, parce que même si le travail est mâché par l’ORM du framework, on a souvent besoin d’écrire des requêtes, notamment pour rechercher des données dans une base, comprendre un fonctionnement spécifique, ou écrire une requête complexe.
  • Les langages Front : HTML, CSS, Javascript. On développe des projets majoritairement « Full-Stack », en s’appuyant sur Bootstrap pour le Front. Connaître Bootstrap, ses composants principaux, et savoir faire un peu de CSS ou Javascript est nécessaire. Il faut donc savoir écrire du Javascript, comprendre la différence d’exécution entre du code serveur et du code client, etc.
  • Notions d’ergonomie : Même s’il y a du design dans nos process, c’est important à mes yeux que le développeur ait des notions d’ergonomie pour concevoir des interfaces agréables, ou a minima se rendre compte qu’une interface est perfectible.
  • Utilisation de Git : Les mécaniques de base du versioning, un commit, des branches, un merge, résoudre un conflit.

Compétences appréciées

Ce qui peut faire la différence, c’est le fait de maîtriser ou connaître précisément des technologies de notre stack :

  • CakePHP
  • VueJS
  • L’écriture de tests unitaires
  • Sécurité Web
  • Hébergement et déploiement

Pour un Junior, on sait que ce sont des technologies ou concepts qui ne sont pas forcément abordés durant le cursus scolaire. Mais selon les projets, les appétences, ils peuvent avoir été découverts, testés, pris en main, etc.

Il y a d’autres points dans l’offre (anglais, usages d’outils comme Notion, etc.) mais c’est sur les technos que mon attention va le plus se porter. Ce qui m’amène à mon second point sur le tri des candidatures.

Tri des candidatures

Quand un poste de Junior est ouvert, je reçois de 1 à 3 candidatures par jour. Dans mes tâches quotidiennes, c’est beaucoup, et j’avoue que parfois je n’ai pas le temps de répondre à tout le monde… Si jamais vous avez postulé chez moi et que je ne vous ai pas répondu, je m’en excuse.

Je ne demande pas de lettre de motivation, elles sont toujours très classiques pour des postes de Junior et au-delà de l’orthographe, je trouve qu’on n’y évalue pas grand-chose.

Je me concentre donc sur le CV, d’abord les technologies présentées :

  • Comme je l’écris plus haut, on cherche des gens pour faire du PHP. Et je reçois parfois des CV avec écrit en gros « Développeur Front-End React » ou « Développeur Python ». Dans ces cas-là, je réponds tout de suite négativement.
  • Passé ce premier « filtre », je cherche les mots-clés autour de PHP. Je préfère peu de technos sur un CV qu’une liste très longue allant de C à Javascript, en passant par Java, PHP, .Net… c’est parfois le signe que les technos ont toutes été abordées sans forcément être approfondies.
  • Je recherche le nom d’un framework PHP, peu importe lequel.
  • Puis des choses liées au Front : HTML, CSS, Javascript
  • Pour les technologies, je ne fais pas attention au %, jauges, etc. je trouve ça trop subjectif mais je n’en tiens pas rigueur.

Si je ne retrouve pas les mots-clés que je recherche, je réponds donc négativement.

Ensuite, je regarde, dans un même « lot », le cursus, les projets scolaires ou personnels et les expériences professionnelles. Il faut qu’il y ait un bon équilibre. Des gens qui ont suivi des formations courtes, je vais être plus regardant sur les projets, il faut qu’il y ait une « compensation » entre le temps de formation et l’expérience acquise ailleurs. S’il y a un compte Github avec du code, ça peut me rassurer par exemple.

Pour les expériences professionnelles, je vais regarder si ce sont des secteurs similaires à ceux de nos projets actuels, pour apprécier les problématiques métiers efficacement, ou si la personne a travaillé dans une agence.

Enfin, je jette un œil aux centres d’intérêt et hobbys, ça peut révéler des atomes crochus, une appétence pour certains secteurs, ou encore se rendre compte si la personne va s’entendre avec le reste de l’équipe, par le partage d’intérêts communs.

Si j’ai un petit doute car je trouve que le CV manque de clarté, je vais envoyer un petit mail pour avoir des précisions, par exemple sur l’expérience autour de PHP.

Et si toutes les cases sont cochées, je vais alors proposer un premier entretien, à distance, d’environ 1h. Le programme de l’entretien est transmis avec l’invitation.

Premier entretien, découverte mutuelle

Je commence par me présenter, présenter Web and Cow (projets, clients, équipe, poste) puis je donne la parole au candidat. Et là j’ai envie d’une seule chose : « qu’il cause », et « qu’il cause bien ».

Je veux qu’il soit capable de m’expliquer son parcours, ses projets, ses expériences. Je vais le questionner sur :

  • Les problématiques métier adressées
  • Les solutions techniques mises en œuvre
  • Les échanges au sein d’une équipe
  • Les échanges avec le client ou l’utilisateur final
  • Les process et outils de gestion de projet utilisés
  • Les difficultés rencontrées

Quelque part, je « contrôle » le contenu du CV, tout en vérifiant que la personne sait exprimer ses idées, décrire une situation, expliquer un peu de technique, utiliser le bon vocabulaire, etc. Je ne pose pas de questions pièges, je joue juste le curieux sur le déroulé d’un projet, etc.

C’est un point très important pour moi. Dans le quotidien, on a besoin d’être capable d’expliquer une fonctionnalité, un problème technique, préciser un contexte, utiliser un vocabulaire métier, etc.

Ensuite, je pose quelques questions techniques, sur les compétences requises ET sur les compétences appréciées. On parle de CakePHP dans nos offres, sur notre site, sur nos réseaux sociaux. Est-ce que le candidat a fait l’effort de jeter un œil à la documentation. Sur les compétences requises, je peux être très précis, poser des questions sur l’actualité de PHP par exemple. Sur les compétences appréciées, je cherche à jauger la curiosité du candidat, sa capacité à préparer l’entretien. Je sais que si les bases techniques sont présentes, et que le candidat est curieux, alors, avec les ressources disponibles (internes ou externes), il saura progresser sur nos technologies.

Enfin, un échange libre, pour les centres d’intérêt et pour répondre à toutes les questions du candidat. Toujours bon signe aussi quand le candidat a préparé une ou deux questions pertinentes.

Si tout s’est bien passé, on peut passer au test technique.

Le test technique

Je cherche à évaluer la capacité du candidat à produire un code propre. Pour cela on utilise la plateforme Tainix (développée par les équipes de Web and Cow). Le candidat doit, en PHP :

  • Réaliser un challenge « débutant »
  • Réaliser un challenge « intermédiaire »
  • Réaliser 3 tests unitaires par challenge
  • En s’appuyant sur la sandbox proposée (en utilisant git et composer)

C’est à réaliser « à la maison » dans l’attente du second entretien, déjà positionné. J’estime qu’il faut 2 à 4h pour réaliser ce test. Toutes les ressources disponibles sur Tainix (et sur le web d’une manière générale !) sont à disposition : exemples de corrigés, exemples de tests unitaires, listing de bonnes pratiques à suivre.

Les tests ne présentent pas une complexité algorithmique « forte ». Ils permettent par contre de jauger le candidat sur sa capacité à résoudre un problème et organiser une solution.

En fait, je considère que le test est donc réalisé « en conditions réelles » :

  • Temps nécessaire pour réaliser un code de qualité
  • Exemples de code à disposition
  • Guide des bonnes pratiques à disposition

Forcément, cela demande plus de temps au candidat qu’un QCM de 30 minutes, mais je trouve ça plus intéressant. Je ne recherche pas quelqu’un qui connaît tout par cœur, je recherche quelqu’un qui sait découvrir un environnement de travail, s’inspirer d’exemples, se référer à des pratiques à suivre, faire une recherche, etc. Comme je le fais au quotidien avec mon équipe en place.

Le code produit est à nous transmettre au + tard la veille du second entretien. Celui-ci a lieu dans nos locaux, en présence du CTO.

Entretien technique

En plus du code produit dans le cadre du test technique, on demande au candidat de venir avec du code produit dans un autre projet, scolaire ou professionnel. Le but de cet entretien c’est de parler de code, de code, et de code. Cela dure entre 2 et 3h.

D’abord les challenges Tainix : qualité du code produit, respect des standards, organisation des objets créés, tests unitaires. On va souvent poser 2 questions :

  • Pourquoi ? Pourquoi avoir utilisé telle fonction, telle structure, telle logique, etc.
  • Qu’est-ce qu’on pourrait encore améliorer ? Bonnes pratiques, conventions, simplification des algorithmes, etc.

Sur le code produit en dehors de Tainix, on va poser des questions sur le contexte du projet, sur l’organisation des données, sur les choix d’architecture, l’organisation du code, etc.

En plus des compétences techniques, comme dans le premier entretien, on évalue la capacité du candidat à présenter son code, expliquer son projet, montrer qu’il le maîtrise.

Au quotidien, j’ai besoin que l’équipe technique s’approprie les projets sur lesquels elle travaille : le code bien sûr, mais aussi la compréhension du besoin métier.

Durant cet entretien, on va faire en sorte de travailler, voir « bidouiller » le code avec le candidat, pour lui montrer d’autres façons de faire, comment faire mieux par moments, quelle bonne pratique utiliser ou mieux respecter, etc. L’objectif c’est que ce temps d’entretien profite aussi au candidat, qu’il reparte en ayant progressé ou découvert quelque chose.

On garde toujours un temps aussi pour l’échange libre et répondre à toutes les questions du candidat.

La décision finale

La décision finale n’est jamais prise en direct à la fin de l’entretien, pour plusieurs raisons :

  • Plusieurs candidats à voir
  • Besoin de se poser pour prendre la bonne décision

Même s’il m’arrive de ne pas répondre à tous les CV entrants, là on fait un retour à tous les candidats qu’on a reçu. Et si la réponse est négative, on s’efforce de donner quelques pistes de progression sur les points qui nous ont manqué durant le ou les entretiens. Encore une fois, c’est un jugement vis-à-vis de notre process et ce à quoi nous apportons de l’importance. Dans une autre entreprise, cela peut être complètement différent.


Si récapitule, pour le candidat :

  • Envoi d’un CV (30 min ?)
  • Premier entretien de 1h à 1h30
  • Test technique à réaliser, 2 à 4h
  • Second entretien, 2h à 3h + temps de transport

Soit une fourchette de 5h à 10h à nous consacrer pour pouvoir intégrer l’équipe Web and Cow, qui en général s’étalent sur 2 à 4 semaines maximum. Est-ce beaucoup ou non ? Cela est difficile à évaluer. Je suis preneur d’éléments de comparaison 🙂

Une fois chez Web and Cow, nous avons un parcours d’intégration et des ressources techniques à disposition, organisées dans Notion. Mais bon c’est un autre sujet 😉

Et s’il y a d’autres questions auxquelles je n’ai pas répondu, n’hésitez pas à m’en faire part sur Twitter.

Ressources

Publié par Arthur Weill

Directeur de l’agence rennaise Web and Cow, directeur digital du Groupe Valorex, impliqué dans l'informatique et la programmation depuis plus de 10 ans.