Puzzles de logique délicate - Sont-ils vraiment utiles pour évaluer les compétences en programmation?
Lors de la dernière entrevue à laquelle j'ai assisté, on m'a demandé de résoudre un casse-tête dans lequel je devais mesurer exactement bla litres d'eau compte tenu de deux seaux avec des capacités - bla et bla litres respectivement. Je n'ai pas pu résoudre le puzzle en un temps donné (~ 5 minutes).
L'intervieweur était un peu déçu et a déclaré qu'un programmeur devait avoir "ces" compétences. Je n'ai pas compris les compétences dont il parlait.
Je me suis toujours senti étrange à propos de ce genre d'énigmes qui sont normalement posées lors de la programmation des entretiens d'embauche. Je ne comprends pas quel est, le cas échéant, le lien entre ces puzzles et la programmation. Quelles sont exactement les compétences que les enquêteurs ont l'intention d'évaluer avec de telles énigmes?
Certaines personnes leur demandent dans le but d'évaluer votre capacité et votre approche pour résoudre les problèmes. Personnellement, je ne pense pas que ces puzzles fournissent un indicateur précis. Dans le "monde réel", vous avez plus de cinq minutes pour déterminer si votre problème avec un emballage bin vs un sac à dos , par exemple. Au départ, il est parfois facile de mal comprendre le problème actuel jusqu'à ce que vous soyez en train d'appliquer la mauvaise solution. Cela arrive aux personnes ayant 1, 5, 10 ou même 20 ans d'expérience.
Les meilleurs puzzles d'entrevue sont ceux où vous vous asseyez devant un ordinateur pour résoudre un problème dans le domaine dans lequel vous revendiquez une expertise. Je n'aime pas non plus la pensée "Eh bien, un programmeur devrait pouvoir ..." car il ne tient pas compte du fait que les gens s'inquiètent lorsqu'ils sont touchés avec quelque chose d'inattendu dans un cadre déjà stressant. Bien sûr, vous pourriez résoudre cela si vous aviez le temps d'y penser .. et peut-être pourriez-vous le résoudre plus rapidement si vous réalisiez que votre vie serait finie si vous ne l'avez pas fait. Voulez-vous travailler quelque part où votre vie sera terminée si vous ne pouvez pas résoudre les problèmes en cinq minutes ? Serez-vous renvoyé si vous ne pouvez pas ?
Tous les grands programmeurs devraient-ils également être des champions du sudoku? Je suis sûr qu'il y en a beaucoup, mais ce n'est pas comme une sorte de condition préalable à la compétence.
Je ne dis pas que vous ne devriez pas pas être testé sur la façon dont vous abordez les problèmes, mais les tests devraient être amusants et inviter le "meilleur" que le demandeur doit donner, compte tenu de leur domaine d'expertise. Prouver que vous êtes aussi intelligent qu'un personnage que Bruce Willis dépeint semble un peu inutile, étant donné que les producteurs ont dépensé une jolie somme pour obtenir cette scène juste juste.
En d'autres termes, si vous détectez que vous êtes interviewé par quelqu'un qui a peu de compréhension de ce que vous allez réellement faire , excusez-vous d'aller aux toilettes et ne revenez jamais.
Microsoft a commencé à utiliser ces questions au début des années 80. Comme Microsoft a connu un succès notable, d'autres entreprises ont commencé à les copier, mais quelques points clés ont été perdus dans la traduction.
À l'époque, Microsoft essayait de combler de nombreux postes techniques mais non liés à la programmation: rédacteurs techniques, testeurs, assistance téléphonique, etc. Ce n'étaient pas des emplois courants à l'époque, et les gens ayant une expérience réelle dans ces domaines étaient difficiles à trouver. Comme alternative, Microsoft pensait pouvoir embaucher des personnes vraiment intelligentes, intelligentes et flexibles et les former à l'emploi. Étant donné que ces gens n'avaient pas de formation en programmation, leur poser des questions de programmation dans l'interview était inutile. Les énigmes ont été choisies pour essayer de trouver des gens intelligents et dotés de compétences analytiques exceptionnelles. Les programmeurs ont généralement été confrontés à des problèmes de programmation de tableau blanc, bien qu'on puisse également leur demander des énigmes au déjeuner ou au dîner.
Ces questions n'ont jamais été conçues pour échouer. Ils étaient censés être le début d'une conversation sur la façon dont vous aborderiez le problème, et comment vous pensiez à des problèmes que vous n'aviez jamais vus auparavant. Le seul moyen sûr d’échouer était de refuser d’essayer de résoudre le problème. À l'époque, c'était une nouvelle stratégie, et vous ne pouviez pas simplement rechercher les questions sur Google.
Éditer:
Quelque temps après avoir écrit cette réponse, j'ai lu The Computer Boys Take Over , une histoire de l'informatique institutionnelle dans les années 1950 et 1960. Apparemment, la pratique consistant à demander des énigmes et des énigmes aux candidats à des emplois de programmation remonte aux années 1950. Les États-Unis tentaient d'informatiser leur système de défense aérienne et IBM a estimé qu'ils auraient besoin de plusieurs milliers de programmeurs pour faire le travail. La réponse fut choc et consternation: il n'y avait que quelques dizaines de "programmeurs professionnels" dans le monde entier. Plusieurs approches ont été essayées: tests d'aptitudes en programmation abstraite, recrutement de mathématiciens comme programmeurs, recrutement de joueurs d'échecs et de résolution de mots croisés, et sélection des candidats avec des énigmes et des énigmes.
Ils ont finalement réussi à recruter suffisamment de programmeurs pour achever le projet, mais la conclusion était qu'aucune des méthodes de sélection n'était meilleure que la chance d'identifier les recrues qui ont connu un succès notable en tant que programmeurs.
Sont-ils utiles? Non, pas vraiment. Ils étaient autrefois si courants chez Microsoft qu'ils ont même été appelés "questions Microsoft", et il y a eu des livres écrits à leur sujet, celui-ci est en fait une assez bonne lecture ..
Il y a 2 problèmes avec eux. Premièrement, si le demandeur fait des recherches (et lit le livre), il les connaîtra de toute façon et deuxièmement, même s'il peut les résoudre, comment cela montre-t-il que ce sera un bon dev/test/PM.
Pour ces raisons, ils sont rarement plus demandés chez Microsoft. Il est préférable de poser des questions de codage ou des questions de résolution de problèmes qui ne nécessitent pas de réponse "astucieuse". En d'autres termes, vous devez poser des questions qui vous permettent d'explorer les compétences et le comportement du demandeur pendant qu'il essaie de résoudre le problème - en tant qu'intervieweur, je veux qu'il pose des questions, trouve des solutions, puis revienne sur ses traces un problème, peut-être même ne pas trouver de solution dans le temps dont ils disposent, mais au moins y aller de manière sensée. Cela reflète le travail de la vie réelle. Je n'ai jamais eu à mesurer 3 pintes en utilisant 2 seaux et un poulet (ou quelle que soit la question).
Cela dit, on m'a posé quelques questions pièges de mon temps, et je me considère maintenant comme un expert dans le transport de poulets et de renards dans de petits bateaux et dans le calcul de la durée de vie d'une mouche qui vit dans un train. Je n'ai jamais eu à utiliser ces informations, mais qui sait, peut-être un jour ...
Vous voudrez peut-être lire le livre Comment déplaceriez-vous le mont Fuji? . Cela entre dans le raisonnement que beaucoup de gens utilisent des énigmes lors des entretiens, et mon opinion est que c'est une combinaison de comportements cultes du fret ( "Microsoft le fait, et si nous voulons réussir aussi bien que ils sont, alors nous ferions mieux de faire ce qu'ils font ") et le bizutage de fraternité (" par dieu!, je devais répondre à ces questions et vous feriez mieux de croire que le le prochain gars va devoir y répondre! ").
L'histoire de ces questions en tant que pratique d'entrevue a commencé avec William Shockley dans les années 1950. C'était une sorte de question d'interview de la Silicon Valley assez courante que les intervieweurs posaient parce que d'autres intervieweurs le faisaient (et peut-être qu'ils savaient quelque chose que cet intervieweur ne savait pas?). Shockley les envisageait comme un test d'intelligence, et la question avec les 2 seaux était sur l'un des originaux test de Stanford Binet IQ en 1916.
Il est très possible que les personnes interrogées souhaitent réellement voir comment vous recherchez des réponses, de sorte qu'elles poseront des questions impossibles à calculer, telles que le nombre de pompes à essence dans votre ville. Ces types de problèmes sont Problèmes de Fermi . Deux articles de blog intéressants de Jeff à ce sujet sont The Hardest Interview Puzzle Question Ever and How Good an Estimator are You? Part III .
Personnellement, j'ai une mauvaise opinion de ce genre de questions car elles sont généralement utilisées par des enquêteurs qui ne savent pas ce qu'ils font, ni comment rechercher des développeurs. À moins que vous ne travailliez pour une entreprise qui fabrique des puzzles/énigmes, ils appartiennent au crépuscule de l'histoire avec "quelle est votre plus grande faiblesse" (répondez à la vérité et vous terminez votre entrevue de mauvaise façon) ou "pourquoi sont des couvercles de trou d'homme ronds "(ils ne le sont pas tous).
D'autres ont fourni des réponses que j'ai votées positivement doivent . La raison pour laquelle j'écris une autre réponse est parce que ce que je veux dire ne rentrera probablement pas dans un commentaire, et parce que quelque chose doit être dit sur la façon dont une bonne entrevue d'emploi en programmation peut ressembler.
Dans la première bonne interview dont je me souviens, nous avons beaucoup parlé, sans hâte. Tout d'abord pendant une heure, au téléphone, sur la conception orientée objet et les avantages et inconvénients de sa mise en œuvre en C++. Ensuite, sur place, j'ai parlé avec plusieurs personnes de leurs pratiques de développement logiciel, d'intégration, de test, de contrôle de version et de gestion de configuration, d'équipes et de responsabilités, de technologie et de conception. C'était une interview d'une journée qui comprenait un déjeuner avec les gens qui m'ont interviewé. Avec le recul, il s'agissait de savoir si je pouvais m'intégrer de manière productive dans ce qu'ils faisaient déjà.
Depuis, les bonnes interviews ont toutes été longues, des conversations d'une à deux heures sur le développement de logiciels. Il n'y a eu aucune question de résolution de problème, aucun casse-tête et aucun défi de codage.
Si je devais interviewer quelqu'un pour un travail de programmation aujourd'hui, je procéderais comme ça. Je demanderais des opinions sur un large éventail de sujets et laisserais la profondeur de côté:
- Quelles sont vos préférences de langage de programmation? Pourquoi?
- Comment aborder la gestion des exceptions?
- Les avantages du design en couches ne sont-ils pas un mythe?
- L'intégration continue n'est-elle pas un fardeau pour l'efficacité?
- Celui qui a écrit un morceau de code devrait le posséder, non?
- Que faites-vous pour entrer dans le "flux"?.
- Comment les défauts signalés devraient-ils être inclus dans un plan de projet?
- ...
Ce sont des questions avec plus d'une réponse, et elles concernent toutes des sujets sur lesquels un développeur de logiciels devrait avoir une opinion éclairée. Je suis entièrement d'accord avec les réponses qui mentionnent des problèmes réels antérieurs vécus comme sujet de conversation (pas comme questions).
Les études les plus scientifiques sur le développement logiciel efficace depuis Peopleware disent que les meilleurs programmeurs sont ceux qui comprennent la dynamique du développement logiciel, même s'ils n'ont pas les QI les plus élevés. Je préfère prendre une recrue désireuse d'apprendre que quelqu'un avec n années d'expérience qui se résume à 1 année d'expérience répétée n fois. Mon parti pris personnel est envers les candidats qui ont tendance à sortir des sentiers battus et qui savent en même temps s'insérer dans la (ma) boîte actuelle.
Ils peuvent être utiles pour évaluer résolution de problèmes compétences, ce qui est bien sûr l'un des aspects clés de la programmation.
En tant qu'enquêteur de nombreuses personnes au fil des ans, je ne pose généralement pas gotcha des questions de type tout à fait comme celle que vous semblez décrire, mais je peux très bien poser quelque chose et demander "comment résoudriez-vous .. . ".
Dans ce cas, mes attentes sont de vous entendre articuler votre approche du problème. Quelles autres données essaieriez-vous de recueillir? Comment testeriez-vous vos hypothèses, etc.
Ce ne sont que des pratiques d'embauche vaudou. D'autres personnes posent ces questions afin de se sentir comme ils sont censés le faire. Ils savent que ne pas répondre à la question est "mauvais" et répondre est "bon", mais ils ne peuvent pas vous dire pourquoi au-delà des non-réponses comme "un développeur a besoin de ces compétences". Ils sont une perte de temps et un indicateur que l'intervieweur n'est pas un enquêteur compétent.
C'est le rationalle old-skool que vous devez avoir des compétences de base en logique; tout le reste peut être enseigné. Mais ce n'est pas tout à fait vrai. Lire logique booléenne, conditions et boucles, ce n'est pas la même chose que de pouvoir résoudre un puzzle logique.
Cela dit, à l'époque des langages procéduraux, il était probablement vrai que quelqu'un qui pourrait résoudre ces problèmes aurait une propension plus élevée à pouvoir appliquer n'importe quel problème en termes de commutateurs. Mais à mon avis, la programmation OO/fonctionnelle nécessite un état d'esprit d'ingénierie, ce qui est assez différent (mais pas contradictoire).
Personnellement, je ne suis pas sûr de vouloir un emploi dans une entreprise qui pensait toujours que la logique était plus importante que les compétences pratiques en programmation.
Clause de non-responsabilité: je suis très doué pour les casse-têtes logiques et je n'aurais probablement pas fait mes débuts dans ce domaine sans cette rationalité.
L'intervieweur doit avoir fait référence à la résolution de problèmes et aux compétences en logique, qui font partie du travail quotidien d'un programmeur. Lorsque vous rencontrez un problème, vous devez être en mesure de l'analyser, de le subdiviser et d'écrire une solution pour celui-ci en utilisant l'approche la plus optimale.
Vous pourriez discuter de la façon dont un puzzle comme celui-ci représente votre capacité à le faire. Je ne vois pas le mérite de poser une question de puzzle au lieu de simplement poser un problème de programmation réel.
La programmation ne consiste pas à écrire des lignes de code, il s'agit de résoudre des problèmes pour et à partir d'autres personnes (client, utilisateur, etc.).
Il arrive que pour les programmeurs la solution prenne la forme d'un programme.
C'est pourquoi il est important d'avoir des capacités de résolution de problèmes et pourquoi il est testé.
Cela étant dit, je ne suis pas sûr que résoudre des énigmes délicates soit la meilleure façon d'évaluer quelqu'un.
Deux points:
La programmation est principalement différente de la résolution d'énigmes. Il est parfaitement expliqué par Steve McConnell dans "Code Complete":
Quelle? Vous n'avez pas besoin d'être superintelligent? Non, non. Personne n'est vraiment assez intelligent pour programmer des ordinateurs. Pour bien comprendre un programme moyen, il faut une capacité presque illimitée à absorber les détails et une capacité égale à les comprendre tous en même temps. La façon dont vous concentrez votre intelligence est plus importante que la quantité d'intelligence dont vous disposez. Comme le chapitre 5 l'a mentionné, lors de la conférence du prix Turing de 1972, Edsger Dijkstra a présenté un article intitulé "The Humble Programmer". Il a soutenu que la plupart des programmes sont une tentative de compenser la taille strictement limitée de nos crânes. Les gens qui sont les meilleurs en programmation sont ceux qui réalisent à quel point leur cerveau est petit. Ils sont humbles. Les gens qui sont les pires en programmation sont ceux qui refusent d'accepter le fait que leur cerveau n'est pas à la hauteur de la tâche. Leurs ego les empêchent d'être de grands programmeurs. Plus vous apprenez à compenser votre petit cerveau, mieux vous serez un programmeur. Plus vous êtes humble, plus vite vous vous améliorerez.
De tels puzzles peuvent être utiles pendant l'entretien, mais seulement si l'intervieweur regarde le Processus, pas le résultat lui-même.
Mais idéalement, les puzzles devraient être plus compliqués et liés à la programmation (comme un petit projet de 2 heures), à mon avis. Le fait est que les enquêteurs sont des personnes et n'ont pas de "compétences d'entrevue" parfaites.
Les puzzles dans les interviews se divisent en deux catégories: les "puzzles logiques" (comme celui qui vous a été demandé) et la catégorie "penser différemment". La catégorie Penser différemment (je ne sais pas si elles sont aussi appelées puzzles latéraux?) Sont généralement de ce type: Combien de feuilles y a-t-il dans cet arbre? ou Combien de tailleurs sont présents dans votre ville?
Je suis d'accord avec les "puzzles logiques" car ils ont au plus une ou peut-être deux solutions et peuvent être obtenus par une logique simple. Et je crois que les énigmes logiques sont bonnes dans une certaine mesure parce que le processus nécessaire pour les résoudre est très bien la façon dont un codeur doit penser dans la vie réelle.
Le genre "penser différemment" me dérange sans fin car il vous oblige à faire des hypothèses, puis à faire des calculs sur la base des hypothèses. Autrement dit, si votre intervieweur est d'accord avec votre logique mais pas avec vos hypothèses, ou vice-versa, vous avez perdu. Il y a trop de place pour que l'intervieweur soit en désaccord avec votre solution.
Quand je prends des interviews, je ne pose pas d'énigmes logiques. Raison: la plupart des candidats, même ceux qui ont 3-4 ans d'expérience, échouent ou abandonnent quand je leur demande de coder des problèmes de manuels simples tels que les séries Fibonacci ou les palindromes.
Le problème avec les puzzles, dans les deux cas, est que les programmeurs pas si bons savent qu'en cherchant des solutions à de tels puzzles courants sur le net, ils peuvent impressionner les intervieweurs. Très peu de gens seront assez honnêtes pour dire qu'ils connaissent déjà la solution.
Il existe plusieurs façons d'examiner ces problèmes:
Connaître une solution précédente. Dans le film ... Die Hard with a Vengeance ... expliquez-moi cela ...? étant un exemple de savoir une solution pour le cas où les blahs sont 4,3 et 5 respectivement. Certaines personnes pourront rapidement exploiter leurs connaissances internes d'une solution passée et l'adapter si nécessaire. C'est généralement ce à quoi je pense qu'un enquêteur s'attendrait, ce qui peut ou non être une bonne idée.
Compétences d'improvisation créative. Ce serait le cas si vous ne connaissez pas une solution précédente ou même reconnaissez le problème comme étant quelque chose que l'on pourrait modéliser comme une équation diophantienne. Ainsi, la question est de savoir à quelle vitesse pouvez-vous utiliser ce qui est donné et trouver une solution au problème de manière créative tout en expliquant pourquoi ce que vous avez est une solution valable au problème.
Soit cela pourrait être ce qui permet de dépasser la question de manière satisfaisante, mais dans chaque cas, il y a aussi un test de compétences en communication, car on pourrait également essayer de répondre: "Est-ce vraiment pertinent pour le poste que je suis? Quand ces compétences ont-elles été utilisées pour la dernière fois? " cela peut conduire à un dialogue intéressant si l'intervieweur s'ouvrira sur ce qu'ils veulent exactement voir qu'une approche alternative pourrait peut-être être considérée comme plus efficace ici.
Ce n'est pas un problème particulièrement délicat. Trois étapes seulement sont nécessaires et il n'y a que deux choix à chaque étape. Je serais surpris si l'un de mes collègues n'était pas en mesure de le résoudre très rapidement. Nous ne présentons pas de tels problèmes dans les entretiens, mais je pense qu'il est raisonnable de poser de telles questions. Ils sont certainement plus utiles que des questions détaillées sur la syntaxe ou les bibliothèques.
OTOH, je pense que les problèmes de programmation sont plus utiles.
Vous devez vous rappeler qu'il n'y a aucun moyen de savoir avec une certitude absolue que quelqu'un sera bon dans un travail. Surtout un travail CS, car de nombreux défis que le travail pourrait avoir en magasin ne peuvent pas être prédits.
L'employeur potentiel doit donc deviner vos performances futures.
Des diplômes, des recommandations et des GPA peuvent être obtenus avec du temps/effort et de l'ingénierie sociale, l'expérience de travail peut être embellie et/ou fausse, et les tests standardisés sont franchement trop basiques pour être trop révélateurs de la capacité. Ainsi, le curriculum vitae peut donner une indication des niveaux d'effort/d'engagement dans votre histoire, mais rien de tout cela ne parlera de votre capacité réelle à résoudre des problèmes difficiles qui surviennent dans le monde de l'informatique. Je ne peux pas penser à une meilleure façon de prédire ce genre de capacité que quelques bons puzzles logiques/mathématiques/CSy.
Rappelez-vous que c'est un jeu de devinettes, et la réalité est que toutes choses égales, nous préférerions embaucher quelqu'un capable de résoudre ces énigmes plutôt que celui qui ne le peut pas.
Oui, vous pouvez étudier les puzzles d'entrevue, mais je pense que vous vous retrouverez brûlé si le puzzle donné ne correspond pas à ceux que vous étudiez ... et tant que vous ne mémorisez pas les puzzles et leurs solutions, peut-être en étudiant les puzzles eux-mêmes feront de vous une personne plus intelligente d'une manière réelle, comme toute véritable éducation devrait le faire.