J'ai eu une dispute récemment avec un collègue programmeur. Il interviewait pour un nouveau poste et on lui a posé cette question:

Donnez une séquence de nombres commençant par X et se terminant par Y mais avec un élément manquant pour que N soit YX-1, trouvez l'élément manquant dans O (N) ou mieux.

Maintenant, la réponse n'est pas pertinente ici (mais intéressante). Cela a commencé une discussion pour savoir si c'était même une bonne question à poser lors d'un entretien.

Un côté: les algorithmes font partie intégrante de la programmation et la capacité des candidats à répondre à cette question soutient que ce candidat sera un bon programmeur et sera capable de résoudre des problèmes plus importants et peut gérer la plupart des tâches de programmation qui sont finalement faciles à comprendre et à répondre.

Autre côté: L'écriture d'algorithmes à partir de zéro est rarement utilisée dans la programmation moderne et n'est donc pas pertinente dans la plus grande question de savoir si la personne sera un bon programmeur. Une personne a pu répondre à cette question avec succès mais ne peut toujours pas effectuer des tâches de programmation plus courantes.

Tes pensées? Bonne question d'entrevue ou non?

Je suis d'accord pour poser une question d'algorithme, mais je ne suis pas d'accord pour insister sur un niveau de qualité big-O spécifique.

Poser ce genre de question est intéressant de voir comment la personne aborde le problème et quels pièges elle considère dans sa tentative, mais à moins qu’elle n’écrive quelque chose de follement incorrect ou inefficace, les détails réels de ce qu’ils écrivent ne sont pas aussi révélateurs que le fait qu’ils passer à travers les étapes de résolution / conception de problèmes de manière cohérente.

Je pose une question similaire, mais les personnes avec qui j'ai eu le plus de chance après l'embauche sont les personnes qui ont donné des réponses erronées mais qui ont eu la bonne idée dans leur approche.

Je ne serais pas d'accord avec l'idée que la capacité d'écrire des algorithmes n'est pas pertinente dans la plus grande question de savoir si la personne sera un bon programmeur. Même s'il n'a jamais à l'utiliser (ce qui est douteux), cela montre toujours s'il a la flexibilité mentale requise pour trouver une solution logique à un problème plus compliqué qu'un simple ensemble d'exigences déjà rédigées et énoncées. en détail par le client.

Je ne voudrais certainement pas embaucher quelqu'un qui ne sait pas penser et analyser. C'est ce qui fait la différence entre un singe code et un programmeur informatique.

Je dois admettre ici que je fais partie de ceux qui aiment poser des questions d'algorithme lors des entretiens, mais je dois souligner que la réponse réelle à la question est absolument hors de propos. Peu m'importe que la personne interrogée connaisse la réponse ou non. Au lieu de cela, pour moi, cette question cible différents aspects, comme les suivants - par ordre d'importance:

Exigences

Ces questions sont délibérément sous-spécifiées. Dans votre exemple, aucun autre détail n'est donné sur la séquence. Si vous avez une personne interrogée qui vous demande si ces chiffres sont réellement triés, c'est un bon signe. Il a la mentalité correcte pour demander aux clients de plus amples détails, ce qui aidera à trouver une meilleure solution dans un délai plus court. Le candidat peut également jouer avec l'idée d'utiliser l'espace O (n) pour stocker un tableau de N nombres, mais il ne devrait pas le faire sans demander plus de détails sur X et Y. Disons que X et Y sont compris entre 1 et 1000 , alors bien sûr, allez-y et lancez une solution basée sur une baie. Mais si je vous dis que l'intervalle est de 1 et 1 milliard, alors le problème devient totalement différent. Permettez-moi de souligner à nouveau que je ne me soucie pas de la solution.

Techniques standard

Je ne veux pas engager un programmeur qui ne sait même pas ce que signifie O (n). C'est un must absolu si vous avez reçu une éducation décente dans ce domaine. Mais il est également important de ne pas simplement savoir ce que cela signifie, mais d'appliquer réellement ces connaissances. Dans votre exemple, je veux qu'un candidat se rende compte qu'il n'est pas autorisé à trier les données (sans poser d'autres questions ciblant l'option d'un tri par compartiment ou d'autres approches de tri O (n)) en raison du tri requis O (n log n) en général.

De même, d'autres questions d'algorithme ciblent des techniques standard comme la traversée d'arbre ou de graphe, ou la récursivité. Un candidat peut glisser à l'une de ces techniques, ce qui ne fait pas bonne impression. Dans de tels cas, cependant, j'aime creuser plus profondément pour savoir si le candidat a des antécédents CS. Bien sûr, cela dépend de la position cible, mais généralement un développeur qui ne connaît pas les complexités d'exécution, ni les structures de données typiques et leurs traversées, ne sera d'aucune aide.

État d'esprit de résolution de problèmes

Après avoir posé la question, vous surveillez attentivement le candidat. Comment réagit-il? Vous obtenez ici les meilleurs résultats de candidats qui ne savent absolument pas comment résoudre le problème dans un premier temps . À cet égard, la question vérifie ce qui pourrait se produire si une situation similaire se produisait plus tard sur le lieu de travail. Vous pouvez rencontrer un tel problème au cours de votre développement, et il est bon de savoir comment votre candidat gère ces problèmes, même s'il n'est pas en mesure de le résoudre tout seul.

Exemple: vous ne voulez pas que votre candidat passe en mode silencieux pendant la prochaine demi-heure! Vérifiez s'il peut trouver des questions intelligentes (voir Exigences), vérifiez s'il commence à penser hors de la boîte une fois qu'il se rend compte qu'il ne peut pas le faire. Même une contre-question "amusante" comme "Puis-je utiliser l'option téléphone-un collègue?" est un bon signe.

Comment répondre

En général, les meilleures réponses que vous pouvez donner pour ce genre de questions sont des contre-questions! Dire une réponse tout de suite échoue fondamentalement, et ce n'est en fait pas une bonne réponse du tout, car toutes ces questions suggèrent des compromis, ce que votre réponse implique, sans que vous ayez les informations requises pour le faire intelligemment troquer. Bien entendu, la qualité des contre-questions varie selon les candidats.

Remarque générale sur les questions d'entrevue: les contre-questions sont rarement une mauvaise chose. Dans une de mes propres interviews, on m'a par exemple demandé quelque chose comme ceci: "Si vous deviez implémenter X, choisiriez-vous C ++ ou Java pour cela, et pourquoi?" - J'ai simplement répliqué par "Suis-je limité à ces deux?". Devinez par vous-même, quel type de réaction vous obtenez d'un intervieweur pour une telle contre-question - et à quel point il est facile pour vous de montrer à l'enquêteur ce dont vous êtes capable.

À moins que vous ne posiez des questions sur les algorithmes / formules que le candidat doit connaître pour le travail (dynamique des fluides, par exemple, si le poste l'exige), je ne vois pas leur valeur. Le candidat s'inquiète probablement déjà de la façon dont il est habillé, de la façon dont il parle, etc.

Lorsque j'interviewe, je ne pose même pas de questions de programmation en soi. Je demande au candidat de décrire ses projets passés, comment son code a atteint ses objectifs, quelles sont ses approches, etc. Je peux dire assez rapidement si le candidat sait ce qu'il fait ou s'il est un poseur.

Je suis d'accord que les programmeurs doivent très bien connaître les algorithmes, même avec de nouveaux cadres fantaisistes, mais je ne suis pas totalement convaincu d'un casse-tête dans une interview. Ma plus grande préoccupation serait que dans un environnement réel, vous écrivez des algorithmes dans des conditions très différentes; aka, pas sous pression avec quelqu'un qui vous regarde à chaque touche, avec au moins plusieurs minutes pour réfléchir en silence. Pour ceux qui préconisent cette méthode d'évaluation, combien de temps donnez-vous généralement à la personne pour la résoudre? Je crois que le code ne consiste pas tellement à trouver une solution dans une terreur fébrile de 3 minutes, alors convainquez-moi que c'est en fait un bon moyen de voir comment quelqu'un va gérer une tâche quotidienne.

Le problème avec cette question spécifique est que c'est presque une question piège. Avec un aperçu particulier, vous obtiendrez facilement O (n), sinon vous aurez du mal à vous améliorer que O (n log n). Il se réduit presque à "Avez-vous déjà vu celui-ci?"

Je ne suis pas sûr qu'il y ait de bonnes questions algorithmiques. Si vous en posiez une basée sur la théorie des graphes, par exemple, cela dépendrait de la familiarité de la personne interrogée avec la théorie des graphes - et, si vous l'embauchez, elle pourrait se familiariser assez rapidement avec la théorie des graphiques. Encore une fois, nous sommes de retour à "Avez-vous déjà été exposé à cela?"

Il n'y a pas de temps dans une interview régulière pour résoudre de sérieux problèmes, et j'approche les choses différemment quand je peux m'asseoir, utiliser Wikipedia et généralement prendre un certain temps pour comprendre les choses. L'enquêteur n'a probablement pas le temps de discuter soigneusement de ce qu'il sait en détail et de choisir une question algorithmique appropriée.

J'ai plusieurs questions de type algorithme que j'utilise régulièrement, dont certaines sont très difficiles. Je les utilise pour voir comment ils attaquent mentalement un problème et pour voir s'ils appréhendent certains concepts. (J'ai vu beaucoup trop de candidats développeurs qui ne comprennent tout simplement pas les pointeurs.)

Vous voulez une question qui vous donnera un aperçu du candidat. Une question d'algorithme peut donner une bonne réponse ou non. Et je ne parle pas de leur capacité à y répondre ou non. S'ils y travaillent et que vous comprenez et suivez leur raisonnement, c'est un bon indicateur. S'ils restent assis là, pas de vraie réponse, ne semblent même pas savoir par où commencer, c'est un mauvais indicateur (peut-être). Le problème serait que certaines personnes gèlent, et il peut être difficile de différencier le gel de l'absence de compétences en résolution de problèmes.

Les gens se plaindront de demander à peu près n'importe quoi dans les entretiens, pour diverses raisons. Le demandeur peut geler, le demandeur aurait pu simplement chercher cette question, le demandeur peut ne pas savoir ce morceau particulier de trivia / technologie / que ce soit. Tout cela est vrai, mais une entrevue doit encore avoir lieu, et beaucoup d'entre nous dans cette profession détestent ça. Nous détestons l'idée de quelqu'un assis en jugement sur nous. Nous évoquons immédiatement les raisons pour lesquelles nous pourrions être jugés injustement, ou comment le test pourrait être faux ou joué. En bout de ligne, cela n'a pas d'importance.

Ce que vous voulez vraiment, c'est un intervieweur ayant la capacité de déterminer les compétences qui peuvent ou non être présentées lors de l'entretien. Les questions ne sont que des outils. Pour moi, tous les marteaux se ressemblent. Mais pour quelqu'un de suffisamment compétent avec eux, je suis sûr qu'il y a une différence.

J'aime les questions d'algorithme, car c'est ce que nous faisons. J'aime les contraintes, car c'est ce que nous utilisons. Big-O est particulièrement pertinent dans mon industrie.

Je n'aime pas exiger que les réponses à ce genre de questions soient "écrivez le code sur le tableau blanc". La personne interrogée doit être en mesure de parler intelligemment de l'approche de la solution et d'engager une discussion continue pendant que les intervieweurs modifient les exigences pendant que la discussion est en cours.

La question d'origine est posée, dit l'interviewé, "commencez au début et marchez vers la fin à la recherche du" trou "". L'enquêteur dit que c'est trop lent, car N est gargantuesque. La personne interrogée commence à discuter de la recherche binaire. L'enquêteur dit que tout à coup, les données ne sont plus triées. La personne interrogée dit "trier puis rechercher". "Maintenant c'est trop lent". Etc.