Follow

J'ai donné un entretien d'embauche pour un poste de dev. Au lieu de demander un exercice de code, je suis allé voir le Github de la personne, j'ai trouvé un de ces projets récents, avec des points qui pouvaient être améliorés, et on a fait une relecture collaborative de son code.

BIen plus efficace que l'exercice de code, parce qu'on voit :
1. comment la personne collabore
2. comment elle subit la critique
3. si elle repère ses propres bugs
4. si elle sait expliquer ses choix d'implémentation

Y a aussi des défauts :
- impossible de reproduire l'interview telle quelle pour d'autres candidats, donc c'est nécessairement biaisé
- la personne peut avoir du mal à se souvenir de son projet, s'il est ancien (ça peut être intéressant de la prévenir quelques jours avant qu'on va regarder tel projet ensemble)
- plein de projets ne sont pas écrits de manière qualitative, donc les défauts présents peuvent juste être signes de l'envie d'aller vite, pas la qualité réelle du code produit en général

Bref, à réessayer pour les prochaines fois.

Et vous, qu'en pensez-vous ? Comment faites-vous passer vos entretiens techniques, pour tester les compétences de dev sans passer par l'exercice d'algo bête et méchant ?

@bnjbvr ça ne rend pas github obligatoire , ou tu aurait fait de même avec une autre forge ?

@usul tant que le code est open-source, peu importe la forge. J'aurais compté des points libristes en plus si ça avait été sur un Gitlab ou un Gitea auto hébergé :)

Effectivement, ça implique que la personne ait mis en ligne du code libre, et ce n'est pas toujours le cas.

@bnjbvr Bah j'trouve que c'est intéressant comme façon de faire 👍
Après, comme j'ai jamais eu à faire passer des entretiens… 🤷

@bnjbvr Ça dépend ce que tu veux tester : si c'est comment il code, comment il construit son raisonnement, etc. un exercice en binôme me semble plus approprié. Si c'est plus l'humain, son regard critique (un projet "non-qualité" n'est pas un problème s'il est capable de pointer ça du doigt par exemple), le projet perso passé en revu est bien. Je préfère le deuxième exercice, l'humain m'est plus important que la technique et le ou la candidat⋅e est généralement moins stressé⋅e.

@bnjbvr Par contre il ne faut pas que ça devienne un exercice "incontournable" au point que ça désavantage les candidat⋅es n'ayant pas de projets libres !

@marien
C'est aussi un pré critère de sélection en soi, hé hé. Mais oui, ça peut être limitant.

@bnjbvr

Dans ma boîte on fait un truc très semblable. On a un jeu de dés simple mal implémenté (dans plein de langages)
Et on demande au candidat d'ajouter une fonctionnalité (dans son langage préféré)

Points bonus s'il pense à:
* demander s'il y a des tests
* refactorer *avant* de rajouter du code

Dans tous les cas on discute ensemble du refactoring.

Ça permet la reproductibilité.

@bnjbvr Autre avantage: on voit comment le candidat se comporte dans du code *existant*, et s'il sait comprendre et implémenter les spécifications.

@dmerej Super idée, ça me semble encore mieux, j'essayerai ça la prochaine fois, merci pour l'inspiration :)

Sign in to participate in the conversation
TUTUT DELIRE PARTY

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!