Quels sont les avantages et les inconvénients pour l'employeur des questions de code lors d'une entrevue? [fermé]

16

La question n ° 11 du test Joel est: "Les nouveaux candidats écrivent-ils du code lors de leur entretien?". Quels sont les arguments pour et contre de demander aux nouveaux candidats d'écrire du code lors de l'entretien et de prendre une décision à ce sujet?

duros
la source
Écrire du code comme dans l'écrire physiquement avec un crayon et la main ou écrire comme dans du code de type sur une machine?
Chris
Le principal problème est de poser des questions stupides ou inutiles et de penser que vous l'avez bien fait. Tels que quelqu'un commente qu'on lui a demandé d'écrire une liste de liens.

Réponses:

13

Je ne vois pas les inconvénients. Une entrevue comporte plusieurs parties et un candidat devrait être endossé «en amont» à plusieurs reprises.

J'interviewe environ 10 personnes par semaine. J'apprécie vraiment, vraiment, vraiment le fait que les RH aient fait tout le travail de fond et m'ont présenté de nombreuses notes. Au moment où ils me parviennent, il est temps pour moi de réussir leurs tests.

Les tests dépendent entièrement de la position. Généralement, j'essaye de sonder:

  • Compétence générale en programmation. Pouvez-vous utiliser efficacement les opérateurs? Pouvez-vous concevoir un système numérique qui a une radix qui n'est pas 10?

  • Savez-vous comment faire ce que nous vous engageons à faire?

  • Évaluation de vos contributions à tous les projets open source que vous avez répertoriés

J'essaie d'être bref et amusant. Quand j'entre dans le bureau, j'attrape les réponses, les regarde et mène ensuite un entretien secondaire. Pour être embauché, vous devez généralement passer par trois entretiens.

J'évalue également dans quelle mesure vous vous fondrez dans l'équipe qui vous accueillera. Cette équipe compte sur moi pour le faire efficacement.

C'est une chose de répondre à des questions sous forme de méta, c'est une autre de produire réellement du code. Si je vais vous embaucher, j'ai vraiment besoin de vous voir produire du code.

Tim Post
la source
Hmmm ... Je me considère comme un développeur qualifié. Au cours de mes trois derniers entretiens, quand on m'a demandé quelque chose comme «que fait une méthode particulière», ou quelque chose de similaire, j'ai décidé d'abandonner. Puisque je ne cherche jamais un emploi, où je serais censé faire quelque chose que je connais très bien. Ce n'est pas intéressant. Comme mon ex-patron l'a dit: "Réutilisables? Les programmeurs devraient être réutilisables, peut-être des programmes".
duros
@duros Je suis désolé d'entendre ça. Un bon intervieweur devrait être capable de rendre le processus amusant .. et devrait se rendre compte que les autres programmeurs détestent les tests.
Tim Post
ce n'est pas que je ne me sens pas à l'aise lorsque je suis testé. Je me rends compte des opportunités d'apprendre et d'essayer quelque chose de nouveau que j'aurais, s'ils m'engagent en tant que codeur ... Au cours de la dernière, j'ai envoyé l'intervieweur pour lire les javadocs ...: - / Peut-être, je ' m mal ...
duros
10
On m'a demandé une fois dans une interview d'écrire des accesseurs pour une liste chaînée en Perl. Depuis 8 ans que je travaille avec Perl, je n'ai rencontré aucun programme de production utilisant des listes chaînées. Bien sûr, j'ai brouillé et produit, sur papier, des méthodes insert () et remove () et un objet basé sur le hachage qui, selon moi, ferait l'affaire. La première chose que l'intervieweur a dit en regardant le journal était "Il vous manque quelques points-virgules"
leed25d
1
c'est une autre de produire du code - c'est vrai, c'est vrai. J'ai été à plusieurs reprises surpris par des gens qui décrivent un algorithme plausible mais ne peuvent même pas commencer à le réduire en code. Cela, ou ils ont survolé une étape non algorithmique qui ne peut être évitée lorsque vous écrivez du code.
poolie
34

Toutes mes excuses à Scott Whitlock:

Les inconvénients:

  • aucun

Avantages:

  • Économise BEAUCOUP de temps et de chagrin sur la route si vous empêchez d'embaucher quelqu'un qui ne peut pas programmer
  • Vous oblige à avoir une personne technique dans l'entretien
Armand
la source
Est-ce que «vous oblige à avoir une personne technique dans l'entretien» peut être considéré comme un con?
Yeikel
2
Cela dépend si vous essayez de remplir un rôle ou simplement de remplir une chaise, je suppose. Mais l'OMI non, ça ne peut pas être considéré comme un con.
Armand
19

Si vous deviez embaucher un jongleur, vous seriez fou de ne pas le faire jongler avec vous. Ou un musicien que vous auriez auditionné. Sinon, vous obtenez des trucs comme le K-strass génial yo-yo "master" .

Marcher à travers quelque chose sur un tableau blanc est l'équivalent pour les programmeurs d'une jongle de démonstration rapide.

comment s'appelle-t-il
la source
+1 pour le lien. Je pense toujours que jongler ne consiste pas à se souvenir de choses comme les signatures de méthode, ou similaire, mais simplement à pouvoir penser et résoudre des problèmes que vous n'avez jamais rencontrés auparavant ...
duros
4
Sauf que la jonglerie est une compétence immédiate avec seulement quelques variantes, souvent exécutée devant un public. La programmation est une tâche lourde et profonde, rarement exécutée en tant que telle. Il est également beaucoup moins productif sur papier ou tableau blanc. Cela dit, les tests de pseudo-code (ou ignorer les bogues de support triviaux) peuvent être très utiles.
Bruce Alderson
10

Je pense que c'est super utile, et je le fais toujours, mais comme les avantages ont été si bien couverts, je vais discuter uniquement des négatifs (apparents).

Je pense que les tests de code sont peu susceptibles de vous donner de faux positifs: les chances sont faibles que quelqu'un qui ne peut pas écrire de code parvienne à le simuler dans une interview, du moins si vous avez une échelle de questions de difficulté croissante. (Le scénario le plus probable est peut-être qu'ils trichent en demandant à un ami, s'il ne s'agit pas d'une entrevue en personne.)

Les problèmes sont plutôt du côté des faux négatifs: les tests de code vous conduiront-ils à rejeter la personne qui est en fait le meilleur candidat?

Trac

Vous pouvez avoir quelqu'un qui est en fait un très bon développeur, mais qui est très nerveux à propos de cette interview, et ils ont essentiellement peur de la scène. Jouer sous pression est important dans une certaine mesure, mais faire face à la peur de la scène n'est pas un élément clé pour être programmeur (par rapport à d'autres professions), et il serait malheureux de rejeter quelqu'un qui en souffre gravement. Cela peut aggraver: si la personne ne peut pas répondre à une question à laquelle elle sait qu'elle doit répondre, elle peut se resserrer. Ou, comme dans cette question , ils sentent qu'ils ne peuvent pas parler et coder en même temps.

Atténuation: commencez par poser quelques questions sur leur parcours, leurs objectifs, etc. avant de passer aux questions techniques. Commencez peut-être par des questions techniques plus faciles pour qu'elles prennent de l'élan. Ne soyez pas une bite pendant l'entrevue (chicanant sur les points-virgules, etc.).

C'est une mesure bruyante

Les questions de code intéressantes peuvent avoir plusieurs réponses correctes. Si une personne écrit une bonne réponse et une autre une réponse correcte et plus efficace, combien de poids devriez-vous y mettre?

Dans une certaine mesure, cela ressemble au problème avec certaines questions «énigmes»: la personne a la perspicacité ou non et vous obtenez un résultat presque binaire. L'intelligence affecte probablement la probabilité d'avoir cette idée, mais l'échantillonnage à quelques reprises seulement vous donne une mesure grossière.

Cela me dérange pour les questions de code (bien que je les utilise toujours.) La meilleure atténuation à laquelle je peux penser est d'avoir autant que possible une rampe de solutions possibles: la personne peut au moins écrire une réponse brute force brute, ou une réponse pour une partie du problème. Réaliser que c'est mieux que rien est un bon signe. S'ils en découvrent plus, ils peuvent le rendre plus efficace ou plus élégant. Autant que possible, évitez de poser des questions qui obtiennent des réponses binaires.

Ce n'est pas vraiment représentatif

La programmation n'est pas un travail de résolution de problèmes algorithmiques de dix minutes les uns après les autres: il y a beaucoup plus de travail sur la compréhension et la conception de systèmes plus grands et la concentration pendant de longues périodes de temps, pour ne rien dire des compétences interpersonnelles. Les questions de code ne testent pas vraiment cela.

Mais, les questions de code ne sont pas les seules questions que vous allez poser: vous pouvez regarder leur contexte, leurs références, leur travail open source (le cas échéant), pour trouver des preuves d'efforts soutenus, de créativité, de compétences interpersonnelles.

Savoir comment résoudre de petits problèmes algorithmiques et comment les réduire en code est une condition nécessaire mais pas suffisante: si vous ne pouvez pas résoudre de petits problèmes et que vous ne pouvez pas écrire de code non trivial, alors toute la vision globale du monde n'est pas va faire de vous un développeur productif.

N'importe qui pourrait résoudre ce problème

Non, apparemment non. Comme le souligne le célèbre article de FizzBuzz , les problèmes que vous pourriez penser sont un piège trivial non seulement pour les nouveaux diplômés mais aussi pour les personnes ayant des années d'expérience dans l'industrie. Je ne sais pas pourquoi. Soit le test de code est une mauvaise mesure (ce qui est possible, bien que je pense que ce soit peu probable), soit ils ne contribuaient pas beaucoup aux projets de leur curriculum vitae, ou ils faisaient beaucoup en copiant-collant code algorithmique (ce qui est possible.)

Il convient de reconnaître que vous pouvez vraiment faire beaucoup de choses sans écrire de code algorithmique. Les gens gagnent beaucoup d'argent sur des applications dont la valeur réside dans le graphisme ou la logique métier et non dans ce que vous pourriez appeler la "programmation", et c'est très bien. Mais, si vous avez réellement besoin de programmeurs, ce n'est pas un bon choix.

Il n'est peut-être pas bien calibré

Si vous posez une question, la réponse peut très bien vous sembler simple. Cependant, si on vous pose une question par ailleurs comparable à l'improviste, ou une question qui n'est pas orientée vers vos propres intérêts et antécédents particuliers, cela peut être beaucoup plus difficile.

atténuation: exécutez les tests sur certains développeurs que vous connaissez déjà et voyez comment ils le font. Peut-être que quelqu'un déjà dans votre équipe, que vous connaissez est très intelligent, aura des problèmes avec l'un d'eux et vous pouvez envisager de le régler. Peut-être penseront-ils à une réponse meilleure ou différente.

C'est trop comme des anecdotes

Je pense que les questions de code peuvent certainement entrer dans le jeu, si vous insistez pour que les gens connaissent par cœur les API obscures, ou obtiennent la syntaxe parfaite, ou se souviennent de la définition exacte d'un algorithme non trivial. Ceux-ci sont tous raisonnables pour s'appuyer sur des documents, des recherches sur le Web ou des erreurs de compilation, et ont peu de corrélation avec une véritable expertise. Ne pas même savoir où les API sont susceptibles d'être est peut-être un indice que la personne ne l'a pas utilisé récemment, mais ce n'est pas nécessairement un problème tant qu'elle ne ment pas sur son curriculum vitae.

La réponse est donc assez simple: ne posez pas de questions triviales et ne vous attardez pas sur des erreurs triviales. Rappelez au candidat le nom de l'API ou laissez-le le rechercher; corriger les erreurs de syntaxe; ne testez pas les personnes qui mémorisent des définitions de structure de données.

Comment comparez-vous?

Si vous avez deux candidats et que les deux répondent bien aux questions, comment choisissez-vous entre eux? Vous pouvez choisir celui qui a terminé le plus rapidement, mais peut-être que vous commencez à cueillir des lièvres plutôt que des tortues. Vous pourriez faire un autre tour et poser des questions beaucoup plus difficiles, mais je n'en suis pas sûr non plus. Peut-être que vous leur donnez simplement un A + et essayez de choisir entre eux sur d'autres critères (ou essayez de trouver l'argent pour embaucher les deux.)

poolie
la source
7

Un inconvénient auquel je peux penser est qu'il est difficile de "coder à haute voix" devant d'autres personnes. J'ai même du mal à taper avec quelqu'un qui regarde par-dessus mon épaule, et je ne suis pas seul. Je remarque que lorsque quelqu'un m'appelle à son poste de travail pour aider quelque chose, il commence soudainement à faire des fautes de frappe, à sélectionner le mauvais code, voire à faire des erreurs carrément - dont aucune n'aurait été commise si je n'avais pas été assis juste là. Enfer, j'ai vu des gens commencer à utiliser le menu pour les opérations de copier-coller, juste parce qu'ils étaient sous observation. Ce n'est pas un comportement normal, et les codeurs dont je parle sont d'excellents programmeurs et d'ailleurs assez intelligents.

J'ai récemment eu une entrevue au cours de laquelle l'intervieweur m'a demandé comment je coderais une opération particulière et il a dit: «Montrez-moi simplement les mathématiques». Eh bien, je devais d'abord réfléchir au problème avant d'aborder les mathématiques, ce qui m'a obligé à faire des ourlets et des haplings. Ce que j'ai mis sur le tableau blanc au début était embarrassant, et je sentais que je perdais à ce moment-là. J'ai finalement eu le moment A-ha et j'ai trouvé la réponse (en fait, quand j'ai finalement pensé à ce qu'il demandait vraiment ), mais le "gâchis" que j'ai fait avant d'y arriver m'a fait me sentir très mal à l'aise. Néanmoins, j'ai obtenu le poste, mais si l'intervieweur avait été moins patient, je ne l'aurais peut-être pas fait.

Je pense que si vous confiez aux interviewés une tâche de codage, donnez-leur un peu de temps pour travailler sur un ordinateur, peut-être même dans un IDE qu'ils connaissent. Laissez-les écrire le code pour vous et ensuite en parler. Demandez-leur pourquoi ils ont fait les choses d'une certaine manière et si une autre façon ne serait pas meilleure. Vous en apprendrez plus sur ce genre de processus qu'en leur demandant de faire pipi (au sens figuré) dans une tasse juste en face de vous.

Robusto
la source
4
Mais ça va. Le but d'une question d'entrevue de codage n'est pas de tester la capacité de frappe ou même une parfaite connaissance de l'API. Les fautes de frappe et autres peuvent être ignorés et vous vous concentrez plutôt sur le processus de réflexion du candidat et sa familiarité avec les fondements de la programmation. Par exemple, j'ai fait partie d'une entrevue qui a montré l'incapacité totale du candidat à penser à quelques pas en avant (il résoudrait un petit problème, réalisait que cela créait un autre problème, etc.).
Adam Lear
2
C'est "difficile à coder devant les autres"? Bien. Je n'engage que des gens qui peuvent faire des choses difficiles. L'un d'eux est en mesure de discuter du code (c'est-à-dire du programme) avec (devant) d'autres personnes.
Kevin Cline
1
@kevin cline: Vous manquez mon point. Vous souciez-vous de la façon dont les gens obtiennent des résultats, ou voulez-vous seulement qu'ils obtiennent des résultats en fonction de vos caprices? Beaucoup de gens peuvent très bien coder dans un environnement d'équipe, mais ont besoin de «temps seul» pour produire à une efficacité maximale. Vous parlez comme le genre de gars qui n'aurait pas embauché Mark Zuckerberg parce qu'il avait besoin d'être «branché» pour une productivité maximale.
Robusto
1
@Robusto: Je ne pose pas de questions profondes dans une interview. J'ai juste besoin de voir quelqu'un résoudre un problème simple en quelques minutes. Et j'ai besoin de gens qui peuvent travailler en équipe. Cela signifie une capacité et une volonté de parler de code. Bien sûr, je peux manquer un grand programmeur qui ne peut tout simplement pas supporter la pression d'une interview. C'est bon. Mais une mauvaise embauche est désastreuse.
Kevin Cline
6

Inconvénients: aucun. Chaque fois que vous passez à configurer un PC, à concevoir un test de code et à le réviser, vous éviterez des maux de tête indicibles à l'avenir.

Avantages: "Faites confiance, mais vérifiez" - Ronald Regan. Tant de fois j'ai vu et entendu parler de gens qui ont finalement abandonné une position où, dans l'interview, vous penseriez avoir une rock star. La preuve est dans le pudding; Je veux voir ce qu'ils peuvent faire. Cela représentera ce qui se passe une fois que vous investissez du temps et de l'argent en embauchant quelqu'un et que vous collez un nouveau projet devant lui.

HardCode
la source
4

Les inconvénients:

  • Vous oblige à avoir une personne technique dans l'entretien

Avantages:

  • Économise BEAUCOUP de temps et de chagrin sur la route si vous empêchez d'embaucher quelqu'un qui ne peut pas programmer
Scott Whitlock
la source
25
Si vous interviewez des développeurs sans la participation de techniciens, vous êtes de toute façon condamné.
David Thornley
@ David: Je suis d'accord, je pense que les avantages ici l' emportent de loin sur les inconvénients, mais c'était le seul "con" auquel je pouvais penser.
Scott Whitlock
4

Lorsque j'ai interviewé pour mon emploi actuel, le recruteur m'a donné une liste de questions pour écrire du code. J'ai été très impressionné parce que les questions ont évidemment été écrites par quelqu'un qui avait une connaissance approfondie de SQL, donc cela fonctionne dans les deux sens.

Larry Coleman
la source
2

Vous voulez vraiment que la personne écrive du code dans l'interview - encore mieux, demandez-lui de jumeler le programme avec un membre de votre équipe pendant X fois (tout ce que vous pouvez vous permettre confortablement en temps / main-d'œuvre).

C'est à peu près l'une des seules façons de savoir si cette personne peut coder ou non.

Je préfère légèrement la programmation en binôme car elle montrera leur travail d'équipe, leur donne un véritable IDE avec lequel travailler et leur permet de travailler sur un `` vrai '' problème (l'autre personne de la paire peut les guider au-delà des spécificités environnementales que l'interviewé a ne pouvait jamais raisonnablement savoir).

Nous avons commencé à utiliser cette politique d'embauche et nous sommes vraiment satisfaits des résultats.

Martijn Verburg
la source
+1 pour les tests de paires: prouve à la fois la capacité de travailler avec un coéquipier / et / la capacité de coder.
Bruce Alderson
2

Vous jugez un oiseau par ses plumes et un programmeur par son code.

Lorsque j'ai commencé avec la société actuelle pour laquelle je travaille, ils m'ont demandé d'écrire du code C qui génère ou vérifie le bit de parité d'une entrée binaire (selon que vous codez ou décodez). C'était une question d'entrevue exactement parce que ces types de problèmes sont résolus pendant le travail. Bien sûr, je ne pense pas à vérifier la parité, mais plutôt à travailler à un niveau bas.

terminus
la source
2

Jusqu'à présent, toutes les réponses (que j'ai lues) ne traitaient pas du fait que le test Joel n'est PAS (juste) une liste de meilleures pratiques pour les entrepreneurs mais une liste de contrôle pour faciliter votre évaluation d'un employeur potentiel .

Le truc c'est que ... s'ils testent à fond leurs candidats, ils embaucheront probablement des gens qui connaissent leur métier ... cela signifie pour vous

  1. moins de maux de tête et aussi
  2. la chance accrue d' apprendre quelque chose de vos collègues

au lieu de corriger les bugs après eux ...

Raffael
la source
1

Je dirais:

Avantages

  • Démontre que le candidat a au moins une connaissance passable de la programmation, car les CV peuvent être fabriqués / embellis
  • Si l'intervieweur discute du code avec le candidat, par opposition à ce qu'il ressemble davantage à un test écrit, cela pourrait être un bon indicateur de la façon dont vous "maillez" socialement et si le candidat convient bien à l'entreprise / l'entreprise et l'équipe sont bonnes convient au candidat

Les inconvénients

  • Cela pourrait être insultant pour les candidats si les questions sont des bêtises par cœur / triviales qui ne se poseraient jamais pendant le travail (par exemple, "Écrire un tri à bulles" lorsque tous les cadres modernes que l'on utiliserait au travail ont un tri intégré, "Inverser une chaîne" "quand il y a une Reverseméthode intégrée ou similaire, ou pour des tests écrits des choses comme" Quels sont les arguments de la Foométhode de la Barclasse ", quand n'importe quel idiot pourrait Google cela ou utiliser la documentation) par opposition aux questions d'architecture / conception qui montrent le candidat peut faire avancer les choses et résoudre des problèmes commerciaux .
Wayne Molina
la source
1
Je pense que "inverser une chaîne" est une excellente question de départ dans une interview de codage. S'ils ne savent pas par où commencer (et un nombre incroyable de personnes ne le savent pas), vous ne voudrez probablement pas les embaucher. S'ils utilisent la méthode intégrée, c'est bien - cela vous dit qu'ils n'essaieront pas de construire leur propre roue si une est fournie - mais présentent alors une situation hypothétique où la méthode intégrée a un bogue pour qu'ils besoin d'écrire le leur. Vous pouvez ensuite utiliser leur code comme point de départ pour poser d'autres questions telles que la façon de corriger les bugs, l'utilisation de la mémoire, le temps d'exécution, etc.
Gabe
0

L'un des avantages est que cela montre que quelqu'un possède des connaissances de base en programmation ou autre (la dernière fois que j'ai rencontré cela, j'ai été surpris de la base de la question SQL). Il peut également servir de base à une discussion technique, demandant pourquoi le candidat a fait telle ou telle chose, et comment cela pourrait être amélioré.

Cela prend du temps dans l'entrevue, qui pourrait être utilisé pour d'autres choses. De plus, écrire du code sur un tableau blanc n'est pas un environnement naturel, et certaines personnes auront des problèmes de plus en moins graves. Cela pourrait vous faire manquer un développeur qui devient nerveux sans outils ni références normaux.

David Thornley
la source
3
Ce qui vous surprendrait encore plus, c'est combien de personnes supplémentaires ne pouvaient pas répondre à cette question fondamentale que qui le pouvait.
HLGEM
0

La programmation est une compétence hautement technique avec un tas de «livrables» clairs. Un candidat peut ou ne peut pas les livrer. Il n'y a donc aucun "inconvénient" à poser des questions techniques. C'est entièrement pour dire, "montrez-moi du code pour cette application, ou" montrez-moi le code pour une application que vous avez DÉJÀ écrite. "

NE PAS le faire pourrait conduire à un résultat comme celui-ci: Un homme riche a interviewé un tuteur pour apprendre à ses enfants à jouer aux échecs (comme un exercice d'expansion de l'esprit). Le tuteur a ouvert une planche à carreaux et a commencé à parler des 64 cases mais n'a pas touché une pièce d'échecs. Pressé par le temps, le père a quand même engagé le tuteur. Et le tuteur a appris aux enfants à jouer à CHECKERS.

Tom Au
la source
Cela montre juste un exemple d'un enquêteur incompétent, pas la nécessité de jouer aux échecs dans une interview. L'homme riche aurait pu simplement me demander «Expliquez Castling», ou quelque chose de similaire, et a immédiatement eu une idée de ce que le tuteur savait.
GrandmasterB