Est-ce une mauvaise pratique d'entrevue que les candidats écrivent une implémentation de liste chaînée?
En lisant ce site et SO J'ai vu de nombreuses histoires de questions et réponses d'entrevue disant qu'un candidat devait implémenter une liste chaînée à partir de zéro. Habituellement, c'est un exercice "de gimme" pour programmer des candidats comme écrit FizzBuzz. L'idée est que si le candidat ne peut pas le faire, il ne peut pas programmer et doit être rejeté presque immédiatement.
Cependant, je ne peux m'empêcher de penser que cela pourrait être une mauvaise pratique pour les raisons suivantes:
- Les langages modernes de niveau supérieur comme C # et Python utilisent nativement les listes de manière intensive; l'écriture de votre propre objet de liste liée ne serait requise que dans des circonstances inhabituelles et même alors probablement déconseillée.
- Les langages de niveau inférieur comme C++ ont des bibliothèques standard avec des itérateurs/conteneurs de liste et des objets.
- À la lumière des deux premiers points, les codeurs peuvent passer des années sans même penser à mettre en œuvre eux-mêmes une liste (liée, doublement liée, etc.). Certains peuvent même ne pas vraiment voir de telles choses depuis le collège.
- La puissance de calcul n'est pas non plus le facteur qu'elle était il y a des années, donc l'efficacité via des pointeurs n'est plus le problème qu'elle était (en général).
- Une simple recherche sur le Web de quelque chose comme "exemple de liste chaînée" ferait apparaître de nombreux exemples de code qui pourraient simplement être mémorisés et crachés, n'indiquant pas vraiment la véritable compétence du demandeur.
Je dois dire que l'utilisation d'une liste chaînée pour mener à à composition non limitée questions/discussions sur les capacités de résolution de problèmes/réflexion critique des candidats est probablement une très bonne pratique d'entrevue. De toute façon, un intervieweur peut vraiment voir à quoi ressemble un candidat et comment il pense qu'il est massivement bénéfique.
Je pense que cette approche binaire "pas de code de liste liée, pas de travail" pour les programmeurs travaillant sur une application de bureau ou Web est un peu dépassée. Cela pourrait également être très nocif; un candidat qui ne se souvient pas comment travailler correctement avec la tête d'une liste pourrait être un excellent codeur et collègue et être perdu dans le mélange. Pensées?
EDIT : Il y a de nombreux (bons) commentaires suggérant que si c'est une bonne ou une mauvaise question à poser dépend du contexte du travail. Je suis tout à fait d'accord, alors laissez-moi reformuler cette question: la mise en œuvre d'une liste chaînée est une question d'entretien courante pour un large éventail de travaux de codage, similaire à des questions comme FizzBuzz ou l'écriture d'une fonction récursive pour le calcul des factorielles. Cette question a-t-elle suffisamment d'utilité pour être utilisée couramment pour évaluer les candidats à la programmation à tous les niveaux? Ou devrait-on considérer une mauvaise question à poser, à l'exception des postes de "développeur principal, équipe des listes liées intégrées"?
Si répondre à la question vous dit ce que vous voulez savoir sur un candidat, c'est une bonne question d'entrevue. Si cela ne vous le dit pas, c'est une mauvaise question.
Les questions simples comme FizzBuzz servent un objectif spécifique. Si un candidat ne peut pas coder FizzBuzz, il ne peut tout simplement pas coder et vous pouvez terminer l'interview plus tôt. Je noterais que la mise en œuvre d'une liste chaînée n'est que légèrement plus difficile, mais cela peut démarrer une conversation sur les structures de données en général qui en révélera beaucoup.
N'oubliez pas qu'aucune question d'entrevue ne vous dira tout ce que vous voulez savoir. Vous devez vraiment avoir un groupe de questions prêt. Vous devriez poser des questions dans une séquence du plus simple au plus difficile afin de pouvoir trouver la limite de ce que le candidat sait. Si vous posez une question et qu'ils la clouent, vous ne savez toujours pas quoi d'autre ils font ou ne savent pas.
Concernant votre montage:
Cette question a-t-elle suffisamment d'utilité pour être utilisée couramment pour évaluer les candidats à la programmation à tous les niveaux? Ou devrait-on considérer une mauvaise question à poser, à l'exception des postes de "développeur principal, équipe des listes liées intégrées"?
Je pense que c'est une bonne question d'ordre général qui pourrait être utilisée pour évaluer pratiquement n'importe quel candidat à la programmation. Il doit simplement faire partie d'un plus grand groupe de questions. Ce serait un bon brise-glace pour de nombreux types de postes (même si le candidat ne peut pas implémenter une liste chaînée à partir de zéro, il peut peut-être expliquer comment il en a déjà utilisé une et quelles sont les fonctions clés), ou le début de une longue séquence de questions plus avancées pour le poste "Développeur principal, Équipe des listes liées intégrées".
J'ai manqué des emplois uniquement parce que mon esprit s'est vidé de puzzles simples comme celui-ci. J'ai également réussi avec brio de telles énigmes dans d'autres interviews - je sais comment implémenter une liste chaînée dans un environnement sans pression. Je n'ai jamais eu à me plaindre de mes capacités de la part de quelqu'un avec qui j'ai travaillé, alors peut-être que je ne devrais pas penser que j'ai manqué un emploi, je devrais penser qu'ils m'ont manqué.
Alors oui, je pense que c'est au mieux une pratique discutable, mais je la comprends. J'ai également envisagé la possibilité que ce ne soit pas la faute de la question mais celle de l'auteur de la question, pour en faire une situation de haute pression.
Personnellement, je préfère poser des questions ouvertes sur un problème que le candidat a déjà résolu - récemment, si possible, et couvrant à la fois les problèmes de codage et de processus. S'ils peuvent apporter des exemples de code, c'est fantastique.
Il faut définir le type de travail de programmation. Si vous êtes en train de développer des compilateurs et des algorithmes, des questions à ce sujet doivent être attendues. Si vous êtes dans des applications de type métier et que vous vous attendez à ce que le candidat fasse des applications CRUD, alors, la connaissance du concept (sans écrire de programme) peut être suffisante. Aujourd'hui, la connaissance des différentes technologies nécessaires pour faire le travail spécialement dans le type d'applications LOB remplace le besoin d'algorithmes soignés.
Ma réponse est "ça dépend". Je poserais cette question si un candidat a inscrit C ou C++ sur son CV. Demander à implémenter une liste chaînée est un bon test pour la compréhension des pointeurs qui est absolument essentiel pour un programmeur C ou C++.
D'un autre côté, si un candidat ne prétend pas connaître le C ou le C++, je ne lui demanderais pas de mettre en place une liste chaînée, mais j'envisagerais de lui poser des questions. Expliquez à un niveau élevé comment fonctionne une liste chaînée. Quelle est la complexité de l'ajout d'un élément en tête de liste? La queue de la liste? Insérer un élément au milieu de la liste? Quand utiliseriez-vous une liste par opposition à un tableau? Ce sont des concepts fondamentaux de structure de données que, à mon humble avis, chaque programmeur devrait connaître.
Je ne considérerais pas cela comme une mauvaise question d'entrevue. Beaucoup de compréhension et de programmation de la structure de données commence par une très bonne compréhension des listes liées. Cela dit, il y a quelques mises en garde:
1) C'est une question de type pétillant. Vous validez simplement quelque chose de très basique: la personne comprend-elle une liste chaînée? Posez-la et continuez.
2) Il y a le défi avec les listes chaînées que les langues qui sont très adaptées pour montrer votre compréhension des concepts de listes chaînées (par exemple, C) peuvent ne pas être les mêmes que la langue avec laquelle elles travailleront au travail. Vous pouvez démontrer une compréhension de base dans n'importe quelle langue avec des structures, bien sûr, mais demander à un candidat de réimplémenter une liste chaînée dans Erlang sans utiliser [] n'est pas le même défi et ne vous dira pas la même chose sur la compréhension d'un candidat comme leur demandant de le faire en C. Leur demandant de le faire en C si le travail est autour de Java manque également quelque peu le point.
3) Avec cela à l'esprit et les défis généraux de la "programmation du tableau blanc", en posant ce genre de question, j'accepterais des pseudocodes ou des diagrammes pour autant qu'ils démontrent une compréhension des principes de base. Je ne demande pas aux gens d'écrire sur un tableau blanc du code syntaxiquement et logiquement parfait, surtout s'ils peuvent ensuite se retourner et identifier les problèmes logiques lorsqu'on leur demande de le revoir. YMMV.
Lorsque je donnais des interviews, on m'a souvent demandé des implémentations de listes chaînées et certains algorithmes centrés sur des listes chaînées. J'ai résolu la plupart d'entre eux, et certains d'entre eux m'ont obligé à exercer mes neurones un peu.
Si jamais je prenais une interview, j'irais pour une sorte d'implémentation de liste chaînée, non pas pour tester la qualité d'une personne dans le codage, mais pour vérifier à quel point une personne prête attention aux détails. Tout le monde peut écrire une liste chaînée, mais ce sont les cas limites où même certains bons programmeurs échouent. Ne lui demandez pas: Write a code for linked list in C/C++. Demandez-lui d'écrire une liste chaînée générique en C (pas C++), etc.
Tordez le problème et mettez d'autres conditions sur la liste chaînée, et vous aurez une bonne question à poser. Certaines personnes feront alors des erreurs.
Dans mes 10 ans de programmation professionnelle jusqu'à présent (et environ 10 ans de plus comme passe-temps), je ne pense pas avoir jamais eu besoin de mettre en œuvre une liste chaînée. Si quelqu'un m'a demandé de le faire lors d'une entrevue, je pourrais contrer en demandant si c'est quelque chose que je ferai régulièrement au travail.
Bien sûr, il existe presque certainement des emplois où vous devrez écrire des implémentations plus ou moins propres en salle propre d'algorithmes communément connus - comme implémenter un liste liée à partir de zéro. Mais pour la plupart des emplois de programmation, quelle valeur spécifique at-il pour l'entreprise qu'un candidat puisse le faire lors d'un entretien? Est-ce vraiment si important dans un tel contexte que le candidat fournit une implémentation parfaite qui gère correctement les cas Edge, signale les échecs conformément à la pratique courante dans le langage ou le framework, etc.? Ou pouvez-vous ignorer cela et vous concentrer sur la façon dont ils abordent réellement un problème auquel ils n'ont peut-être pas été confrontés depuis 10 à 20 ans?
Lorsque j'ai interviewé pour mon emploi actuel, j'avais très peu d'expérience avec la pile technologique utilisée dans l'entreprise. Maintenant, quelques années plus tard, j'ai régulièrement des collègues qui viennent me poser des questions non seulement sur les produits, leur mise en œuvre et les normes mises en œuvre par eux, mais aussi sur des problèmes de programmation beaucoup plus généraux (hier, on m'a demandé ce que les implications étaient d'une dépendance circulaire dans une contrainte par défaut dans SQL Server dans le contexte d'une table particulière et de son utilisation dans notre cas - en raisonnant à travers elle, il s'est avéré qu'il n'y avait aucune implication dans ce cas particulier). Je n'avais pas non plus besoin d'une nouvelle implémentation de liste chaînée.
Posez des questions pertinentes pour le travail que le candidat est susceptible d'être assigné, et essayez d'avoir une idée de ce qu'ils pensent de l'acquisition de nouvelles connaissances. Comment pourraient-ils trouver le sens d'une syntaxe obscure qu'ils n'ont jamais vue? (Si vous êtes un magasin C, par exemple, alors vous pourriez essayer une question impliquant des trigraphes.) Pour un poste de programmation, lisent-ils régulièrement ou contribuent-ils à des forums tels que Stack Overflow? Si on leur a demandé d'effectuer une tâche dans un langage ou un framework de programmation avec lequel ils ont peu ou pas d'expérience (par exemple, si vous êtes principalement une boutique Java, qu'en est-il de Clojure ou .NET?), alors comment pourraient-ils aborder le problème? Peut-être retirer un vrai bug de votre outil de suivi des bogues (peut-être même un qui a depuis longtemps été résolu) et leur demander comment, en termes généraux, ils aborderaient le problème et seraient prêts à expliquer les parties pertinentes le produit en question.
Si le candidat peut gérer des types de problèmes pertinents à l'analyse de rentabilisation et a une bonne attitude envers l'apprentissage de nouvelles choses, c'est probablement un bien meilleur indicateur de l'adéquation pour ce poste particulier que d'être en mesure de fournir des réponses standardisées à des questions bien connues, qu'il s'agisse de FizzBuzz, de listes chaînées ou d'autre chose. Ajoutez à cela l'adéquation du candidat avec l'équipe et je pense que vous êtes sur un terrain assez sûr.
Bien sûr, la plupart des gens n'auraient jamais besoin d'implémenter une liste chaînée, mais pour les implémenter à partir de zéro, il faudra probablement gérer correctement les pointeurs. Leur idée est alors qu'avoir formé un modèle mental cohérent pour les pointeurs est en corrélation avec la maîtrise du langage, comprendre ce qui se passe à un certain niveau (abstrait) de la machine et la capacité d'abstraire en général.
Je ne dis pas que ce serait nécessairement la meilleure mesure, mais seulement qu'il existe une certaine corrélation.
Vous commencez par dire que ce sont des "questions", mais ensuite vous faites remarquer que les gens ne pourront naturellement pas les poser. Je suis confus.
Voici comment j'y pense:
- Il est rarement nécessaire d'en écrire un, comme vous le dites, donc les gens l'oublieront facilement.
- Ils ne sont pas incroyablement difficiles à écrire.
- Les concepts utilisés pour les écrire peuvent être considérés comme fondamentaux.
- Ils sont incroyablement utilisés (même si vous ne le savez pas).
Je pense que cela les rend bonnes questions à poser. Si vous êtes inquiet à leur sujet avant de préparer l'entretien, jetez une liste. Demandez-leur de l'écrire circulaire et de demander quel est le temps d'exécution asymptotique de leur mise en œuvre. Ou demandez-leur d'écrire une autre structure de données commune et/ou rapide ... Un arbre de recherche binaire? Une file d'attente (FIFO)? Une pile (FILO)? Une file d'attente naïve (O(n)) prioritaire? Beaucoup de gens que je connais pensent qu'un BST est O(log n)juste parce que c'est un arbre.
Si vous cherchez quelqu'un qui travaillera dans le métal et a besoin d'une très fondation solide dans les structures de données ... cela peut même être loin trop trivial pour le les candidats que vous cherchez à embaucher.
Cela suppose, bien sûr, que vous souhaitez qu'un développeur qui possède les bases/principes fondamentaux des structures de données et que sa position bénéficie de ces principes fondamentaux. Si vous voulez quelqu'un qui peut créer une page asp en quelques secondes, interviewez-le. Il ne s'agit pas de choisir une question d'entrevue parce que tout le monde le fait, mais d'en choisir une qui mesure les compétences que vous recherchez. Personnellement, je pense que les questions sur les structures de données sont bonnes, liste liée ou non.
Cette question a-t-elle suffisamment d'utilité pour être utilisée couramment pour évaluer les candidats à la programmation à tous les niveaux?
Non, absolument pas. Selon sa formulation, ce qu'il vous dira va de "ce candidat sait comment concevoir une liste chaînée" à "ce candidat peut programmer une liste chaînée dans la langue X". Si vous demandez un pseudocode, il tendra davantage vers le premier. Si vous demandez une implémentation dans un langage particulier, vous obtiendrez plus dans leur compréhension du langage (en particulier avec C et C++, où vous pouvez traiter des pointeurs et des références et des structures).
J'irais même jusqu'à dire qu'il n'est pas possible d'évaluer tous les candidats en utilisant les mêmes questions. Vous devez adapter vos questions d'entrevue pour évaluer les compétences que vous recherchez dans le poste.
Si la personne va être en mesure d'écrire du code, je penserais à inclure un algorithme et/ou une question de structure de données, à condition que cela soit pertinent pour le poste. J'essaierais de choisir quelque chose qui aurait pu être discuté ou utilisé auparavant. Je me concentrerais également sur d'autres choses que la simple implémentation desdits algorithmes et structures de données, tels que le temps d'exécution et la consommation de mémoire (des choses comme la notation big-O). Ces concepts sont pertinents non seulement pour créer la structure de données, mais aussi pour choisir l'implémentation la mieux adaptée (comme un ArrayList par rapport à un LinkedList par exemple).
Je ne pense pas que pour un travail de programmation régulier devrait être une question qui élimine un candidat. Mais c'est un bon moyen de voir si vous avez affaire à un programmeur vraiment senior ou à quelqu'un qui vient de coder des formulaires depuis de nombreuses années. Et même ainsi, cela ne devrait pas être un critère fondamental pour choisir un programmeur. Peut-être est un grand programmeur avec une mauvaise mémoire et n'a pas lu les mots "liste liée" sur des années (ou ne se souvient pas du nom) mais peut toujours faire de bonnes applications.
Donc, comme certains l'ont dit, si cela va être un travail qui doit fonctionner avec une liste chaînée et beaucoup d'algorithmes sophistiqués, etc. alors ok. Est-ce que si pour les données d'entrée habituelles sur un formulaire, valider et afficher est un peu inutile et injuste.
Je pense que c'est un mauvais exemple d'une question d'entrevue, mais pour une raison différente. Une liste chaînée est un concept si simple que savoir ce que c'est, c'est savoir comment l'implémenter. Si la personne ne sait pas ce qu'est une liste chaînée, alors vous devez expliquer comment cela fonctionne, et ce faisant, vous donnez la réponse sans rien découvrir sur si oui ou non ils savent comment résoudre les problèmes =. La question est donc réductible à "savez-vous déjà ce qu'est une liste chaînée et comment elle fonctionne?", Ce qui ne vous dit rien d'utile sur leur aptitude en tant que programmeur.
Écrire une implémentation de liste chaînée est une bonne question d'entrevue, car elle en révélera beaucoup sur la façon de coder du candidat:
Sait-il ce qu'est une API? Peut-il utiliser le code d'autrui? Peut-il écrire du code pour que d'autres personnes puissent l'utiliser?
Sait-il ce qu'est une liste liée? Connaît-il les collections, les structures de données, les algorithmes?
S'il ne sait même pas quelles méthodes une liste liée devrait offrir, vous savez qu'il n'en a probablement jamais utilisé ou sait quand en utiliser une.
Comment gère-t-il le problème? Commence-t-il par une analyse d'abord, une petite spécification, quelques tests au préalable? Ou commence-t-il simplement à pirater joyeusement?
Gère-t-il les cas Edge? Qu'en est-il de la suppression du dernier nœud de la liste liée? Que se passe-t-il si quelqu'un essaie d'ajouter une référence à la liste liée elle-même à la liste liée, puis supprime le tout?
Gère-t-il les exceptions? Chaque langage de programmation a ses propres conventions pour gérer les exceptions: en Java, vous vous attendez à ce qu'un LinkedList lève une NoSuchElementException lorsque vous effectuez un getFirst () sur une liste vide. D'autres langues peuvent renvoyer undefined, -1 ou une constante.