Personnellement quand je recrute quelqu'un, je m'intéresse dans l'ordre à:
- La façon dont il/elle pense
- Le relationnel
- Un (tout petit) peu de technique pure
En premier le raisonnement parce que les outils, les langages, ça s'apprend. Quand on a l'esprit tordu, on ne peut souvent pas faire grand chose. Depuis que j'ai été embauché, j'ai connu pas mal de changements techniques (nouveaux frameworks, nouveaux languages, cvs -> svn -> git,...) et quand on est démerdard, ça ne pose pas de problème. Je préfère quelqu'un qui sache apprendre qu'une personne qui ait tous les buzzwords du moment sur son CV.
En général, il suffit de discuter un peu de problèmes sur lesquels la personne a pu travailler, ou bien lui demander quelle serait sa démarche face à tel soucis. On voit assez vite si le gars est logique dans sa tête ou pas et son niveau de culture "technique" (au sens large). Ce sur quoi il a pu bosser, ce qu'il connaît de la vraie vie. Exemple typique, l'un des meilleurs recrutement que j'ai fait c'est un gars qui venait de l'embarqué pour bosser sur du web. Il n'avait jamais fait de web (professionnellement). La plupart des cabinets l'auraient envoyé bouler. Mais en 10 min, on se rends compte qu'il touche un peu à tout. Face à un problème, il développe des petits outils pour gagner du temps. Il sait trouver de l'info, se former, il sait se qui se fait dans divers domaines. Bref, il apporte beaucoup.
Ensuite le relationnel parce que tu n'a vraiment pas envie de bosser avec un connard. Il y a des gens qui brillants mais incontrôlables voire carrément psychopathes. Je pense en particulier à un petit "terroriste" qui code la nuit, qui change du code qui marchait bien parce que "sa façon est meilleure" alors que 1) ça n'était pas prévu et ça met le projet en retard 2) avant ça marchait maintenant ça ne marche plus 3) il n'a pas jugé utile de prévenir qui que soit (surtout pas l'équipe de validation, faut pas déconner). Dans l'informatique, on ne travaille pas tout seul dans sa grotte donc il faut déjà être un minimum sociable, savoir communiquer/expliquer/donner de l'info et savoir écouter/comprendre. Beaucoup de soucis viennent de specs mal comprises, de questions non posées, d'informations perdues en cours de chaînes.
Je pose quand même une ou deux question un peu technique juste au cas où. Il y a des gens qui sont capables de pipoter de façon presque crédible si on ne gratte pas trop le vernis. Pas besoin d'aller chercher très loin, il suffit de prendre une techno sur laquelle il a bossé et de lui poser une question à laquelle quelqu'un qui a vraiment utilisé le truc (pas lu en diagonale un article sur la question) peut répondre. On voit tout de suite la différence entre celui qui a vaguement entendu parler d'un truc et qui se fait mousser et celui qui a mis les mains dans le cambouis. Le bullshit passe mal. Je préfère quelqu'un d'honnête qui admet ne pas savoir qu'un joueur de flûte soit disant capable de tout faire mais infoutu d'écrire un hello world.
Pour ce qui est des estimations, je dirais peu importe. Les estimations sont souvent fausses par contre chacun à tendance à se tromper toujours dans le même sens. Il y a les optimistes qui voient toujours un peu trop court et de l'autre côté les prudents qui se gardent une marge de sécurité qu'il n'utilisent souvent pas. A l'usage, on s'adapte. On voit rapidement du quel côté la personne penche et on fait en fonction. Et puis il ne faut pas oublier qu'une estimation reste une estimation. Il y a des aléas. Ca fait partie de la gestion de projet d'estimer les risques et de prévoir plus ou moins de marge en fonction de la complexité.
# Petite check list
Posté par Croconux . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 10.
Personnellement quand je recrute quelqu'un, je m'intéresse dans l'ordre à:
- La façon dont il/elle pense
- Le relationnel
- Un (tout petit) peu de technique pure
En premier le raisonnement parce que les outils, les langages, ça s'apprend. Quand on a l'esprit tordu, on ne peut souvent pas faire grand chose. Depuis que j'ai été embauché, j'ai connu pas mal de changements techniques (nouveaux frameworks, nouveaux languages, cvs -> svn -> git,...) et quand on est démerdard, ça ne pose pas de problème. Je préfère quelqu'un qui sache apprendre qu'une personne qui ait tous les buzzwords du moment sur son CV.
En général, il suffit de discuter un peu de problèmes sur lesquels la personne a pu travailler, ou bien lui demander quelle serait sa démarche face à tel soucis. On voit assez vite si le gars est logique dans sa tête ou pas et son niveau de culture "technique" (au sens large). Ce sur quoi il a pu bosser, ce qu'il connaît de la vraie vie. Exemple typique, l'un des meilleurs recrutement que j'ai fait c'est un gars qui venait de l'embarqué pour bosser sur du web. Il n'avait jamais fait de web (professionnellement). La plupart des cabinets l'auraient envoyé bouler. Mais en 10 min, on se rends compte qu'il touche un peu à tout. Face à un problème, il développe des petits outils pour gagner du temps. Il sait trouver de l'info, se former, il sait se qui se fait dans divers domaines. Bref, il apporte beaucoup.
Ensuite le relationnel parce que tu n'a vraiment pas envie de bosser avec un connard. Il y a des gens qui brillants mais incontrôlables voire carrément psychopathes. Je pense en particulier à un petit "terroriste" qui code la nuit, qui change du code qui marchait bien parce que "sa façon est meilleure" alors que 1) ça n'était pas prévu et ça met le projet en retard 2) avant ça marchait maintenant ça ne marche plus 3) il n'a pas jugé utile de prévenir qui que soit (surtout pas l'équipe de validation, faut pas déconner). Dans l'informatique, on ne travaille pas tout seul dans sa grotte donc il faut déjà être un minimum sociable, savoir communiquer/expliquer/donner de l'info et savoir écouter/comprendre. Beaucoup de soucis viennent de specs mal comprises, de questions non posées, d'informations perdues en cours de chaînes.
Je pose quand même une ou deux question un peu technique juste au cas où. Il y a des gens qui sont capables de pipoter de façon presque crédible si on ne gratte pas trop le vernis. Pas besoin d'aller chercher très loin, il suffit de prendre une techno sur laquelle il a bossé et de lui poser une question à laquelle quelqu'un qui a vraiment utilisé le truc (pas lu en diagonale un article sur la question) peut répondre. On voit tout de suite la différence entre celui qui a vaguement entendu parler d'un truc et qui se fait mousser et celui qui a mis les mains dans le cambouis. Le bullshit passe mal. Je préfère quelqu'un d'honnête qui admet ne pas savoir qu'un joueur de flûte soit disant capable de tout faire mais infoutu d'écrire un hello world.
Pour ce qui est des estimations, je dirais peu importe. Les estimations sont souvent fausses par contre chacun à tendance à se tromper toujours dans le même sens. Il y a les optimistes qui voient toujours un peu trop court et de l'autre côté les prudents qui se gardent une marge de sécurité qu'il n'utilisent souvent pas. A l'usage, on s'adapte. On voit rapidement du quel côté la personne penche et on fait en fonction. Et puis il ne faut pas oublier qu'une estimation reste une estimation. Il y a des aléas. Ca fait partie de la gestion de projet d'estimer les risques et de prévoir plus ou moins de marge en fonction de la complexité.