Entretien tech pour start-up: quelles questions poser? 26/10/2017 0 4 minutes de lecture
Une fois que le fameux product-market fit trouvé et la levée bouclée, le plus difficile reste à faire: se constituer une équipe talentueuse pour continuer à accélérer. Mais pour cela il n’est pas toujours si simple de sélectionner les bons candidats.
![image](https://www.frenchweb.fr/wp-content/uploads/2017/10/A.jpeg)
Recruter prend un temps considérable et il n’est pas toujours possible de faire passer 6 entretiens comme dans les cabinets de conseil en stratégie.
Au cours de ma précédente expérience en tant que CTO chez Zilok puis OuiCar j’ai dû faire passer largement plus d’une centaine d’entretiens tech pour des postes variés comme:
- Dev full stack
- Back-end
- Front-end
- Intégrateur
- Respo SEO
- Data scientist
- Dev iOS / Android
- CTO (à la fin!)
J’ai fait sans aucune doute des erreurs de recrutement. Mais j’ai en tout cas essayé de faire évoluer les questions que je posais en entretien pour essayer de qualifier plus rapidement et plus efficacement les candidats.
Mon objectif était de recruter des profils bons techniquement, attirés par le produit, motivés par le projet et capables de bien travailler en équipe.
1. Question tech: pourriez-vous me citer et m’expliquer quelques design patterns?
Cette question un peu académique a pour objectif non pas forcément de vérifier si le candidat connaissait la liste intégrale des design patterns, mais plus pour vérifier si les problématiques de conception intéressent le candidat.
![image](https://www.frenchweb.fr/wp-content/uploads/2017/10/carte.jpeg)
certains geek pourront comprendre l’image :)
Je fus assez surpris de voir à quel point cette notion est souvent complètement inconnue des candidats.
Très fréquemment le candidat me parle d’UI car il pense que je lui parle de design!
Le plus cité curieusement n’est pas le singleton (2ème position) mais le MVC (qui n’est un pas un pattern élémentaire mais une combinaison des patterns observateur, stratégie et composite).
J’ai même eu des candidats iOS qui ne connaissaient pas (ou qui n’avaient pas mis de mot dessus) le pattern de delegation, alors que c’est utilisé partout.
Cette question filtre je trouve assez bien les candidats. Si vous recherchez des profils qui s’intéressent un minimum à la conception il est normal de poser ce genre de questions, qui a le mérite d’être language agnostic.
2. Question produit: quelles sont vos applications préférées?
Question ouverte pour apprécier et jauger la curiosité du candidat. Si c’est pour un dev mobile je n’imaginais pas recruter quelqu’un qui n’aime pas essayer beaucoup d’applications et noter les points qui l’ont marqué. Parfois je formulais la question un peu différemment:
Quelle application auriez-vous été fier d’avoir créée et pourquoi ?
Ce que je cherche à évaluer c’est le niveau d’importance donné par le candidat au produit, aux détails, aux workflows…
Quelqu’un qui réfléchit aussi aux problèmes et pas seulement aux solutions. Aimer le produit est essentiel également pour communiquer efficacement avec les autres services, comprendre les priorités, et de savoir tester son code de manière pertinente.
3. Question motivation: qu’est-ce que tu améliorerais sur le service?
Cette question a pour objectif de voir si le candidat a préparé l’entretien. C’est évidemment pas simple car il faut se mettre à la place d’un «vrai» utilisateur mais le plus important à mon sens est d’y avoir réfléchi.
J’ai reçu trop de candidats qui avaient à peine testé le service. Moins de 1 sur 2 a pris le temps de s’y inscrire.
Prendre des candidats qui ne sont pas motivés par la finalité du service est pour moi une grosse erreur, encore plus s’ils sont bons techniquement! C’est la voie royale à la démotivation, à de l’over-engineering,…
Donc je n’attendais pas des réponses pour remplir mon backlog mais pour jauger de l’implication future du candidat.
4. Question existentielle: qu’y a-t-il de difficile dans votre métier?
La question paraît simple mais je pense que c’est la plus difficile de toutes! Elle nécessite d’avoir du recul sur son métier et d’y avoir un peu réfléchi au préalable.
Elle permet de voir et de déceler les candidats qui cherchent à s’améliorer : connaître les difficultés c’est d’abord vouloir progresser.
A cause de cette question un recruteur m’a même affirmé que mes questions étaient trop difficiles!
La réponse obtenue la plus fréquente (50% des cas au moins): «rien, tout est facile dans ce que je fais».
Cette réponse vient sûrement du fait que la question est peut-être pas très bien posée mais souligne également que chaque candidat aimerait m’impressionner en prétendant savoir tout faire.
En général je réponds de la manière suivante:
Alors si tout est facile pourquoi je devrais recruter un profil comme le votre à 60k, plutôt que le premier venu au smic ?
Pas très sympa de ma part, mais c’est pour voir les réactions.
Mais j’ai eu parfois de très bonnes réponses notamment sur iOS à propos de la difficulté de la synchronisation des données entre l’application et le serveur.
5. Question de lecture: faire une petite «carte» sur le code
Bon celle-là je vais être honnête je ne l’ai pas posée mais elle m’a été soufflée par un (très bon) candidat CTO que j’ai reçu en entretien pour mon remplacement.
L’objectif est de permettre au candidat d’avoir une idée du code source et de voir comment il réagit face à un nouvel environnement.
Egalement cela sert de test sur sa capacité à travailler sur un code qui n’est pas le sien. Si le temps le permet c’est encore mieux s’il peut travailler de concert avec un membre de l’équipe tech pour voir (brièvement) sa capacité à travailler en équipe.
Ce que j’ai appris avec le temps c’est que TOUT développeur préfère écrire du code plutôt que de lire du code. D’ailleurs c’est pour cela je pense que l’on entend tellement de «c’est pas propre ce code, c’est de la m…». C’est parfois justifié mais cela montre aussi que la personne a du mal à s’intégrer dans un contexte inconnu.
Conclusion
Faire des bons choix en recrutement est clé pour la réussite de sa boîte et c’est un exercice délicat.
Je n’ai pas abordé ici des questions spécifiques suivant les spécialités des dev, mais évidemment on doit rajouter quelques questions techniques.
Pour finir ce que j’ai retenu des candidats que je trouvais très bons c’est qu’ils partageaient souvent la même priorité dans leurs motivations:
la volonté d’être dans un environnement où ils pourront apprendre et progresser.
Si le candidat parle de cela c’est bon signe.
Bon courage!