FizzBuzz - vraiment?
Quand il s'agit de questions "test d'interview", le sujet de FizzBuzz revient souvent. Il y a aussi un Coding Horror post à ce sujet.
Maintenant, si vous vous embêtez à lire des sites comme celui-ci, vous êtes probablement moins susceptible d'être dans le groupe démographique des programmeurs qui trouveraient FizzBuzz tout sauf trivial.
Mais est-il vraiment vrai que 99% des programmeurs auront du mal avec ça?
Vraiment?
Quelles sont les preuves pour étayer cela?
Quelques exemples concrets seraient très utiles pour répondre à cette question.
99%? Non. Un pourcentage significatif? Oui. D'après ma propre expérience directe d'interviewer des gens, je peux en témoigner. Cela peut vous sembler insignifiant, mais il y a beaucoup de gens dans le domaine de la programmation qui ont plus ou moins truqué leur chemin pendant des années et postulent sur des postes de niveau non-entrée et échouent celui-ci.
Même si vous POUVEZ facilement le résoudre, mais vous me donnez une énorme statique sur le fait qu'on vous demande de faire une telle tâche subalterne comptera contre vous. Faire partie d'une équipe signifie parfois devoir faire des choses que vous pourriez ne pas apprécier mais qui sont nécessaires. Si tout de suite, avant même que nous commencions à travailler ensemble, vous pensez qu'il serait préférable d'essayer d'affirmer votre statut spécial d'être au-dessus de faire quelque chose que je vous ai demandé de faire, alors cela agira comme une marque contre vous.
Je ne me soucie pas nécessairement de l'élégance de votre solution (bien que ce serait bien), mais en vous voyant essayer sur un tableau blanc et en discutant, cela me montre que vous êtes au moins prêt à essayer . Si vous vous indignez et dites quelque chose comme "Je suis un résolveur de problèmes, pas un singe de code!" alors vous serez renversé une cheville.
J'ai eu des personnes interviewées qui refusaient carrément de commencer à essayer. Refusez simplement. Non. Euh. Je ne le ferai pas. Je pose une ou deux questions polies, je les remercie de leur temps et je termine l'interview.
Je dis cela en tant que manager et développeur.
Je pense que 99% des programmeurs qui postulent pour un emploi (et ne l'obtiennent pas) peuvent avoir du mal à le faire. Mais pas 99% des programmeurs qui occupent un emploi de manière productive.
C'est la nature de notre processus de recherche d'emploi moderne. Beaucoup de personnes qui postulent ne sont pas qualifiées.
Ce message Coding Horror témoigne également de la façon dont nous enseignons l'informatique de nos jours. Dans le passé (en particulier au MIT), vous deviez apprendre des choses comme LISP, ce qui vous oblige à saisir des concepts comme la récursivité.
De nos jours, les gens apprennent Java parce qu'il est largement utilisé dans l'industrie, et l'accent a été mis sur la syntaxe plutôt que sur la réflexion approfondie en programmation. Je n'aime pas Java; en fait, je pense que c'est un idéal premier langage de programmation. Mais je n'ai pas vu mes instructeurs enseigner avec lui des principes de programmation approfondie.
Je déteste dire ça mais
La principale raison pour laquelle j'ai vu des questions de programmation ne pas obtenir de réponse est la faute du demandeur plutôt que du répondeur.
Je me souviens clairement d'une interview où on m'a demandé comment créer un algorithme de recherche de collection particulier qui s'exécuterait en constant temps (même nombre de recherches quel que soit le nombre d'éléments dans la collection). J'ai tâtonné et je suis tombé dessus pendant 20 minutes avant d'abandonner. C'est à ce moment-là que ce génie réalisant l'interview a commencé à démontrer que la réponse était quelque chose qui fonctionnait en presque constant, mais toujours pas constant. Un peu comme dire "Donnez-moi une réponse de zéro" puis accepter 0,1.
Bref, j'ai vu trop de cas où une personne interrogée pose une question qui ne répond pas aux critères suivants:
- Ils connaissent toutes les bonnes réponses possibles.
- Ils savent pourquoi les bonnes réponses sont correctes.
- Ils savent comment fournir suffisamment d'informations sans donner de réponse.
- Les questions de "résolution de problèmes" ne reposent pas sur la connaissance d'un fait non divulgué (c'est le plus gros problème que j'ai vu).
- Il vous faudrait moins d'une minute pour écrire la réponse si vous n'aviez pas à le comprendre. Si cela prenait 5 minutes juste pour taper le code, cela demande vraiment plus de résolution de problèmes que ce qui peut être inséré dans la partie verbale de l'entretien.
- Les questions sont basées sur plus que "Un problème que j'ai rencontré une fois ou qui m'a été donné à l'école et vous devez donc savoir comment le résoudre en ce moment". Je parie que vous avez eu plus de 2 minutes pour y répondre, pourquoi ne donnez-vous pas la même courtoisie au candidat?.
Sérieusement (1), je pense que demander aux gens d'écrire du code dans la partie verbale d'une interview est stupide.
Sérieusement (2), je pense que interviewer des gens sans leur demander d'écrire du code est aussi stupide.
Sérieusement (3), vous devez soit leur donner des "devoirs", leur demander d'apporter des exemples de code, soit leur donner un ordinateur portable et quelques questions et un bureau calme pour travailler dessus. Laissez-les ensuite tranquilles pendant qu'ils y travaillent. Je préfère généralement cette dernière approche car elle limite leur capacité à obtenir de l'aide extérieure (triche) et je peux la chronométrer.
J'ai lu l'article Coding Horror que vous mentionnez, et mon opinion est que Jeff a raison ... mais à quand remonte la dernière fois qu'il a été interviewé?
Lorsque vous êtes interviewé, vous êtes généralement en situation de stress élevé, et vous devez souvent répondre à des questions théoriques (pas d'intelligence, pas de google, pas de resharper, ... seulement votre mémoire troublée par le stress). C'est la même chose dans les tests. Le stress ne vous aide pas.
J'ai remarqué que la seule façon de savoir si quelqu'un est apte à un poste est de travailler avec lui pendant un certain temps ... Il suffit de prendre les 10 dernières personnes que vous avez embauchées sur 100 (peut-être plus), combien était vraiment bon louer???
n employeur devrait embaucher un résolveur de problèmes, pas un singe de code qui connaît les modules.
Vous ne pouvez pas tester "pendant un certain temps tous les candidats", il est donc nécessaire de les interroger. C'est pourquoi je concentre mes questions sur cela (résolution de problèmes) et je vérifie les références passées.
Mon opinion est que le FizzBuzz est dangereux pour l'entreprise qui recherche des développeurs pour freiner sa croissance.
Il vous suffit de rechercher sur FizzBuzz. Il y avait une énorme vague d'articles de blog là-dessus. De manière générale, le blogueur a déclaré: "J'ai dit aux gens de l'écrire dans [une langue] et voici le genre d'erreurs qu'ils ont commises:", puis il a énuméré quelques pièges. Le plaisir commence dans les commentaires où les gens disent "ha! C'est trivial dans [une autre langue], tout ce que vous avez à écrire est ceci:" suivi du code. Le commentaire suivant trouve invariablement des bogues dans ce premier. Il semble que certains très bons développeurs ne réussissent pas du premier coup, dans n'importe quelle langue. Quelques erreurs:
- J'ai demandé 1 à 100 et vous en avez fait 1 à 99 ou 0 à 99
- déconner s'il faut imprimer le numéro avec le pétillement et/ou le buzz
- désaccords sur "fizzbuzz" vs "fizz-buzz"
- optimisations manquées, comme comparer deux fois quand une fois ferait
- beaucoup plus
Lorsque j'embauche, je demande aux gens de coder sur le tableau blanc pour moi, rien de plus compliqué (je sais, vous ne pensez pas que c'est compliqué) et de nombreux candidats échouent complètement. Je veux dire écrire du style vb If, Then, End If mais mettre des accolades également (juste pour être du bon côté, je suppose) ou écrire C # (et demander d'abord, C #?) Mais sans point virgule nulle part. Ne me lancez pas sur des erreurs logiques!
J'ai récemment été chargé d'interviewer plus de 50 programmeurs pour un poste senior où ils travailleraient principalement avec PHP.
J'ai jeté le problème de fizzbuzz à l'examen de dépistage, principalement pour m'amuser et parce que je voulais dix bonnes questions et je n'en avais que neuf. Mon intention, à l'époque, était de montrer aux gens que nous pouvons aussi nous amuser, même sur des questions d'entrevue.
80% des candidats ont résolu le problème, mais n'ont pas utilisé l'opérateur de module.
15% des candidats n'ont pas pu résoudre le problème.
5% des candidats ont résolu le problème en utilisant l'opérateur de module.
Bien que mon échantillonnage soit assez limité (50 candidats d'un pays), je peux vous dire que:
95% d'entre eux avaient un BS ou plus dans un programme CS (les universités ici rivalisent en essayant de rendre le son CS plus spectaculaire).
J'étais vraiment étonné. Eh bien, effrayé .. mais étonné. Je ne pensais pas que je serais près de reproduire les résultats, car le problème est devenu si populaire. Cela me montre que 5% de mes candidats ne sont peut-être pas des super programmeurs, mais au moins ils lisent des blogs liés à la programmation.
Lors de ma dernière embauche, j'ai eu 3 travailleurs de la construction avec 0, je répète zéro, la formation en programmation ou l'expérience postulent pour un poste de développeur de logiciels.* Voilà donc le fond du canon. Si vous supposez une répartition normale des compétences, vous pouvez voir comment le niveau de compétence moyen sera assez faible et même "supérieur à la moyenne" (parmi les candidats) sera encore relativement mauvais.
Maintenant, si vous ne fouillez que les candidats qui avaient ce qui semblait être une certaine capacité de programmation, vous constaterez que vous avez maintenant:
- menteurs
- les amateurs de mot à la mode (j'ai lu un article sur .NET une fois)
- mauvais programmeurs réels
- les personnes qui ont utilisé une technologie pour mener à bien un projet, mais qui n'en ont pas entendu parler (voir les questions fizzbuzz sur idisposable pour les identifier)
De plus, certaines questions "fizzbuzz" que j'ai vues sont spécifiques à un domaine. Vous pouvez progressivement développer avec un langage/framework x pendant un certain nombre d'années (d'où z ans d'expérience avec x) et n'en avoir rencontré aucune partie (les développeurs de bibliothèque ne connaissent pas grand-chose au développement de composants d'interface utilisateur, par exemple.)
De même, de nombreux développeurs effectuent le développement de la maintenance de nos jours, de sorte que leurs compétences en architecture/conception peuvent être faibles dans certains domaines.
Maintenant, je ne sais pas si 99% est précis, mais l'IME est toujours assez élevé. Au moins dans la plage de 80%.
* Non, nous n'avons pas appelé ou même donné un deuxième regard sur ces applications.
Oui vraiment. Probablement pas à 99% mais toujours assez élevé. J'avais l'habitude d'interviewer des étudiants en informatique pour des stages et des embauches à temps plein. J'interviewais environ 25 étudiants dans un collège. On nous a dit de ne pas poser les mêmes questions, car les étudiants ont parlé. J'ai vite compris que cela n'avait pas d'importance, car je ne ferais que 3 ou 4 étudiants sur les 25 qui pourraient répondre à ma première question. "Ecrire strcmp"
Je leur ai demandé d'écrire une fonction pour comparer deux chaînes. Peut-être utiliser la fonction pour trier les mots d'un dictionnaire. Vous seriez étonné du nombre d'élèves qui n'ont pas compris comment comparer deux mots, et encore moins comment écrire la fonction. Et certains de ces étudiants ont affirmé avoir obtenu tous les A en CSc.
La chose est que la programmation est TRÈS DIFFICILE. Beaucoup de gens aiment penser qu'ils savent programmer, mais ils ne le font pas.
Quelques idées:
Je ne le reprocherais pas à quelqu'un si leur programme avait des bugs mais ils avaient clairement la bonne idée. Le débogage fait partie de la programmation.
Je pense qu'il est triste que tant de gens postulent pour des emplois qu'ils ne savent pas qu'ils ne peuvent pas faire. Cela me semble être un problème avec l'économie.
Il est vraiment facile de poser de mauvaises questions aux gens, où la seule réponse "correcte" est celle que l'enquêteur donnerait.
Ce test couvre très bien plusieurs choses que je veux savoir sur un programmeur que je pourrais embaucher:
- Pouvez-vous même programmer du tout?
- Pouvez-vous écrire un programme à partir de zéro (car tout le monde ne peut pas !!!)
- Pouvez-vous résoudre un problème sans plus - y penser.
Pour élaborer sur le dernier point, il existe d'innombrables solutions au fizz-buzz. Allez-vous pour la lisibilité? La vitesse? Brièveté? Essayez-vous de terminer l'écriture du programme rapidement? Comment un programmeur attaque ce problème simple est très révélateur. Si un programmeur ne peut pas choisir une solution et la mener à terme, qu'est-ce que cela vous apprend sur la façon dont cette personne va effectuer une tâche réelle?
Malheureusement, de nombreuses personnes dont le curriculum vitae est impressionnant semblent manquer de compétences de base en programmation. J'ai vu de nombreux cas où les personnes qui indiquent C et C++ dans leur curriculum vitae ne pouvaient pas répondre aux questions de base sur les pointeurs.
Je pense qu'une partie de la raison pour laquelle cette question est si populaire est qu'il y a plus d'une façon de répondre, et selon la direction que le candidat choisit d'aller peut vous donner un aperçu de la façon dont ils codent. De grands exemples peuvent être vus ici si vous avez 10K rep sur Stack Overflow.
Quant à la statistique de 99%, vérifiez d'où vient ce nombre. C'est probablement biaisé. S'il est basé sur des programmeurs débutants qui interviewent pour leur premier emploi, alors oui, je peux voir que cela est possible, surtout si la majorité de leurs candidats sortent tout droit du collège. Je peux en fait penser à quelqu'un qui écrirait probablement une condition de 100 if comme une solution à ce problème.
Il y a deux types de personnes que j'espère que FizzBuzz m'aidera à éviter.
- Chanceurs n'ayant aucune connaissance de la programmation ou aucune connaissance pertinente de la programmation. Habituellement, vous pouvez les reconnaître dans le CV mais pas toujours et leur confier une tâche de programmation simple est un bon moyen de faire comprendre qu'ils ne sont pas programmeurs.
- Diplômés d'écoles Java, qui ont suivi un cours ou un diplôme en programmation mais ne savent pas vraiment comment programmer. Ces personnes peuvent être plus difficiles à filtrer car elles peuvent parler de théorie, mais elles n'ont tout simplement aucune compétence pratique. Mettre un problème simple devant eux et demander une solution et une explication de la solution est une assez bonne façon de voir la différence entre un Petra Java et un Paula Bean.
Dans les deux cas, je ne me soucie pas vraiment d'une implémentation parfaite. Le test que vous devez faire avec les personnes qui postulent à des emplois de développeur est qu'elles peuvent programmer du tout.
Cela dit, je ne m'embêterais probablement pas avec ce test particulier pour plusieurs raisons maintenant. Tout d'abord, il est très bien connu et l'un des groupes ci-dessus serait rapide pour l'essayer. Deuxièmement, je préférerais utiliser les questions sur l'écran du téléphone de Steve Yegge pour éliminer les non-programmeurs avant de les amener. Si quelqu'un reconnaissait ces questions, cela impliquerait d'avoir lu le blog de Steve Yegge qui me suggèrent qu'ils étaient dans le top 1% des développeurs qui prennent leur profession au sérieux et méritent certainement une interview. De même, si quelqu'un avait un bon représentant ici ou sur SO je serais enclin à les interviewer.
Il est difficile de croire que les développeurs ne peuvent pas coder FizzBuzz tant que vous ne voyez pas les "neuf sur cinq" qui copient et collent leur travail ensemble et essaient de ne pas écrire de code. Je ne pouvais pas y croire quand j'ai entendu l'un de nos développeurs seniors enseigner à un développeur C #, avec 3 ans "d'expérience", comment utiliser un dictionnaire. Des interfaces? Modèles de conception? stdout? YAGNI? Ma piste n'avait jamais entendu parler de YAGNI! C'est incroyable ce que ces gens ne savent pas.
Je le crois maintenant. Je pense aussi qu'il y a trop de développeurs qui en font juste assez.
Je trouve la déclaration que 99% des programmeurs sont incapables de programmer ou de résoudre un test de codage simple très exagéré. Dans le cas du test FizzBuzz, soit vous avez déjà rencontré ce problème et pouvez le résoudre facilement avec l'opérateur modulo, soit vous ne l'avez pas rencontré auparavant et vous aurez du mal à le résoudre. Il ne dit rien à l'intervieweur de vos compétences en programmation.
Je pense que le problème avec de nombreux programmeurs laissant apparemment une mauvaise impression lors d'une interview réside dans la nature des méthodes techniques d'interview. Les intervieweurs s'attendent à ce que les candidats mémorisent et reproduisent instantanément la syntaxe du langage, les détails et la complexité de calcul des structures de données, des architectures matérielles, des modèles de conception, etc., etc. Le domaine de l'informatique/génie logiciel est vaste. Il est impossible et insensible d'essayer de tout mémoriser.
Dans le monde réel, la clé est de pouvoir comprendre le problème de programmation/conception qui vous est attribué et de savoir où trouver des informations (votre IDE, pages de manuel, livres, google, etc.) comment résoudre votre problème. C'est cependant quelque chose que les enquêteurs ne testent jamais.
Je suis encore un programmeur relativement junior (j'ai codé pour de l'argent pendant environ 2 ans et codé à titre professionnel comme responsabilité secondaire pendant environ 2 ans auparavant), alors utilisez suffisamment de grains de sel.
J'ai de l'expérience en faisant un premier écran pour les codeurs d'un projet de grande entreprise (nous savions un peu que le projet était condamné, mais bon, ils voulaient quand même payer). En tant que seul programmeur de l'entreprise à embaucher, on m'a confié la tâche d'examiner les CV et de sélectionner les candidats.
C'était pour un projet gouvernemental peut-être n'a probablement pas attiré les candidats les plus talentueux, mais je n'ai reçu aucune candidature de quiconque possédant un compte github qui avait réellement du code affiché, ni de personne ayant un portefeuille, j'ai donc utilisé fizzbuzz (littéralement le problème exact) comme premier passage sur toute personne qui semblait pouvoir programmer.
Je l'ai préfacé d'une pseudo-excuse déclarant que je savais que c'était stupide mais que je voulais juste voir n'importe quel code de travail, et s'ils le voulaient, ils pourraient envoyer un autre exemple de valeur égale ou supérieure ou vraiment n'importe quoi, mais ce fizzbuzz suffirait.
Le résultat: je n'ai pas reçu une seule réponse qui était réellement correcte, ce qui est époustouflant compte tenu du volume de réponses sur Internet. Personne n'a même pris la peine de plagier. Nous devions simplement embaucher des personnes qui avaient précédemment travaillé sur les versions précédentes du projet qui avaient échoué.
Après le choc initial de l'exercice et la déception sur la façon dont les logiciels/contrats gouvernementaux étaient vissés, je me sentais beaucoup mieux dans mes propres compétences, donc de petites victoires?
Edit: Par non correct, je ne veux pas dire une erreur hors-par-un (c'est-à-dire que j'ai demandé jusqu'à 100 et non 99) ou un autre bug innocent qui est une solution facile. Je veux dire non fonctionnel, soit ne fonctionnera pas/compilera/etc ou a clairement montré que le problème n'était tout simplement pas lu et compris, également une partie importante a retiré l'application et personne n'a envoyé un autre code à la place.