Entretien - HOWTO.md

Intro

Il y a quelques mois, avec mon chef de projet, nous avons reçu en entretien un dev senior, gros CV, passage par la silicon Valley notamment. En tant que Lead Dev, j’avais la lourde tâche de le challenger techniquement, vu la richesse de ses expériences, j’en étais même venu à me demander si j’étais légitime de lui poser des questions techniques.
On s’attendait à du lourd… c’était le cas, pas dans le bon sens.

Cet article est donc destiné à tous les développeurs qui vont passer un entretien, car c’est un exercice loin d’être aisé. Pour en avoir passé plus de 20, notamment avec des SSII au point de connaitre mon speech sur le bout des doigts, je vous présente quelques astuces, et surtout les choses à éviter.

La préparation

Faites des recherches sur la société, son histoire ses produits, sa situation actuelle. Le must serait de faire des recherchers sur des médias plus économiques, cela permet de savoir si la santé de la société est optimale, et sa position par rapport à ses concurrents. Cette recherche a deux objectifs, savoir où vous mettez les pieds, la seconde s’est de pouvoir poser des questions au cours de l’entretien, je vous explique après pourquoi.

Le CV

Normalement, à ce stade le recruteur a déjà vu et fait passer votre CV, vous avez toujours la possibilité de fournir une mise à jour.
A eviter, le style sobre limite Europe de l’est, tout blanc, et noir (comme ce blog…). Un peu de couleur, attire l’oeil, sans aller dans l’excès toutefois. Si vous êtes expérimenté, rien d’illogique d’avoir plusieurs pages, par contre vaut mieux éviter de trop s’étendre sur les choses qui ont plus de 5 ans.

L’entretien

Savoir se présenter

N’abusez pas du “jejejejejejejejejeje”, il faut savoir varier ! Cela demande une certaine souplesse, mais dès que l’on a quelques synonymes en stock, cela permet de jongler. Voyez votre speech comme une histoire, et comme toute histoire si elle est pénible, votre auditoire va décrocher. Sans verser dans le discours politique, user de la ponctuation et des intonations, ça permet de tenir en haleine ceux qui écoutent, et de rattraper ceux qui ont décroché. Evitez aussi de vous attarder sur des expériences qui s’éloignent trop du métier de la société visée, ou si elles sont trop vieilles.

Formation/certif

Un peu comme les badges Pokémon, les formations certifiantes c’est le must. Par contre, c’est à double tranchant, par exemple, si vous avez passé une certification Java, précisez la version, le candidat que nous avions reçu, avait passé la version 1…qui datait de 1997 ! Pour avoir commencé à potasser la certif Java (version 7, oui j’ai honte…), je sais que ça demande un investissement personnel assez élevé, donc rien que de dire que vous vous y interessez peut être un plus.

Vos expériences

Il faut toujours rester simple et concis : technos, taille de l’équipe, métier du client, deadline. Que Maurice du service compta vous a ramené un soir et que ça soit votre meilleur souvenir ? Who cares ?
Aussi, ça ne sert à rien de répéter ce qui est déjà écrit, il faut alimenter votre discours avec des détails.

Les questions techniques

“Je ne sais pas” est une réponse valable, personne ne sait tout, et il vaut mieux ! Si vous savez déjà utiliser toutes les technos du client, vous allez vous ennuyer au bout de trois semaines. La réponse top quand on ne sait pas: “je ne l’ai pas utilisé mais je sais que c’est machin-machin” ou “je ne sais pas, c’est quoi ?”. Et pour cela, il faut avant tout s’être renseigné sur la stack technique du client, et avoir fait le comparatif avec ce que vous maitrisez ou connaissez.

Github

Votre repo GitHub, c’est votre carte de visite, vous n’êtes pas obligé d’en avoir un mais c’est quand même mieux, mais comme le reste, c’est à double tranchant. Donc faites le vivre, par exemple avec des POC mais sur des technos actuelles, les stacks dépassées ou plus en vogue ne sont pas nécessaires.
Attention gros piège !!! J’ai proposé au candidat de faire une relecture du code d’un projet sur son repo. Ce n’était pas parce que j’étais en manque de Pull Request, mais pour voir ses réactions face aux remarques sur son travail. Je n’allais pas être favorable au recrutement de quelqu’un qui n’accepte pas la critique. Et la j’ai gagné au jackpot, le candidat a répondu à côté à mes remarques. C’était évidemment un piège. Concernant l’usage de Git, ne dites jamais mais vraiment jamais que vous ne suivez pas les precos du client, c’est un synonyme de suicide professionnel.

Je fais une apparté à ce sujet, nous sommes des développeurs, les ouvriers du 21eme siècle, et nous sommes payés pour produire des lignes de code. Une partie de notre travail consiste à être critique vis à vis du code de nos collaborateurs (aka Pull Request). Evidemment il ne faut pas prendre les remarques à titre personnel. J’ai l’habitude de dire en entretien que vous n'êtes pas votre code, ben en fait un peu quand même, voire carrément vous êtes votre code.
Ce que l’on produit reflète nos connaissances du langage, nos expériences passées, et notre façon de résoudre des problèmes algorithmiques. On peut rajouter que le code a un style, c’est comme une histoire (cf. Clean Code), et comme chaque histoire l’auteur a un style propre à lui.
Donc un conseil, ne prenez pas les remarques ou questions sur votre code à titre personnel. Si vous faites face à une question que vous estimez stupide, c’est peut venir du fait que votre code n’est pas assez clair…

La société/le client

Voyez l’entretien comme un rendez-vous galant, et votre objectif c’est d’avoir la possibilité de conclure.
Comme quand vous draguez, si vous faites preuve d’égocentrisme, c’est mort!
Interessez-vous à la personne que vous avez en face, forcez-vous si il faut, en lui posant des questions.
Quand je n’avais pas d’idée, j’utilisais mes jokers : “Et vos concurrents ?” “Vous vendez a l’international ?”

le salaire

Ce point est généralement abordé avec les RHs, et managers, pas forcément lors de l’entretien.
Il n’y a rien de tabou à parler d’argent, vous êtes là pour obtenir une rémunération et le client pour payer pour un service.
Si vous n’arrivez pas à mesurer vos prétentions salariales, prenez votre ancien salaire et ajoutez 15-20% (au choix).
Evitez de les changez au cours des échanges, c’est ce qui s’est passé avec le candidat que j’avais vu, et ça m’a paru louche.

La fin de l’entretien :

Vous risquez moins de vous planter à ce stade, le mal est déjà fait de toute façon.
Concluez en ré-affirmant votre motivation : pourquoi ce job vous interésse ?
C’est peut grâce à la stack technique ? Le métier ? Les perspectives d’évolution ? L’image de marque.
Il ne faut pas hésiter à dire pourquoi vous devez être choisi : l’une de vos expérience colle avec le stack technique ? Vous allez apporter un regard neuf ? etc.

Après l’entretien

Comme quand on drague, on se recontacte 3-4 jours après, pas avant. Un p’tit mail pour faire le résumé de l’entretien, en citant les personnes que vous avez croisé, et ré-affirmez les raisons pour lesquelles vous êtes absolument fait pour ce poste.

Le refus

Ne pas être sélectionné ne veut pas nécessairement dire que vous avez échoué, vous n’êtes peut-être pas la personne, ou le profil recherché à cet instant, vous êtes peut-être trop cher ?
Tant pis c’est la vie, un petit mail pour répondre, avec politesse, et qui sait peut-etre dans 6 mois ils vous recontacteront.
C’est ce qui s’est passé avec ma société, après l’échec avec le Dev Senior, on a rappelé le candidat que l’on avait vu 2 semaines auparavant, et il s’avère que c’est un très bon élément.
Le maitre mot c’est de Rester professionnel, quoi qu’il arrive, question sexiste, raciste, comportement déplacé ?
Réagissez en professionnel, car vous êtes un professionnel (si ! si !) et qu’accessoirement le monde de l’info est très très petit.
Autre conseil, de mon prof de fac (2006…) : N’envoyez jamais un mail sous le coup de l’émotion. Relisez vous 2 fois, répondre par un scud, ça vous soulagera sur le moment, mais ça ne vous apportera rien de bon.