Des puzzles logiques délicats - Sont-ils vraiment utiles pour évaluer les compétences en programmation? [fermé]

Lors de la dernière entrevue à laquelle j'ai participé, on m'a demandé de résoudre un casse-tête dans lequel je devais mesurer exactement des litres blah d'eau avec deux seaux d'une capacité respective: bla et blah litres. Je suis incapable de résoudre le casse-tête dans le temps imparti (~ 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 de quelles compétences il parlait.

Je me suis toujours senti étrange à propos de ce genre de casse-tête qui est normalement posé lors des entretiens d'embauche. Je ne comprends pas quel est, le cas échéant, le lien entre ces énigmes et la programmation. Quelles compétences les enquêteurs ont-ils l'intention d'évaluer avec de tels casse-tête?

Certaines personnes leur demandent d'essayer d'évaluer leurs capacités et leur approche de la résolution de problèmes. Personnellement, je ne pense pas que de tels casse-tête fournissent un indicateur précis. Dans le "monde réel", par exemple, vous avez plus de cinq minutes pour déterminer si vous avez affaire à un panier d' emballage ou à un sac à dos . Au début, il est parfois facile de mal comprendre le problème 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 «casse-tête» sont ceux dans lesquels vous vous asseyez devant un ordinateur pour résoudre un problème du domaine dans lequel vous revendiquez une expertise. Je n'aime pas non plus le "Bien, un programmeur devrait pouvoir ..." penser, car il ne tient pas compte du fait que les gens deviennent anxieux quand ils sont frappés par quelque chose d'inattendu dans un contexte déjà stressant. Bien sûr, vous pourriez résoudre ce problème si vous aviez le temps d’y réfléchir… et peut-être pourriez-vous le résoudre plus rapidement si vous réalisiez que votre vie serait finie si vous ne le faisiez pas. Voulez-vous travailler quelque part où votre vie sera finie si vous ne pouvez pas résoudre les problèmes en cinq minutes ? Voulez-vous être viré si vous ne pouvez pas ?

Tous les grands programmeurs devraient-ils aussi être des champions du sudoku? Je suis sûr que beaucoup le sont, mais ce n'est pas une sorte de condition préalable à la compétence.

Je ne dis pas que vous ne devriez 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 que le personnage décrit par Bruce Willis semble plutôt inutile, étant donné que les producteurs ont dépensé une belle somme pour que la scène soit parfaite.

En d'autres termes, si vous constatez que vous êtes interrogé par une personne qui comprend mal ce que vous allez réellement faire , excusez-vous d'aller aux toilettes et de ne jamais y revenir.

Microsoft a commencé à utiliser ces questions au début des années 1980. Alors que Microsoft connaissait un succès remarquable, d'autres sociétés ont commencé à les copier, mais quelques points clés ont été perdus dans la traduction.

À l’époque, Microsoft tentait de pourvoir à de nombreux postes techniques mais non liés à la programmation: rédacteurs techniques, testeurs, assistance téléphonique, etc. trouver. Au lieu de cela, Microsoft pensait pouvoir embaucher des personnes très intelligentes, intelligentes et flexibles et les former au travail. Étant donné que ces personnes n'avaient pas de formation en programmation, leur poser des questions sur la programmation au cours de l'interview était inutile. Les énigmes ont été choisies pour tenter de repérer des personnes intelligentes et dotées de compétences analytiques exceptionnelles. Les programmeurs étaient généralement confrontés à des problèmes de programmation au tableau blanc, mais ils pouvaient aussi poser des énigmes au déjeuner ou au dîner.

Ces questions n'ont jamais été faites pour être un échec. Ils étaient censés être le point de départ d'une discussion sur la manière dont vous aborderiez le problème et sur la façon dont vous penseriez à des problèmes que vous n'aviez jamais vus auparavant. Le seul moyen sûr d’échouer était de refuser de tenter de résoudre le problème. À l'époque, cette stratégie était nouvelle et vous ne pouviez pas simplement consulter les questions sur Google.

Modifier:

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 à poser des casse-têtes et des devinettes à des candidats à des emplois dans le domaine de la programmation remonte aux années cinquante. Les États-Unis essayaient d'informatiser leur système de défense aérienne et IBM estimait qu'ils auraient besoin de plusieurs milliers de programmeurs pour effectuer le travail. La réponse a été un choc et une consternation: il n'y avait que quelques dizaines de "programmeurs professionnels" dans le monde entier. Plusieurs approches ont été testées: tests d'aptitudes en programmation abstraite, recrutement de mathématiciens en tant que programmeurs, recrutement de joueurs d'échecs et de résolveurs de mots croisés, et sélection de candidats avec des énigmes et des énigmes.

Ils ont finalement réussi à recruter suffisamment de programmeurs pour mener à bien le projet, mais la conclusion en est qu’aucune des méthodes de filtrage n’était meilleure que la chance d’identifier les recrues qui ont connu un succès remarquable en tant que programmeurs.

Sont-ils utiles? Non, pas vraiment. Celles-ci étaient autrefois si courantes chez Microsoft qu’elles s’appelaient même "questions Microsoft", et il y a eu des livres écrits à leur sujet, celui-ci est en fait une très bonne lecture ..

Il y a 2 problèmes avec eux. Premièrement, si le candidat effectue 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, en quoi cela montre-t-il qu'il s'agira d'un bon développement / test / MP.

Pour ces raisons, on ne leur demande presque plus rien chez Microsoft. Il est de loin 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 "astuce". En d’autres termes, vous devez poser des questions qui vous permettent d’explorer les compétences et le comportement du demandeur face au problème. En tant qu’interviewer, je souhaite qu’il pose des questions, propose des solutions et revienne en arrière dès qu’il découvre un problème, peut-être même pas trouver une solution dans le temps dont ils disposent mais au moins y remédier de façon sensée. Cela reflète le travail de la vie réelle. Je n'ai jamais eu à mesurer 3 chopines avec 2 seaux et un poulet (ou quelle que soit la question).

Cela dit, on m'a posé quelques questions astucieuses à mon époque et je me considère maintenant comme un expert du transport de poules et de renards dans de petites embarcations et du calcul de la durée de vie d'une mouche qui vit dans un train. Je n'ai jamais eu à utiliser cette information, mais qui sait, peut-être un jour ...

Vous voudrez peut-être lire le livre Comment déplaceriez-vous le mont Fuji? . Cela explique le raisonnement selon lequel beaucoup de gens utilisent des énigmes lors d’interviews, et j’estime que c’est une combinaison de culte du fret ( "Microsoft le fait, et si nous voulons avoir le même succès, alors nous ferions mieux de faire ce qu’ils faire " ) et bizutage fraternité ( " par gosh !, je devais répondre à ces questions et vous feriez mieux de croire que le prochain gars va devoir y répondre! " ).

L’histoire de ces questions en tant qu’interview a commencé avec William Shockley dans les années 1950. C’était une sorte de question d’entrevue assez courante dans la Silicon Valley, que les intervieweurs ont posée parce que d’autres intervieweurs le faisaient (et qu’ils savaient peut-être quelque chose que cet intervieweur ne savait pas?). Shockley avait l'intention de les utiliser comme test d'intelligence et la question des deux seaux concernait l'un des tests initiaux de Stanford Binet IQ en 1916.

Il est fort possible que les personnes qui interrogent souhaitent savoir comment vous cherchez des réponses. Elles poseront donc des questions impossibles à calculer, telles que le nombre de pompes à essence dans votre ville. Ces sortes de problèmes sont des problèmes de Fermi . Deux articles de blog intéressants de Jeff sur ce sujet sont The Hardest Interview Question et Jamais, et vous êtes un bon estimateur? Partie III .

Personnellement, j’ai une faible opinion de ce type de questions, car elles sont généralement utilisées par des intervieweurs qui ne savent pas ce qu’ils font, ni comment chercher des développeurs. À moins que vous ne travailliez pour une entreprise qui fabrique des énigmes / énigmes, elles appartiennent au passé de l’histoire avec "quelle est votre plus grande faiblesse" (répondez à la vérité et finissez votre entrevue de façon décevante) ou "pourquoi les plaques d’égout sont rondes "(elles ne le sont pas toutes).

D' autres ont fourni des réponses de que j'upvoted comme une question de nécessité . La raison pour laquelle j’écris une autre réponse, c’est que ce que je veux dire ne correspondra probablement pas à un commentaire et qu’il faut dire quelque chose sur la qualité d’une entrevue d’emploi dans le domaine de la programmation.

Dans le premier bon entretien, je me souviens, nous avons beaucoup discuté sans hâte. Tout d'abord, pendant une heure, au téléphone, à propos de la conception orientée objet et des avantages et inconvénients de son implémentation en C ++. Ensuite, sur site, j'ai parlé à plusieurs personnes de leurs pratiques de développement logiciel, de l'intégration, des tests, du contrôle de version et de la gestion de la configuration, des équipes et des responsabilités, de la technologie et de la conception. C'était une interview d'une journée entière qui comprenait un déjeuner avec les personnes qui m'interviewaient. Avec le recul, tout était question de savoir si je pouvais m'intégrer de manière productive dans ce qu'ils faisaient déjà.

Depuis lors, 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, aucune énigme et aucun défi de codage.

Si je devais interviewer quelqu'un pour un travail de programmation aujourd'hui, je procéderais de la sorte. Je demanderais des opinions sur un large éventail de sujets et laisserais de côté la profondeur:

1. Quelles sont vos préférences de langage de programmation? Pourquoi?
2. Comment aborder la gestion des exceptions?
3. Les avantages de la conception en couches ne sont-ils pas un mythe?
4. L'intégration continue n'est-elle pas un fardeau pour l'efficacité?
5. Celui qui a écrit un morceau de code devrait en être le propriétaire, pas vrai?
6. Que faites-vous pour entrer dans "flux".
7. Comment les défauts signalés doivent-ils être inclus dans un plan de projet?
8. ...

Ce sont des questions avec plus d'une réponse, et elles traitent toutes de sujets sur lesquels un développeur de logiciel devrait avoir une opinion éclairée. Je suis entièrement d'accord avec les réponses qui mentionnent de vrais problèmes antérieurs rencontrés en tant que sujet de conversation (et non en tant que questions).

Les études les plus scientifiques sur le développement de logiciels efficaces depuis Peopleware indiquent que les meilleurs programmeurs sont ceux qui comprennent la dynamique du développement de logiciels, même s'ils n'ont pas les QI les plus élevés. Je préfère prendre une recrue qui est désireuse d'apprendre que quelqu'un avec des nannées d'expérience qui se résume à une 1année d'expérience à plusieurs nreprises. Mon point de vue personnel est envers les candidats qui ont tendance à sortir des sentiers battus et qui savent en même temps s’intégrer à la (ma) boîte actuelle.

Ils peuvent être utiles pour évaluer les compétences en résolution de problèmes , ce qui est bien sûr l’un des aspects clés de la programmation.

En tant qu’interviewer de nombreuses personnes au fil des ans, je ne pose généralement pas de questions de type gotcha comme celle que vous semblez décrire, mais je peux très bien poser une question et demander «comment voulez-vous résoudre ...».

Mes attentes dans ce cas sont de vous entendre exprimer votre approche du problème. Quelles autres données tenteriez-vous de collecter? Comment vérifieriez-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 elles sont censées le faire. Ils savent que ne pas répondre à la question est "mauvaise" et que la réponse est "bonne", 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 du fait que l'intervieweur n'est pas un intervieweur compétent.

C’est la raison pour laquelle vous devez posséder des compétences de base en logique. tout peut être enseigné. Mais ce n'est pas tout à fait vrai. Lire la logique booléenne , les conditions et les boucles n'est pas la même chose que de pouvoir résoudre un casse-tête logique .

Cela dit, à l'époque des langages procéduraux, il était probablement vrai que quelqu'un qui pourrait résoudre ces problèmes aurait davantage tendance à être capable d'appliquer n'importe quel problème en termes de commutation. Mais, à mon sens, la programmation OO / fonctionnelle nécessite un état d’ingénierie très différent (bien que non contradictoire).

Personnellement, je ne suis pas sûr de vouloir occuper un poste dans une entreprise qui pense toujours que la logique est plus importante que les compétences pratiques en programmation.

Disclaimer: Je suis très bon dans les casse-tête logiques et je n'aurais probablement pas commencé dans cette branche sans ce rationalle.

L'intervieweur doit faire référence à la résolution de problèmes et à la logique, ce qui fait partie du travail quotidien d'un programmeur. Quand un problème vous est posé, vous devez être capable de l’analyser, de le subdiviser et d’écrire une solution en utilisant l’approche la plus optimale.

Vous pourriez dire à quel point un casse-tête comme celui-ci représente votre capacité à le faire. Je ne vois pas l'intérêt de poser une question d'énigme au lieu de poser un problème de programmation réel.

La programmation ne consiste pas à écrire des lignes de code, mais à résoudre des problèmes pour et par 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 de disposer de capacités de résolution de problèmes et de la tester.

Cela étant dit, je ne suis pas sûr que résoudre un casse-tête compliqué soit le meilleur moyen d'évaluer quelqu'un.

Les énigmes dans les entretiens appartiennent à deux catégories: les "énigmes logiques" (comme celle qui vous a été posée) et la catégorie "pensez différemment". La catégorie Pensez différemment (je ne suis pas sûre qu'ils soient aussi appelés 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?

Les "puzzles logiques" me conviennent, car ils ont une ou deux solutions au plus et peuvent être obtenus facilement. Et je crois que les énigmes logiques sont bonnes dans une certaine mesure car le processus nécessaire pour les résoudre est de la manière dont un codeur doit penser dans la vie réelle.

Le type "penser différemment" ne me blesse pas parce qu’il vous oblige à faire des hypothèses, puis à faire des calculs en fonction de ces hypothèses. Autrement dit, si votre interlocuteur accepte votre logique mais pas vos hypothèses, ou inversement, vous avez perdu. L'intervieweur a trop de place pour ne pas être d'accord avec votre solution.

Quand je prends des interviews, je ne pose pas de problèmes logiques. Raison: la plupart des candidats, même ceux ayant de 3 à 4 ans d’expérience, échouent ou abandonnent lorsque je leur demande de coder de simples problèmes manuels, tels que la série de Fibonacci ou les palindromes.

Le problème avec les énigmes, de toute façon, est que les moins bons programmeurs savent que, rien qu'en cherchant des solutions à des énigmes aussi courantes 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.

Deux points:

1. La programmation est principalement différente de la résolution de casse-tête. Steve McConnell l'a parfaitement expliqué dans "Code Complete":

   Quelle? Vous n'êtes pas obligé d'être superintelligent? Non, tu ne le fais pas. Personne n'est assez intelligent pour programmer des ordinateurs. Pour bien comprendre un programme moyen, il faut une capacité presque illimitée d’absorber les détails et une capacité égale de tout comprendre en même temps. La façon dont vous concentrez votre intelligence est plus importante que votre intelligence. Comme indiqué au chapitre 5, Edsger Dijkstra, lors de la conférence sur le prix Turing de 1972, publia un article intitulé «The Humble Programmer» (programmateur humble). Il expliqua que l'essentiel de la programmation visait à compenser la taille strictement limitée de nos crânes. Les personnes les plus qualifiées en matière de programmation sont celles qui réalisent à quel point leur cerveau est petit. Ils sont humbles. Les personnes qui sont les pires à la programmation sont celles qui refusent d’accepter le fait que leur cerveau n’est pas à la hauteur de la tâche. Leur ego les empêche d’être de grands programmeurs. Plus vousapprenez à compenser votre petit cerveau, meilleur sera votre programmeur . Plus vous êtes humble, plus vite vous vous améliorerez.

2. De tels casse-tête 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 énigmes devraient être plus compliquées et liées à la programmation (comme un petit projet de 2 heures), à mon avis. Le fait est que les intervieweurs sont des personnes et qu’ils n’ont pas les «compétences d’interview» nécessaires.

Il existe différentes manières d’examiner de tels problèmes:

1. Connaître une solution précédente. Dans le film ... Mourir avec une vengeance ... expliquez-moi cela? être un exemple de savoir une solution pour le cas où les blahs sont 4,3 et 5 respectivement. Certaines personnes pourront rapidement exploiter leur connaissance interne d'une solution antérieure et l'adapter si nécessaire. C’est généralement ce à quoi un enquêteur s’attendrait, ce qui peut être une bonne idée ou non.

2. Compétences d'improvisation créative. Ce serait le cas si vous ne connaissiez pas une solution précédente ou si vous ne reconnaissiez même pas le problème comme étant quelque chose que l'on pourrait modéliser comme une équation de Diophantine. La question est donc 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 valide au problème.

L’un ou l’autre pourrait être ce qui permet de résoudre la question de manière satisfaisante, bien que dans chaque cas, il existe également un test de compétences en communication, car on peut également essayer de répondre: "Est-ce vraiment pertinent par rapport à la situation Quand ces compétences ont-elles été utilisées pour la dernière fois? " cela peut donner lieu à un dialogue intéressant si l'intervieweur s'exprimait sur ce qu'il souhaitait voir exactement, à savoir 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. Seules trois étapes sont nécessaires et il n'y a que deux choix à chaque étape. Je serais surpris si l'un de mes collègues était incapable de le résoudre 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 à un travail. Surtout un travail de CS puisque 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.

Les degrés, les recommandations et les GPA peuvent être obtenus avec du temps / des efforts et de l'ingénierie sociale, l'expérience de travail peut être enrichie et / ou fausse, et les tests standardisés sont trop fondamentaux pour être trop indicatifs de vos capacités. Ainsi, le curriculum vitae peut donner une idée des niveaux d’effort / d’engagement dans votre histoire, mais rien de tout cela n’affectera votre capacité réelle à résoudre des problèmes difficiles qui se posent dans le monde de l’informatique. Je ne peux pas penser à un meilleur moyen de prédire ce genre de capacité que quelques bons puzzles de logique / mathématique / CSy.

N'oubliez pas que c'est un jeu de devinettes et que, dans les faits, toutes choses égales par ailleurs, nous préférerions embaucher quelqu'un capable de résoudre ces énigmes plutôt que de ne pas le faire.

Oui, vous pouvez étudier les énigmes des entretiens, mais je pense que vous vous retrouverez brûlés si les énigmes proposées ne correspondent pas à celles que vous étudiez ... et tant que vous ne mémorisez pas les énigmes et leurs solutions, peut-être en étudiez-vous. eux-mêmes feront de vous une personne plus intelligente d'une manière réelle, comme toute véritable éducation devrait.