Le «White-Board-Coding» est-il inapproprié lors des entretiens? [fermé]

Il s'agit d'une question quelque peu subjective, mais j'aimerais entendre les commentaires / opinions des enquêteurs / interviewés sur le sujet.

Nous avons divisé notre entretien technique en 4 parties. Écrivez le code, lisez et analysez le code, la session de conception et le code sur le tableau blanc.

Pour la dernière partie, nous demandons aux personnes interrogées de rédiger un petit extrait de code (4-5 lignes) sur le tableau blanc et de l'expliquer au fur et à mesure. Permettez-moi d'être clair, le but n'est pas de rattraper les gens. Nous ne recherchons pas une syntaxe parfaite. Enfer ça peut même être du pseudo-code. mais le but est de leur donner un problème très simple et de voir si leur cerveau peut nous communiquer la solution. Par problèmes simples, je veux dire "Inverser une chaîne", "FizzBuzz" etc ...

Notez que nous demandons toujours d'abord un langage explicite. Nous sommes une maison .NET C #. nous avons seulement dit "pseudo-code" où quelqu'un avait effacé / vraiment du mal avec le code.

Ma question est "Est-il inapproprié / déraisonnable de s'attendre à ce qu'un programmeur écrive un extrait de code sur un tableau blanc lors d'une interview?"

À mon avis, c'est très approprié. Si vous voulez qu'un emploi fasse une compétence particulière, alors il est tout à fait approprié de s'attendre à démontrer cette compétence lors de l'entretien.

L'effet de cette technique sur le processus de recrutement est très sensible. 90% des candidats échouent à cette tâche. mais les développeurs recrutés sont bons, et les développeurs seront respectés au sein de l'entreprise.

Si en tant que candidat face à cette technique, détendez-vous tout d'abord. Il s'agit de vous évaluer en tant que programmeur et de vos processus de pensée. Il ne s'agit pas de votre syntaxe parfaite. Si vous faites une erreur de syntaxe, je pourrais jouer le rôle d'un compilateur et vous dire que le code ne parvient pas à compiler sur une certaine ligne, vous donner un message d'erreur et voir comment vous réagissez. De même, si vous ajoutez un; sur une boucle ou une instruction if qui se compilerait, je jouerais le débogueur et vous expliquerais une seule étape du code. Encore une fois, ce n'est pas à propos de l'erreur, c'est à propos de la façon dont vous feriez face à l'erreur, et vos processus de pensée sont-ils bons.

Ma question est "Est-il inapproprié / déraisonnable de s'attendre à ce qu'un programmeur écrive un extrait de code sur un tableau blanc pendant une interview?"

C'est très raisonnable. Une alternative à un tableau blanc pourrait être un ordinateur portable et un vidéoprojecteur, car les programmeurs sont plus habitués à écrire du code sur un clavier que sur un tableau blanc. Assurez-vous simplement qu'un environnement de développement comme Eclipse ou VS ou Idle est déjà en cours d'exécution avec un projet vide au démarrage de la candidate, afin qu'elle n'ait pas à perdre de temps à chercher dans vos applications installées.

Ce n'est pas inapproprié, mais sachez que cela pourrait NE PAS toujours révéler les véritables informations sur les capacités de programmation ou de résolution de problèmes de la personne que vous interviewez. Et je suppose que c'est exactement ce que vous recherchez.

Deuxièmement, notez qu'il y a toujours la peur de l'échec, nettoyant constamment le cerveau de la personne. "Et si je me trompe?", "Et si je fais une erreur idiote". La plus grande partie du cerveau de la personne est constamment occupée à inspecter la façon dont elle se détache - seuls quelques-uns peuvent retenir les nerfs.

Donc, dans ce genre de situation, même les meilleurs pourraient finir par faiblir.

Pour la dernière partie, nous demandons aux personnes interrogées de faire est d'écrire un petit extrait de code (4-5 lignes) sur le tableau blanc et d'expliquer au fur et à mesure

C'est bon. Mais encore une fois, ce n'est pas parce que quelqu'un ne peut pas expliquer quelque chose correctement qu'il ne le sait pas bien. (L'explication est un art de la parole).

Si j'étais toi, je ferais ça Pour la dernière partie ...

Embauchez-les pour un tout petit projet (mais réaliste). Voyez comment ils codent, prennent des décisions, assimilent les conditions de travail et les membres de l'équipe, etc., puis sur cette base, prennent la décision finale.

Pas inapproprié, mais rappelez-vous que certaines personnes (et peut-être une plus grande part de la foule des programmeurs) peuvent être très stressées lors d'une interview. Je pense que la plupart d'entre nous connaissent le gars du bureau qui est un brillant codeur et une personne très digne de confiance, mais il fondrait dans une telle situation. Ses performances n'ont pas pu être mesurées dans un tel test, alors n'en faites pas un test go / no go.

Je pense personnellement que c'est l'une des meilleures choses que vous puissiez faire. Comme vous l'avez dit, vous ne cherchez pas la syntaxe correcte ou quelque chose de similaire, la partie la plus importante ici est de voir si quelqu'un peut communiquer ... J'ai vu tant de bons développeurs qui ne peuvent travailler seuls que dans leur propre espace ... Malheureusement, cela n'est pas possible dans un grand nombre de cas, donc avoir un gars compétent qui est également capable de dire ce qu'il pense de manière claire et concise est un membre plus précieux de l'équipe que quelqu'un qui pense: "Ils ne comprendront pas de toute façon, je vais le faire moi-même et démontrer plus tard ".

La communication, la communication, la communication est quelque chose qui est le fondement de tout projet de moyenne à grande taille (encore plus petit en a besoin)

Je pense que ce n'est pas une chose raisonnable. Nous essayons de trouver des candidats, qui sont bons dans la tâche que nous voulons qu'ils fassent. Écrire du code sur un tableau blanc n'en fait pas partie et je ne pense pas que ce soit un filtre valide pour trouver de bons candidats.

• Un bon code n'est pas écrit, il est réécrit. Un tableau blanc est à peu près immuable, car il est difficile de le changer une fois que vous l'avez écrit. Il devrait être aussi facile que possible de changer d'avis dès que vous comprenez mieux le problème.
• Être en entrevue est une situation stressante, car il n'est pas nécessaire de mettre une pression supplémentaire sur le candidat. De nombreux informaticiens n'ont pas une bonne écriture. Les IDE modernes fournissent de nombreux outils auxquels vous êtes habitué. Et pouvoir google quelque chose la minute dont vous avez besoin fait également partie du style de travail de la plupart des programmeurs. Pourquoi enlever toutes ces choses et créer un environnement artificiel, dans lequel elles n'auront jamais à travailler si vous leur faites une offre?
• Nous sommes également très intéressés par la possibilité d'écrire de bons tests, peut-être même de faire du TDD. Ce n'est pas possible de voir pendant le codage du tableau blanc.

La plupart des indices que vous pourriez tirer d'une session de codage de tableau blanc, vous pourriez également en sortir - Et je pense que le pairage est un bien meilleur outil pour avoir une idée, comment un candidat résout un problème et comment il fonctionne. Il peut apporter son propre ordinateur et travailler dans un environnement avec lequel il est à l'aise. Et il est beaucoup plus facile de l'appliquer à la tâche que vous souhaitez qu'ils effectuent une fois qu'ils se sont joints. Nous avons par exemple une grande base de code héritée, nous leur demandons donc de refactoriser du code extrait pour le projet réel. Et nous nous associons en fait autant que possible dans notre travail quotidien, donc c'est bien adapté.

Bien qu'une session de tableau blanc aide probablement à filtrer les mauvais candidats, elle filtre également de nombreux bons programmeurs.

Personnellement, je sortirais avec n'importe quel intervieweur me demandant de faire FizzBuzz. Je ne sais pas quand cela est devenu la nouvelle norme de l'industrie, mais c'est vraiment une perte de temps. FizzBuzz est un filtre qui peut être utilisé avant une interview, bien que personnellement, je pense que si je devais choisir parmi N candidats dont suffisamment ont du code open source ou un blog que je peux consulter, je préférerais certainement cela comme filtre .

En termes simples, je pense que dans une interview pour un poste de programmeur (sauf peut-être pour les juniors ou les stages), il aurait déjà dû être établi / déterminé que la personne interrogée peut programmer.

Mais oui, le tableau blanc est parfait, même si je pense que vous devriez prendre un ensemble de problèmes différent. Lancez-leur un problème du monde réel et demandez-leur de dessiner un tas de querelles UML pour expliquer leur stratégie globale pour résoudre ce problème. Donnez-leur un ordinateur avec Internet, afin qu'ils puissent rechercher des bibliothèques tierces qu'ils pourraient utiliser comme boîtes noires dans leur paysage de squibbles.
En quelques minutes, vous verrez vraiment comment ils abordent les problèmes. Vous pouvez réellement en faire une chose très intéressante, en choisissant des problèmes pour lesquels vous n'avez pas nécessairement une solution à l'esprit et en essayant de les "résoudre" ensemble, pour voir dans quelle mesure ils communiquent et dans quelle mesure ils peuvent incorporer des contributions (cependant ne pas ne les poussez pas trop fort - certaines personnes pourraient simplement geler si vous le faites). Et puis ajoutez quelques exigences à la volée. C'est un peu comme le développement de logiciels sans implémentation et, surtout, sans débogage, donc 15 minutes, c'est beaucoup de temps.

Permettez-moi de répondre par une autre question:

L'écriture de code sur un tableau blanc offre-t-elle un réel avantage pour évaluer la capacité de programmation, par rapport à la saisie et à l'exécution du code sur un ordinateur?

Je pense qu'il est tout à fait approprié de demander à un candidat d'écrire du code dans une interview. Cependant, pour moi, pouvoir exécuter le code est une partie critique de la boucle de rétroaction qui compose la programmation. Sur un tableau blanc, vous attachez une main derrière mon dos et vous ne comprenez pas comment je résous un problème.

Non, mais l'OMI une meilleure approche serait d'utiliser le tableau blanc pour son objectif et d'utiliser UML / sketches / notes pour certains projets fictifs, plutôt que l'ancien "écrivez-moi une requête sql pour obtenir tous les enregistrements" ou "écrivez une méthode qui inverse une chaîne ".

L'une des meilleures interviews que j'ai eues a été de consacrer environ 20 minutes à discuter avec le développeur principal de l'architecture (non logicielle) d'un manoir de savant fou (avec cachette secrète, rayon de la mort et chenil). Il a pu voir mon approche de la résolution des problèmes, et le problème était quelque chose d'amusant, pas de programmation par cœur typique, qui a été mille fois résolue par les langages modernes. Par ailleurs, j'ai également fait un morceau de code comme celui-ci auparavant, mais je me sentais beaucoup plus "sous pression" qu'avec la partie architecture.

De nos jours, beaucoup de programmation se fait en équipe. Pour que les équipes fonctionnent, les gens doivent pouvoir communiquer. Une grande partie de cela est de pouvoir communiquer devant un tableau blanc (brainstorming, mentorat, révision de code, correctifs proposés, etc.)

Je voudrais savoir si le candidat a expliqué comment résoudre le problème de programmation en utilisant du code de tableau blanc pour aider. Si l'explication est assez bonne, les autres bons programmeurs dans la salle corrigeront mentalement automatiquement toutes les fautes de frappe / erreurs sur le tableau.

Pour la plupart des types de postes d'équipe, il serait déraisonnable de NE PAS s'attendre à ce qu'un candidat soit en mesure d'expliquer et de noter sa tentative de solution.

Non, c'est une bonne chose de coder pour une entrevue, mais vous devez autoriser le code dans n'importe quelle langue raisonnable car il est généralement plus facile de former un codeur compétent dans une autre langue que d'obtenir un codeur moyen dans la langue que vous voulez, à un niveau compétitif.

Je dirais que c'est approprié, mais dans la plupart des cas, ce n'est pas un moyen efficace de savoir qui est bon en programmation et qui ne l'est pas. Si vous voulez faire un travail (= embaucher quelqu'un qui est capable), l'entretien devrait se concentrer sur la mesure des compétences réelles. Jusqu'à présent, la meilleure interview que j'avais travaillé comme ceci:

• Salutations, bienvenue par les RH.
• Quelques mots sur moi, sur l'entreprise, etc ... et elle a expliqué le reste de l'entretien.
• Elle m'a donné un ordinateur portable avec un programme qui manquait de quelques parties, avait échoué aux tests unitaires à cause de cela. Les parties manquantes y étaient commentées sous forme de textes, il s'agissait d'implémenter une tâche de base, comme créer une connexion entre quelques classes, et introduire une logique métier simple.
• Si tout s'est bien passé, les tests unitaires sont devenus verts.
• Au revoir et accord de revenir dans quelques jours.
• Ce jour-là, le leader m'a rencontré et m'a posé des questions sur le programme terminé, qu'est-ce que j'ai fait et pourquoi.
• Ce leader a également posé des questions sur mes expériences passées et sur quelques autres questions.

Donc, pour résumer: si vous cherchez de la main-d'œuvre dans un code de production, testez leurs compétences en environnement réel. Si vous êtes curieux de connaître leurs connaissances théoriques, il est préférable de leur poser des questions à ce sujet. Si vous êtes dépouillé de l'IDE, ou si vous êtes nerveux parce que vous devez programmer sur un tableau blanc devant quelqu'un, je peux comprendre, en particulier dans les TI, les gens sont parfois introvertis et beaucoup d'entre nous ne peuvent pas bien gérer ces situations, donc sur blanc à bord de notre efficacité sera pire qu'elle ne l'est réellement.

Je ne trouve pas cela déraisonnable à moins que la personne interrogée ait une mauvaise mauvaise écriture (ou je devrais dire une écriture) :-). En outre, la seule différence dans votre approche est l'utilisation d'une planche et d'un marqueur. Dans certains cas, les enquêteurs font cette chose, mais ils donnent un papier et un stylo à la place. Dans le cas où 3-4 personnes mènent l'entretien, je dirais que votre approche sera bien meilleure et adaptée.