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


30

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?"


13
IMHO assez raisonnable (et aurait empêché quelques embauches assez mauvaises chez mon ancien employeur, si seulement il avait été mis en œuvre).
Piskvor

3
C'est une chose vraiment déprimante à faire du point de vue de l'intervieweur. Comment les personnes qui revendiquent une expérience de 5 ans en programmation peuvent-elles ne pas avoir ces compétences de base? et 90% ne le font pas. (c'est 90% après avoir éliminé 70% des CV immédiatement, et un taux d'échec de 70% lors de l'entretien téléphonique)
Michael Shaw

18
We're not looking for perfect syntax.le rend raisonnable, en fait je dirais recommandé! Il est déraisonnable de critiquer les erreurs de syntaxe sur le codage du tableau blanc.
Qwerky

16
ne vous attendez pas non plus à une écriture parfaite. L'écriture de tableau blanc est une compétence que la plupart des gens n'ont pas, et la plupart des programmeurs, selon mon expérience, ont une écriture atroce pour le dire doucement, l'écriture verticale ne fait qu'empirer les choses.
jwenting

3
Approprié, oui. Efficace, non. Le seul développeur faible que j'ai personnellement engagé a brillamment fait un tableau blanc.
pdr

Réponses:


47

À 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.


1
merci pour la rétroaction ptolémée. très appréciée. vous êtes réponse décrivez exactement ce que je recherche ainsi que la façon dont j'aborderais aider le candidat à résoudre les problèmes. Mais comme vous l'avez également souligné, je suis sidéré par le nombre de personnes qui postulent pour des postes de 5 ans et plus qui ne peuvent pas le faire.
Eoin Campbell

1
Le plus grand danger est que la frustration s'installe et que vous offrez un emploi à quelqu'un qui a échoué à la tâche de programmation mais qui a bien réussi les autres aspects de l'entretien comme un test technique. La réalité est que ces candidats ont lu un livre et ont une bonne mémoire. Recrutez-vous des gens pour lire des livres? ou pour écrire des programmes?
Michael Shaw

@EoinCampbell, si les compétences en communication sont importantes pour vous, cela est tout à fait approprié.

1
donc, en tant que candidat, vous faites une erreur, je vous le signale un peu plus tard (pas tout de suite). Vous vous sentirez sous pression à ce moment-là. Il s'agit d'un élément clé de l'entretien, comment voyez-vous réagir? Pouvez-vous faire face à la pression d'une faute de frappe lors d'une interview? Si vous fondez sous cette pression, qu'allez-vous faire lorsque nous, en tant qu'équipe, sommes sous pression pour livrer des logiciels dans les délais?
Michael Shaw

1
J'ai utilisé le codage du tableau blanc, la partie positive est qu'il trouve de très bons programmeurs juniors. Le négatif du codage du tableau blanc est le taux d'échec élevé, mais ces personnes ne sont pas très bonnes pour commencer. J'ai demandé aux gens d'écrire aussi peu qu'une ligne de code sur le tableau et j'avais toujours des taux d'échec très élevés. D'un autre côté, on m'a posé des questions sur le tableau blanc en tant qu'interviewé et j'ai toujours trouvé les questions raisonnables. Je préfère de beaucoup le codage du tableau blanc à la liste des algorithmes préférés des gens pour des problèmes spécifiques.
Michael Shopsin

15

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.


Je n'utilise délibérément pas d'ordinateur dans les interviews à cause de l'effet d'intellisense. Un candidat inexpérimenté programme en appuyant sur la touche. et en sélectionnant quelque chose dans la liste. Un tableau blanc rend cela très évident ...
Michael Shaw

5
@Ptolémée: pensez-vous vraiment? Pour un exercice typique de tableau blanc comme «programmer une recherche d'abord en profondeur dans un arbre», à quoi servirait Intellisense?
nikie

2
Les tableaux blancs / papiers ne tombent pas en panne et tout le monde sait comment écrire dessus. Si vous me donnez IDLE pour résoudre un problème, je vais supposer que vous êtes un idiot, et si vous me donnez Eclipse, je vais passer la moitié de mon temps à combattre les raccourcis clavier par défaut.

6
Intellisense (et les autres fonctionnalités de saisie semi-automatique des IDE aussi, j'en suis sûr) peut être désactivé. Ou vous pouvez leur donner le Bloc-notes (ou une alternative plus agréable comme Notepad ++ qui fait la mise en évidence de la syntaxe mais n'a pas de saisie semi-automatique ou similaire). Bien sûr, cela peut planter, mais de façon réaliste: combien de bugs showstopper avez-vous rencontrés dans le Bloc-notes?
un CVn

3
Même s'il ne s'agit que de notepad.exe, il est beaucoup plus facile de travailler avec du papier ou un tableau blanc. Vous pouvez insérer ou supprimer des lignes, ce qui est très pénible sur les supports physiques.
CodesInChaos

10

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.


6
Si une partie de votre processus de recrutement consiste à proposer un contrat à durée déterminée standard pour 3 mois, combien de personnes démissionneraient réellement d'un poste permanent pour accepter votre offre?
Michael Shaw

1
Je voulais dire en dernier dans le sens où c'était le dernier élément de ma liste. Je mélange l'ordre des choses dans l'entretien en fonction de la progression de la conversation et de l'endroit où je pense que ses forces et ses faiblesses se trouvent. Quant à leur offrir un contrat à court terme ... ce n'est tout simplement pas réaliste dans une petite entreprise du monde réel. Je n'ai pas le temps / les ressources nécessaires pour prendre des risques de voltige de 3 mois sur des personnes qui pourraient ne pas s'entraîner et comme l'a souligné Ptolémée, je doute que les candidats soient trop enthousiastes.
Eoin Campbell

"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." J'ai toujours senti que c'était important de le noter, en particulier avec de nouvelles personnes entrant ou sortant de l'université. Je sais que j'étais une épave dans mes premières interviews, m'inquiétant à ce point au point que j'ai foiré certaines des questions les plus faciles juste parce que j'étais si nerveux. Certes, vous ne pouvez pas faire grand-chose. Tout ce que je pouvais faire était de passer à la prochaine entrevue, pour finalement devenir à l'aise avec le processus.
The Jug

1
@TheJug est tout à fait d'accord et nous serons beaucoup plus gentils avec les juniors et les diplômés pour nous assurer qu'ils ne sont pas submergés par le processus, mais nous avons eu des développeurs seniors (7-8 ans exp) aux prises avec cela.
Eoin Campbell

1
"Embauchez-les pour un tout petit projet (mais réaliste) ..." - suggérez-vous de "recruter", par exemple, trois des candidats qui ont postulé pour un poste, même si vous prévoyez de n'en conserver qu'un? Cela me semble très injuste! Cela n'améliorerait probablement pas l'esprit d'équipe non plus.
nikie

8

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.


7
Je ne connais pas ce type, car il n'a pas été embauché.
Kevin Cline,

4
@kevincline au détriment de l'entreprise, à moins que vous ne gagniez de l'argent en ayant les gens nerveux.
JayPea

1
@JayPea: comment puis-je savoir qu'une personne est un codeur génial si je ne peux pas lui sembler coder? La seule alternative serait une recommandation d'une personne déjà membre du personnel. Tout le monde aime embaucher sur des recommandations fiables, mais c'est un assez petit groupe.
Kevin Cline

1
@kevincline Lisez ma réponse, je ne dis pas que vous ne devriez pas faire de codage de tableau blanc lors de l'entretien avec le développeur.
Tamás Szelei

@JayPea Je suis sûr que le fait d'avoir des employés qui ne sont pas nerveux dans des situations de stress élevé est un facteur important dans la réussite financière de nombreuses entreprises.
Kyle Strand

4

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)


c'est plus que de la communication. ils doivent être capables de communiquer, bien sûr, mais ils doivent également pouvoir me dire leur solution au problème simple.
Eoin Campbell

4

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.


1
Les tableaux blancs sont immuables? Il suffit d'effacer quelque chose et de le réécrire sur un coup de tête, c'est ce qui les rend utiles, en particulier l'enseignement. Vous devez vivre dans un univers alternatif.
whatsisname

Peut-être immuable est le mauvais mot (je l'ai pris de medium.com/dima-korolev/… - qui pense que c'est un avantage). Pourtant, par rapport à un éditeur, il est difficile d'ajouter quelque chose pour lequel vous n'avez pas laissé d'espace.
iGEL

3

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.


"il aurait déjà dû être établi / déterminé que la personne interrogée peut programmer" - comment? Soit vous avez une pré-entrevue, auquel cas la question du PO devient de savoir si le codage du tableau blanc est approprié dans une pré-entrevue, soit vous prenez effectivement la parole du candidat pour cela, ce qui est une catastrophe. Les recruteurs et les CV peuvent mentir (et le font), les blogs et les dépôts github peuvent être plagiés.
Julia Hayward

@JuliaHayward: Établir les capacités de codage de base d'un candidat dans une pré-entrevue est une chose différente. Vous n'avez en fait pas besoin d'inviter quelqu'un sur place pour le faire. Vous pouvez leur envoyer un petit problème qu'ils peuvent résoudre. Discutez éventuellement de cette solution (ou du code github) en personne. Plus important encore: il est très peu probable que vous trouviez un candidat capable de maîtriser avec élégance le type de problème que je suggère, tout en ne pouvant pas résoudre les problèmes de type fizzbuzz. L'entretien doit être utilisé pour déterminer dans quelle mesure le candidat est capable de faire face à la complexité typique des problèmes du monde réel.
back2dos

Il se peut que vous n'ayez pas besoin d'avoir quelqu'un sur place, mais au moins vous devriez être au téléphone avec le candidat pour parler de son exercice de codage, quoi que vous utilisiez. Le simple fait de remettre une question et d'attendre l'envoi d'un fichier zip comporte toujours tous les risques d'usurpation d'identité; comme exemple extrême, j'ai fait le test pour FooCorp une fois, puis juste par intérêt googlé "FooCorp coding test" par la suite - et j'ai trouvé que quelqu'un avait publié une assez bonne solution.
Julia Hayward

@JuliaHayward: Si vous posez le même problème à chaque candidat, alors bien sûr, la réponse devient compatible avec Google. Pas étonnant, non? Mais encore une fois, ma réponse demeure: ne faites pas de codage de tableau blanc au niveau du fizzbuzz dans une interview. Cela montre simplement que vous n'avez pas pris la peine de préparer un bon et intéressant problème. Comme vous l'avez dit vous-même, il existe des moyens d'établir des capacités de programmation de base bien avant d'inviter les candidats sur votre tableau blanc.
back2dos

3

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.


est-ce seulement votre avis ou vous pouvez le sauvegarder d'une manière ou d'une autre?
moucher

2
@gnat Je pose juste une question. La deuxième moitié de la réponse est mon avis, oui, mais cela devrait être assez clair par le langage utilisé. De plus, la question elle-même commence par reconnaître qu'elle est subjective et demande spécifiquement des avis sur la question. Je ne pense pas que le downvote était justifié.
Kevin C.21

@Kevin C. Je pense que quelle que soit votre formulation, vous faites un très bon point ici. Le codage du tableau blanc est différent du codage informatique. Est-ce une opinion? Certainement pas, tant que les tableaux blancs ne peuvent pas exécuter de code.
Leandro Caniglia

2

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.


2

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.


0

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.


0

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.


-1

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.


1
"La plupart ou tous les enquêteurs font cette chose" c'est assez rare IMO.
Kirk Broadhurst

Je suppose que tout le monde fait ça. Il est rare qu'ils présentent un PC ou un ordinateur portable juste pour vérifier si vous résolvez un problème de codage particulier. Mais peut-être que les choses sont différentes chez nous. Si vous voulez, je peux modifier cette chose dans la réponse ??
Pankaj Upadhyay

voyez, je suis d'accord, c'est assez rare ... J'ai occupé 4 emplois au cours des 9 dernières années et on ne m'a jamais demandé d'écrire du code sur papier / wb. Tout codage a été effectué sur un IDE. c'est pourquoi je me demande si c'est inapproprié. Je m'attendrais à ce qu'un développeur puisse frapper le code "Inverser une chaîne" en quelques minutes tout au plus sans l'aide d'IDE / Intellisense.
Eoin Campbell

J'ai fait le montage en fonction de votre expérience. Lors de deux entretiens que j'avais également passés, ils m'ont donné un stylo et du papier pour écrire comment imprimer une série de Fibonacci et un algorithme pour la fusion. Donc, je pensais que la plupart des choses se passaient de cette façon :-)
Pankaj Upadhyay

Je dois souligner que je n'ai jamais eu à écrire de code sur un ordinateur; J'ai dû écrire du code sur le papier deux fois ( à la fois quand j'étais junior) et je devais dessiner un diagramme d'architecture sur un tableau blanc une fois . Cela fait environ 20 entrevues ...
Kirk Broadhurst
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.