Joel on Software   Joël à propos de logiciel

D'autres articles de "Joel on Software" en Français

D'autres articles de "Joel on Software" en Anglais

Contacter l'auteur (En Anglais uniquement)

Embaucher est vital pour Fog Creek Software. Dans notre domaine, il y a trois types de personnes. En bas de l'échelle, ce sont les masses incultes, dépourvues des compétences élémentaires requises pour le poste. Ceux-là sont faciles à repérer et à éliminer ; en général, il suffit de lire leur CV et de leur poser deux ou trois questions. Tout en haut de l'échelle, ce sont les superstars, ceux qui sont capables de vous écrire un compilateur lisp en assembleur pour Palm Pilot, juste pour se détendre un week-end. Et au milieu, il y a un tas de «maybes», qui semble-t-il pourraient peut-être apporter une petite contribution. La difficulté, c'est de différencier les superstars des «maybes», parce que chez Fog Creek Software, on n'embauche que les superstars. Voici quelques techniques.

D'abord, la qualité numéro un pour se faire embaucher chez Fog Creek :

Etre intelligent et
Aller au bout des choses

Voilà. C'est tout ce qui compte. S'en souvenir. Se le réciter tous les soirs avant de se coucher. Nous cherchons des gens ayant des aptitudes, pas des connaissances particulières. De toute façon, quelles que soient les compétences qu'un individu apporte aujourd'hui, elles seront complètement dépassées dans pas longtemps. Mieux vaut quelqu'un capable d'apprendre n'importe quelle technologie, plutôt que quelqu'un qui, par hasard, maîtrise justement la programmation SQL.

Définir l'intelligence n'est pas choses aisée. Mais elle peut être décelée lors d'un entretien grâce à quelques questions, comme nous allons le voir. Aller au bout des choses est crucial. Les personnes intelligentes qui ne vont pas au bout des choses ont souvent un doctorat du troisième cycle et travaillent dans une grosse boîte, où personne n'écoute leurs considérations dénuées de tout sens pratique. Elles préfèrent se lancer dans des considérations sur un problème théorique plutôt que s'assurer que les commandes partent à l'heure. Ces individus se reconnaissent facilement à leur propension à trouver une similitude théorique entre deux concepts totalement divergents. Par exemple, ils vont dire : «Les tableurs sont juste un cas particulier des langages de programmation», disparaître pendant une semaine et revenir avec un article brillant, passionnant, sur le calcul théorique des attributs linguistiques d'un tableur comme langage de programmation. Brillant, mais inutile.

Maintenant, ceux qui vont au bout des choses sans intelligence font des trucs débiles en oubliant apparemment de réfléchir, ce qui oblige quelqu'un d'autre à venir réparer les dégâts. Ceux-là sont en fait des charges pour l'entreprise : non seulement ils ne lui apportent rien, mais ils consomment le temps des collaborateurs efficaces. C'est le genre de personnes à écrire des tonnes de code dans tous les sens, plutôt que de créer une sous procédure. Le boulot est fait, simplement il n'est pas fait de manière la plus rusée.

La règle essentielle en entretien :

Décider immédiatement

L'entretien doit déboucher sur une décision. Les seules alternatives sont : On le prend ou Au suivant. Là, allumer son PC et envoyer le rapport au recruteur. Le sujet du message doit être le nom du candidat. La première ligne doit être : On le prend ou Au suivant. Ensuite, justifier sa décision en 2 paragraphes.

Il n'y a pas d'autres alternatives. Ne jamais déclarer : «On le prend, mais pas dans mon équipe». Cela sous-entend que le candidat n'est pas assez intelligent pour vous, mais peut-être assez pour les loosers des autres équipes. C'est fort impoli. Si ça vous démange de dire «On le prend, mais pas pour mon équipe», traduisez automatiquement par «Au suivant», et tout ira bien. Si vous avez le candidat idéal pour une tâche particulière, mais qui ne serait pas bon dans une autre équipe, c'est un Au suivant! Tout va tellement vite qu'on a besoin de gens qui peuvent être efficaces n'importe où. Si vous tombez sur un singe intelligent, très fort, mais vraiment très fort en SQL, mais qui n'apprendra jamais rien d'autre : Au suivant! Pas d'avenir pour lui chez Fog Creek.

Ne jamais dire : peut-être, je ne sais pas... Cela signifie : Au suivant! C'est beaucoup plus facile qu'on ne le pense. Difficile à décider? Dire non, simplement. De la même manière, si vous n'avez pas d'opinion, cela signifie : Au suivant! Ne jamais hésiter : «Oui, c'est bon, je pense, quoi que je me demande si...». C'est un «Au suivant!»

Il est important de se souvenir que : il vaut mieux rejeter un bonne candidature qu'en accepter une mauvaise. Un mauvais choix va vous coûter beaucoup, en argent et en temps - celui que les autres vont perdre à corriger les bugs. En cas de doute, quel qu'il soit, c'est :  Au suivant!

Lorsque vous conduisez un entretien, ne vous préoccupez pas du fait que, si vous rejetez plein de monde, Fog Creek ne va trouver personne, au final. Ce n'est pas votre problème. C'est le problème des ressources humaines, c'est le problème de Joel, mais ce n'est pas votre problème. Gardez en tête cette question : qu'est-ce qui est pire, une boîte médiocre pleine de guignols, ou une boîte qui reste petite mais excellente? C'est bien sûr important de dénicher de bons candidats, et tout le monde doit se sentir concerné par la recherche et le recrutement de gens intelligents et «qui vont au bout des choses». Mais lors des entretiens, il faut faire comme si des foules de bons candidats se bousculaient pour rentrer chez Fog Creek. Ne jamais abaisser son niveau d'exigences, aussi difficile qu'il paraisse de trouver de bons candidats.

Mais comment prendre cette difficile décision? Il faut simplement se demander en permanence, pendant l'entretien : ce gars-là est-il intelligent? Ce gars- làva-t-il au bout des choses? Pour être en mesure de donner une réponse, il va falloir poser les bonnes questions.

Juste pour rigoler un peu, voilà la pire des questions à poser : «Quelle est la différence entre varchar et varchar 2 dans Oracle 8i?» C'est une question terrible. Il n'y a aucune corrélation possible et imaginable entre les personnes qui connaissent justement la réponse - parfaitement inutile - à cette question, et celles que Fog Creek souhaite embaucher. Qui en a quelque chose à faire, de la différence? Il faut 15 secondes pour trouver la réponse sur le web.

En fait, il y a des questions encore pires. J'y reviendrai plus tard.

Donc, nous en arrivons maintenant à la partie rigolote : les questions à poser en entretien. Cette liste de questions provient de mon premier boulot chez Microsoft. En fait, il y a des centaines de questions célèbres venant de chez Microsoft. Chacun a la série de questions qu'il préfère. A vous aussi de développer les questions et un style d'entretien qui vous aidera à prendre la décision «On le prend/Au suivant» Voilà quelques-unes des techniques que j'ai utilisées avec succès.

Avant l'entretien, je lis le CV des candidats et je jette sur papier un plan d'entretien. Il s'agit simplement de la liste des questions que je veux poser. Voici le plan type d'un entretien pour un poste de programmeur.

Avant l'entretien, je suis extrêmement attentif à éviter tout ce qui pourrait risquer de me donner des préjugés sur le candidat. Si l'on considère le candidat comme intelligent avant même qu'il n'entre dans la pièce, simplement parce qu'il est thésard et Polytechnicien (ou parce qu'il a un Ph.D. du MIT), alors rien de ce qu'il pourra dire en une heure ne nous fera revenir sur cette idée préconçue. Si l'on considère d'emblée que le candidat est un gros nul, rien de ce qu'il pourra dire ne nous fera revoir cette impression initiale. Un entretien est comme une balance très, très sensible -- c'est très difficile de juger quelqu'un sur une entrevue d'une heure, ça peut donner l'impression de jouer à la roulette russe. Mais en connaître un petit peu sur le candidat à l'avance, c'est comme rajouter un gros poids sur un plateau de la balance. Un jour, juste avant un entretien, une chargée du recrutement entra dans mon bureau. «Tu vas adorer ce gars», dit-elle. Qu'est-ce que ça m'a énervé! J'aurais dû lui dire «eh bien si tu es si sûre que je vais l'adorer, pourquoi tu ne l'embauches pas directement, plutôt que me faire perdre mon temps avec cet entretien?». Mais j'étais jeune et naïf et j'ai assuré l'entretien. A chaque propos pas très-intelligent que le candidat tenait, je me disais «bon, ça doit être l'exception qui confirme la règle». Je le regardais à travers des lunettes roses. J'ai fini par dire «On le prend», même si il était nul. Et vous savez quoi? Tous les autres interviewers qui l'ont rencontré on dit « Au suivant». Donc : ne pas écouter les chargés de recrutement ; ne pas poser de questions sur les candidats avant de les recevoir ; et ne jamais, au grand jamais, parler des candidats avec un autre recruteur avant que chacun n'ait pris sa décision de manière indépendante. C'est une méthode scientifique!

La phase d'Introduction de l'entretien a pour but de mettre le candidat à l'aise. Je passe environs 30 secondes à lui présenter qui je suis et comment va se dérouler l'interview. Je le rassure systématiquement sur le fait que ce qui nous intéresse est la manière dont il résout les problèmes, pas la réponse exacte. A propos, vous ne devez pas être séparé du candidat par un bureau. Cela crée une barrière formelle et ne met pas le candidat à l'aise. Il vaut mieux déplacer le bureau contre le mur, ou bien en faire le tour et s'asseoir de l'autre côté avec le candidat ; cela aide à le mettre à l'aise. Le résultat en est un meilleur entretien, parce que moins déformé par la nervosité.

La seconde partie est une question sur les derniers projets pour lesquels le candidat a travaillé. Pour les candidats étudiants, interrogez-les sur leur projet de fin d'étude, si ils en ont réalisé un, ou sur une des matières de leur cursus qui aurait donné lieu à un projet et qu'ils ont vraiment appréciée. Par exemple, je demanderais «quel cours avez-vous préféré ce dernier semestre? Ce n'est pas nécessairement un cours d'informatique». En fait, je suis en général plutôt content si ils en choisissent un qui ne soit pas lié à l'informatique. Parfois en regardant les matières de leur cursus, on voit bien qu'ils ont vraiment choisi le moins de cours d'informatique possible, mais beaucoup de matières liées à la musique. Et ils vous affirment que leur cours favori était celui sur les Bases de Données Orientées Objet. Ouais, bon. J'aurais mieux aimé qu'ils reconnaissent préférer la musique aux ordinateurs, plutôt que de fayotter.

Si le candidat a déjà une expérience, vous pouvez parler de son job précédent.

En posant cette question, je recherche une chose : la passion. Une fois que vous avez identifié un des projets pour lequel la personne a travaillé récemment, voilà les signes positifs :

• Les candidats commencent à s'exciter en en parlant ; leur débit s'accélère, il se mettent à gesticuler. Cela montre que, si quelque chose les intéresse, ils en deviendront passionnés. Il y a beaucoup trop de personnes capables de travailler sur quelque chose tout en n'en ayant rien à faire. Même si ils se montrent passionnément négatifs, cela peut être un aussi bon signe. «J'ai travaillé à installer Foo Bar Mark II pour mon employeur précédent, mais c'était vraiment de la daube!». Ces candidats-là, on les prend. Les mauvais candidats n'en ont rien à faire de rien, et ne montrent aucune manifestation d'enthousiasme pendant l'entretien. Un signe révélateur de passion, c'est quand un candidat commence à en parler et oublie momentanément qu'il est en entretien. Parfois je reçois des candidats que la situation d'entretien rend vraiment nerveux -- c'est normal, je n'en tiens jamais compte. Mais si on les fait parler d'Art Monochrome Numérique, ils commencent à s'exciter et perdent tout signe de nervosité. C'est bien. J'aime les gens passionnés, qui prennent les chose à coeur (pour voir un exemple d'Art Monochrome Numérique, essayez de retirer le câble de votre moniteur).
• Ils sont attentifs à expliquer les choses. J'ai refusé des candidats pour la raison que, en parlant de leur dernier projet, ils ne parvenaient pas à l'expliquer en des termes compréhensibles par une personne normale. Les ingénieurs supposent souvent que tout le monde connaît le théorème de Bates ou les axiomes de Peano. Si ils commencent à déraper, il faut les arrêter et leur demander «Soyez gentil, pouvez-vous, juste pour l'intérêt de l'exercice, expliquer cela en des termes que ma grand-mère pourrait comprendre». Là, il y en a beaucoup qui vont continuer à utiliser leur jargon et échouer à se faire comprendre. GONG!
• Dans le cas d'un projet en équipe, chercher les signes montrant qu'ils ont joué un rôle de leader. Admettons qu'un candidat dise : «On travaillait sur X, mais le chef disait Y et le client Z». Je demanderais «Alors qu'avez vous fait?». Une réponse satisfaisante pourrait être : «J'ai réuni les autres membres de l'équipe et nous avons écrit une proposition...». Une mauvaise réponse serait : «Eh bien, il n'y avait rien que je puisse faire. La situation était sans issue». Souvenez-vous : Intelligence, et «Aller au bout des choses». Un bon moyen de dire si quelqu'un Va au bout des choses est de voir si il a eu tendance à aller au bout des choses dans le passé. En fait, on peut directement demander de donner un exemple récent au cours duquel les candidats ont pris un rôle de leadership et sont allés au bout de quelque chose -- vaincu l'inertie d'une institution, par exemple.

OK, le troisième point de cette liste est la question impossible. Ca, c'est amusant. L'idée est de poser une question à laquelle il n'y a pas de réponse possible, juste pour voir comment ils s'en sortent. «Combien y a-t-il d'optométristes à Lyon?» «Combien de tonnes pèse le Sacré-cœur?» «Combien de stations-service à Bruxelles?» «Combien d'accordeurs de piano à Paris?»

• Les candidats intelligents se rendent compte qu'ils ne sont pas interrogés sur leurs connaissances, et plongent dans le jeu des estimations. «Voyons, la population de Bruxelles est d'à peu près 1 million. Chaque personne a en moyenne une voiture....». Ce n'est pas important si ils ont tout faux. L'important, c'est qu'ils aient attaqué le problème avec enthousiasme. Ils vont peut-être essayer de deviner la capacité d'une station-service. «Alors, cela prend 4 minutes à faire le plein, les stations-service ont environs 10 pompes et sont ouvertes 18 heures par jour...». Ils peuvent essayer de faire une estimation géographique. Parfois, ils vont vous surprendre par leur créativité, ou bien ils vont vous demander l'annuaire téléphonique de Bruxelles. Ce sont de bons signes.
• Les candidats pas intelligents seront déstabilisés et énervés . Ils vont vous regarder comme si vous arriviez de Mars. Vous allez avoir à les guider. «Alors, si vous aviez à reconstruire Bruxelles, combien de stations-service y mettriez-vous?» «Combien de temps pour faire un plein?». Et encore, vous allez devoir continuer à les tenir par la main, alors qu'ils resteront stupidement assis en attendant que vous les tiriez d'affaire. Ces gens ne savent pas résoudre les problèmes, et nous n'en voulons pas dans notre compagnie.

Pour les questions de programmation, je demande aux candidats d'écrire une petite fonction en C. Voilà les problèmes que je pose, typiquement :

1. Inverser une chaîne de caractères sur place
2. Inverser une liste liée
3. Compter tous les bits présents dans un octet
4. Recherche binaire
5. Trouver le run le plus long dans une chaîne de caractères
6. atoi
7. itoa (excellent, parce qu'ils faut utiliser une stack ou strrev)

Il ne faut pas donner un problème qui prenne plus de 5 lignes de code ; ils n'auraient pas le temps de le faire.

Regardons-en quelques uns en détail. N°1: Inverser une chaîne de caractères sur place. Aucun des candidats que j'ai vus dans ma vie n'a réussi celui-là du premier coup. Sans exception, ils essaient d'allouer un autre buffer et d'inverser la chaîne dans ce buffer. Le problème, c'est : qui alloue le buffer? Qui libère le buffer? En posant cette question à des dizaines de candidats, j'ai mis en évidence un fait intéressant. La plupart des personnes qui pensent connaître le C ne comprennent pas du tout les allocations mémoire et les pointeurs. Ils n'ont pas pigé. C'est étonnant que ces personnes travaillent comme programmeurs, mais c'est vrai. Par cette question, il y a des moyens de juger les candidats :

• Leur fonction est-elle rapide? Regarder combien de temps prend l'appel à strlen. J'ai vu des algorithmes en n^2 pour strrev, alors qu'ils auraient dû être en n, car ils appelaient strlen encore et encore dans la boucle.
• Utilisent-ils des pointeurs arithmétiques? C'est un bon signe. Beaucoup de programmeurs C ne savent simplement pas comment marche un pointeur arithmétique. Ordinairement, je ne refuse pas un candidat juste parce qu'il lui manque une connaissance particulière. Cependant, j'ai découvert que comprendre les pointeurs en C n'est pas une connaissance, c'est une aptitude. En première année de fac d'informatique, il y a toujours au début du semestre dans les 200 gamins qui ont tous écrit des jeux d'aventure sophistiqués en BASIC sur leur Atari 800 dès l'âge de 4 ans. Ils s'amusent bien à apprendre le Pascal, jusqu'à ce qu'un jour, les profs introduisent les pointeurs. Et soudainement, ils ne pigent plus. Ils ne comprennent simplement plus rien. 90% des étudiants de la promo se réorientent et se spécialisent en sciences politiques, et racontent ensuite à leurs amis qu'il n'y avait pas assez de jolies personnes du sexe adéquat en informatique. Il s'avère que la majorité semble née sans la partie du cerveau qui permet de comprendre les pointeurs. C'est donc une question d'aptitude, pas de connaissances - cela requiert une forme complexe de double pensée indirecte que la plupart des personnes n'ont pas.

Le n°3, permet de voir s'ils ont bien appris les opérations sur les bits en C...mais ça, c'est une connaissance, pas une aptitude, il est possible de les aider sur ce point. La chose intéressante, c'est de les regarder écrire une fonction qui compte tous les bits d'un octet, puis de leur demander d'en écrire une beaucoup, beaucoup plus rapide. Les candidats vraiment intelligents vont créer une table de correspondance (après tout, elle n'aura que 256 entrées). Cette table n'aura à être créée qu'une seule fois. Avec les bons candidats, on peut parler intelligemment de différents compromis espace/vitesse. Poussez-les encore plus loin : dites-leur que vous ne voulez pas passer de temps à construire la table de correspondance pendant l'initialisation. Les candidats brillants vont suggérer un schéma de cache où les bits sont comptés à leur première utilisation, puis stockés dans une table de correspondance, de manière à ce qu'on n'aie pas à les recompter si ils sont à nouveau utilisés. Les candidats vraiment, vraiment brillants, vont essayer d'imaginer une table utilisant une sorte de raccourci qui s'appuie sur les masques ...(N.d.T. j'y comprends rien là)

Voilà quelques techniques qui peuvent être utiles lorsqu'on regarde quelqu'un écrire du code :

• Toujours réaffirmer que l'on comprend qu'il n'est pas facile d'écrire du code sans éditeur de texte, et que ce n'est pas grave si le papier est tout raturé. Réaffirmer aussi que l'on comprend qu'il est difficile d'écrire du code sans bug en l'absence d'un compilateur, et que cela est pris en compte.
• Des signes révélant un bon programmeur : les bons programmeurs ont l'habitude d'écrire leurs «{», puis d'aller en bas de la page et y écrire immédiatement leur «}», et ensuite de remplir l'espace entre les deux. Ils ont aussi tendance à avoir leurs conventions pour nommer les variables, même si elles ont l'air primitives.... Les bons programmeurs utilisent des noms très courts pour les indices de boucle. Ceux qui appellent leur indice de boucle CurrentPagePositionLoopCounter n'ont, de toute évidence, pas écrit beaucoup de code dans leur vie. A l'occasion, vous verrez des programmeurs C écrire quelque chose comme if (0==strlen(x), en mettant la constante à gauche du ==. C'est vraiment bon signe. Cela signifie qu'ils se sont trop souvent fait avoir par la confusion du = et du ==, et se sont obligés à prendre de bonnes habitudes pour éviter ce piège.
• Les bons programmeurs font un plan avant d'écrire leur code, surtout quand il y a des pointeurs. Par exemple, si on leur demande d'inverser une liste liée, les bons candidats vont toujours faire un petit dessin représentant les pointeurs et leur affectation. Obligé. C'est humainement impossible d'écrire le code pour inverser une liste liée sans dessiner des carrés reliés par des flèches. Les mauvais programmeurs vont se lancer directement dans l'écriture.

Inévitablement, leur fonction va être buggée. Donc on arrive à la question 5 : Votre code vous satisfait-il? Peut-être demanderez-vous : «OK, où est donc le bug?». C'est la question ouverte quintessencielle de la mort. Tous les programmeurs font des erreurs, c'est normal, il faut juste qu'ils soient capables de les trouver. Avec une fonction sur les chaînes de caractères, c'est presque toujours qu'ils ont oublié de terminer par «Null» la chaîne résultat. Avec presque toutes les fonctions, il y a des erreurs dans lesquels on tombe à tous les coups. Parfois, c'est l'oubli des points-virgules. La fonction ne va pas marcher avec des chaînes de caractères de longueur 0, ou bien générer un Erreur Générale de Protection si la fonction malloc se plante... Très, vraiment très rarement, vous allez tomber sur le candidat qui ne fait aucune erreur, dès le premier essai. Dans ce cas, la question est encore plus drôle. Quand vous allez lui dire «Il y a un bug dans ce code», il va le revoir attentivement, et vous allez voir s'il sait faire preuve de diplomatie tout en restant ferme sur le fait que son code est parfait... En règle générale, c'est toujours une bonne idée de demander au candidat s'il est content de la réponse qu'il a donnée, avant de continuer.

Partie 6 : la question de conception. Demander au candidat de concevoir quelque chose. Jabe Blumenthal, le concepteur à l'origine d'Excel, aimait à demander aux candidats de concevoir une maison. Selon Jabe, il a eu des candidats qui se sont levés et sont directement allés au tableau dessiner un carré. Un carré! Ceux-là ont été des «Au suivant», immédiatement. Avec des questions de conception, que cherchez-vous à savoir?

• Les bons candidats vont essayer d'obtenir de vous plus d'information sur le problème. Une maison pour qui? Je donnerais comme règle de ne pas embaucher quelqu'un qui se jette dans la conception sans chercher plus avant à qui le produit s'adresse. Je suis parfois tellement agacé que je suis vache, interrompant les candidats en plein travail pour leur dire «en fait j'ai oublié de vous dire, mais il s'agit d'une maison pour une famille de girafes aveugles».
• Les candidats pas intelligents pensent que la conception, c'est comme la peinture : on dispose d'une feuille blanche et on fait ce qu'on veut. Les candidats intelligents comprennent que la conception est une série de compromis. Une bonne question de conception : concevoir les poubelles publiques d'une ville. Penser à tous les compromis! Elles doivent être faciles à vider, mais impossibles à voler ; on doit pouvoir y jeter des déchets sans efforts, mais ces derniers ne doivent pas s'envoler les jours de grand vent ; elles doivent être solides, mais cependant bon marché ; dans certaines villes, elle doivent être conçues de manière à ce qu'il soit impossible aux terroristes d'y cacher une bombe.
• Les candidats créatifs vont souvent vous surprendre par leurs réponses intéressantes, pas évidentes d'entrée. Une de mes questions favorites est Concevoir une boîte à épices pour aveugles. Inévitablement, les candidats vont mettre du Braille quelque part sur les boîtes d'épices, et en général ça finit sur le couvercle, pour des raisons qu'on découvre après avoir posé la question 100 fois. J'ai eu un candidat qui a décidé que ce serait mieux de mettre les épices dans un tiroir, parce qu'il est plus confortable de lire du Braille horizontalement que verticalement (essayez!). C'était tellement créatif que cela m'a surpris -- en des dizaines d'entretiens, je n'avais jamais eu cette solution. Et cela ressemble à un «saut» créatif au-delà des limites du problème. C'est sur cette question que j'ai embauché le candidat, et il est devenu l'un des meilleurs chefs de projets de l'équipe d'Excel.

• Rechercher la conclusion. Cela fait partie d'aller au bout des choses. Parfois les candidats sautillent d'un pied sur l'autre, incapables de prendre une décision, ou bien ils tentent d'éviter les questions difficiles. Parfois, ils vont laisser des points sans réponse et essayer de changer de sujet. Pas bon. Les bons candidats ont tendance à faire avancer les choses, même si on essaie de les retenir. Lorsque la conversation commence à tourner en rond, si le candidat dit quelque chose comme «bon, on pourrait en parler toute la journée, mais il faut faire quelque chose, alors choisissons la décision X», c'est vraiment bon signe.

Cela nous amène au n°7 : Le Challenge. Celui-là est très drôle. Au cours de l'entretien, s'arrêter à quelque chose d'absolument, positivement, incontestablement correct que dit le candidat. A ce moment-là dire «un instant, un instant», et passer 2 minutes à jouer l'avocat du diable. Discuter seulement alors que vous êtes sûr qu'il a raison.

• Les candidats faibles vont laisser tomber. Au suivant!
• Les candidats solides vont trouver un moyen de vous persuader. Ils ont tout une liste de techniques issues des cours de Dale Carnegie pour vous convaincre. «Je comprends peut-être mal ce que vous affirmez», vont-ils dire. Mais ils vont rester sur leur position. On les prend.

Il faut admettre que, en situation d'entretien, on n'est pas sur pied d'égalité. Il y a donc un risque que le candidat ait peur de se disputer avec vous, à cause de votre pouvoir. MAIS les bons candidats auront tendance à être honnêtement passionnés par le débat, à en oublier qu'ils sont en entretien et prendre à coeur de vous convaincre. Ce sont ceux-là dont nous voulons.

Pour finir, il est bon de demander au candidat si il a des questions. Certaines personnes aiment voir si le candidat pose des questions intelligentes ; c'est une technique classique des guides d'entretien. Personnellement, je me fiche des questions qu'ils posent ; à ce moment, j'ai déjà ma décision. Le problème, c'est que les candidats doivent voir 5 ou 6 personnes dans la journée, il leur est donc difficile de poser à 5-6 personnes des questions brillantes à chaque fois. Donc s'ils n'ont pas de question, ce n'est pas grave.

Je garde toujours, toujours 5 minutes à la fin de l'entretien pour vendre Fog Creek. Cela est très important, même si vous n'allez pas embaucher ce candidat. Si vous avez eu la chance de trouver un candidat vraiment bon, vous allez faire l'impossible pour qu'il ait envie de venir. Concernant les mauvais candidats, ils doivent être enthousiastes à propos de Fog Creek Software, de façon à ce qu'ils s'en aillent avec une image positive de la compagnie. Voilà le raisonnement : ces personnes ne sont pas simplement des candidats à l'embauche, ce sont aussi des clients. Ils sont également nos vendeurs pour nos efforts de recrutement : si ils pensent qu'il fait bon travailler pour Fog Creek, ils vont encourager leurs amis à postuler.

Ah, je me souviens que j'ai promis de donner quelques exemples des mauvaises questions à éviter.

D'abord, il y a les questions illégales. Tout ce qui a rapport à la race, la religion, la nationalité, l'âge, la situation vis-à-vis du service militaire, la situation d'ancien combattant, l'orientation sexuelle, au handicap physique, est simplement illégal [aux Etats-Unis]. Si un CV mentionne que le candidat était à l'armée en 1990, ne pas lui demander si il a fait la guerre de Golfe, même pour rendre la conversation sympathique. C'est contraire à la loi. Si, selon le CV, le candidat a assisté à des cours au Technion de Haïfa [Institut de Technologie d'Israël], ne pas lui demander, même de manière informelle, si il est Israélien. C'est contraire à la loi. Il y a ici une bonne discussion sur les questions illégales (mais les autres parties sur les questions d'entretien sont complètement stupides).

Ensuite, éviter toutes les questions qui pourraient laisser à penser qu'on considère comme importantes, ou qu'on utilise comme critère de sélection, des informations dont on n'a rien à faire ou qu'on n'utilise pas pour la sélection. Le meilleur exemple est, je pense, demander à quelqu'un si il a des enfants ou si il est marié. Cela pourrait donner la fausse impression que nous considérons les personnes avec enfants comme susceptibles de se montrer peu assidues, ou de partir en congés maternité.

Enfin, éviter les questions casse-tête, comme celle où il faut former 4 triangles identiques avec 6 allumettes. Comme ce sont des questions où il faut juste connaître le truc, on n'obtient aucune information sur «intelligent/va au bout des choses», car cela dépend si ils connaissaient le truc avant ou pas.

Conduire des entretiens est plus un art qu'une science, mais il faut se souvenir du principe «intelligent/ va au bout des choses» et tout se passera bien. A l'occasion, il est bon de demander à ses collègues quelles sont leurs questions préférées et quel genre de réponses ils obtiennent. Ceci est de longue date le sujet de conversation favori à l'heure du déjeuner, dans la cafet' du bâtiment 16, à Redmond.