Comment réagir aux questions erronées / sans réponse lors de l'entretien? [fermé]

Aujourd'hui, j'ai eu ma première entrevue avec des stagiaires potentiels. Bien que ce soit principalement des questions ouvertes, j'ai eu quelques tâches de programmation triviales pour eux:

• Écrivez une fonction qui renvoie vrai si les côtés du triangle (tous les entiers) a, b et c peuvent représenter un triangle rectangle .
• FizzBuzz.
• Calculer le Nième élément de Fibonacci en utilisant la récursivité (s'ils ne savaient pas ce qu'était Fibonacci , je leur écrirais même la définition F (n) = F (n-1) + F (n-2); F (1) = 1; F (0) = 1).
• Implémentez la structure List pour l'entier et écrivez la fonction pour l'inverser.

Ce sont évidemment des tâches très faciles et je n'étais pas préparé à ce que quelqu'un ne les résout pas.

Comment dois-je agir quand ils ont du mal avec ces questions? Dois-je abandonner la réponse? Donnez un pourboire (j'ai fait cela et j'ai fini par résoudre le problème moi-même)? Ou simplement passer (ou peut-être simplement arrêter) à l'interview?

ps. En ayant des problèmes avec les questions, je ne veux pas dire comme avoir un bug, je veux dire s'ils ne peuvent même pas commencer. C'était le cas des questions de Fibonacci et de List.

Vous avez dit que vous interviewiez pour des postes de stagiaire dans la question, donc c'est de ce point de vue, pour les développeurs à temps plein, la barre sera un peu plus élevée.

Lorsque vous interviewez des stagiaires, vous devez vous rappeler qu'ils peuvent ne pas avoir terminé leurs études et qu'ils peuvent également être entrés au collège sans aucune formation préalable en programmation et en informatique. En tant que tel, vous devez adapter les attentes à ce que vous pouvez raisonnablement attendre de quelqu'un et au degré de prestige de la position (c'est-à-dire que Google peut échapper aux attentes qu'une entreprise dont les gens n'ont pas entendues peuvent).

En parcourant les questions que vous avez présentées, je les considérerais probablement comme suit dans une interview:

1) Écrivez une fonction qui renvoie vrai si les côtés du triangle (tous les entiers) a, b et c peuvent représenter un triangle rectangle.

Application de base de la géométrie avec un codage simple, la plupart des étudiants devraient pouvoir le faire sans trop de difficultés. Tout au plus, un rappel du théorème de Pythagore pourrait être nécessaire s'ils montrent un peu de stress en raison d'une interview. Cela pourrait presque être considéré comme un problème de "renforcement de l'ego" dans la mesure où cela peut aider à calmer certaines personnes si elles sont très nerveuses avant l'entretien.

2) FizzBuzz

Encore une fois, une autre application de certaines instructions de contrôle de base. Les étudiants qui n'ont pas été exposés à l'opérateur de module, ou qui ne l'ont pas beaucoup utilisé, peuvent avoir besoin de s'en souvenir, mais ne devraient pas rencontrer de problèmes réels pour résoudre le problème.

3) Calculer le Nième élément de Fibonacci en utilisant la récursivité (s'ils ne savaient pas ce qu'était Fibonacci, je leur écrirais même la définition F (n) = F (n-1) + F (n-2); F (1 ) = 1; F (0) = 1).

Cela a tendance à être un problème assez courant, de sorte que la plupart des étudiants (sinon tous) le verront à un moment donné avant l'obtention du diplôme. Le hic est qu'il apparaît généralement lorsque la récursivité est présentée aux étudiants car elle se prête bien ou une solution récursive ou basée sur une boucle qui peut ensuite être comparée afin que les étudiants de différentes écoles puissent la voir à différents moments en fonction de la séquence des cours. En pratique, si quelqu'un ne pouvait pas trouver le récursif, je demanderais une alternative en utilisant des boucles et s'il ne pouvait pas le faire, je serais plus préoccupé par sa capacité potentielle.

4) Implémentez la structure List pour l'entier et écrivez la fonction pour l'inverser.

Cette question pourrait en fait être un peu trop ouverte car elle est écrite, donc ce pourrait aussi être une bonne question pour voir comment le candidat cherche des informations supplémentaires (par exemple, si des fonctions de suppression doivent être incluses, une conversion en tableaux, etc.), mais étant donné un bien énoncé de problème défini («Mettre en œuvre une structure de liste de base pour les entiers qui permet d'ajouter des nombres à la fin ou à un index arbitraire, de les supprimer et d'inclure une fonction pour renvoyer une copie inversée de la liste»), les élèves devraient être en mesure de résoudre le problème tant que les listes sont une structure commune présentée soit dans un premier cours sur les structures de données, soit dans un premier cours d'informatique de base.

En ce qui concerne les candidats, s'ils éprouvent des difficultés, assurez-vous qu'ils sont détendus et accordez-leur un peu de clémence car ils pourraient simplement avoir une anxiété de performance car cela pourrait être leur premier véritable entretien. Des conseils sur la résolution des problèmes pourraient être nécessaires, surtout dans le cas des troisième et quatrième problèmes, par opposition aux deux premiers.

Également, structurez le processus général d'entretien de manière à ce que des points de "sortie gracieuse" soient intégrés. Par exemple, vous pourriez avoir le programme suivant:

• Rencontrer et saluer, procédures d'entrevue.
• Entretien avec le (s) programmeur (s) du personnel, questions de base sur le contexte.
• Présentation du quiz de programmation.
• Pause
• Retour de pause, licenciement de certains candidats qui ne conviennent pas.
• Entretien prolongé avec le (s) programmeur (s) du personnel.
• Entretien avec les ressources humaines (si nécessaire).
• Emballer.

Ce flux d'entrevues a tendance à bien fonctionner si vous voulez être en mesure de licencier les candidats tôt car ils savent dès le début qu'ils pourraient être licenciés après la pause. La courte entrevue avant le quiz signifie également qu'ils ne se présentent pas seulement pour passer le test, ce qui leur permet de s'entraîner à l'entretien et peut également leur permettre de décider qu'ils ne conviennent pas. Si d'autres programmeurs observent le quiz ou aident le candidat pendant celui-ci, cela leur donne également une chance de réussir / échouer le candidat pendant une courte pause.

En tout temps, lorsque vous interviewez pour un stage et que les candidats sont des étudiants, vous devez vous rappeler qu'ils sont toujours étudiants et peuvent ne pas avoir beaucoup de pratique avec les entretiens (conduisant à une éventuelle anxiété de performance) et peuvent également ne pas avoir atteint le point dans leurs études pour même être en mesure de répondre aux questions, ce qui signifie que ce pourrait être une bonne idée de les envoyer sur leur chemin avec une copie de la «solution (s) idéale (s)» aux problèmes qui leur sont également posés.

Mon objectif pour tout entretien d'embauche, peu importe de quel côté je suis, est de finir par avoir l'impression de parler à un collègue. Des collègues viennent tout le temps dans mon bureau lorsqu'ils sont bloqués sur un problème. Je demande de l'aide à mes collègues quand je suis coincé. Donc dans une interview, j'essaie de recréer cette dynamique.

En d'autres termes, que diriez-vous si un collègue avait besoin de mettre en œuvre une séquence fibonacci et ne savait pas de quoi il s'agissait? Vous leur expliqueriez jusqu'à ce qu'ils le comprennent suffisamment pour continuer par eux-mêmes. Il n'y a pas de honte dans l'ignorance tant qu'elle n'est pas permanente.

Si vous effectuez cet exercice et que vous ne pouvez toujours pas vous imaginer travailler avec cette personne, alors ils ne conviennent pas au travail.

Le point de poser des questions comme celle-ci dans une interview est de déterminer si quelqu'un peut comprendre comment résoudre les problèmes. Le travail de programmeur consiste généralement en deux choses: "Prenez ces exigences et implémentez-les dans le code" et "découvrez pourquoi l'implémentation ne correspond pas aux exigences et corrigez-la". Donc ce que vous cherchez vraiment n'est pas une solution à ces questions spécifiques, mais la capacité de comprendre les choses.

Comprenant cela, je donnerais un indice ou deux pour démarrer quelqu'un, et peut-être un peu plus s'il est clair qu'ils font de réels progrès mais manquent un détail quelque part. Mais s'il devient clair qu'ils ne savent tout simplement pas comment résoudre le problème, alors vous avez votre réponse et il n'est pas nécessaire de poursuivre l'exercice.

Pour donner un exemple, lorsque j'ai interviewé à mon poste actuel, on m'a posé une question sur la recherche du chemin le plus court d'un nœud à un autre sur un graphique. J'ai répondu que j'utiliserais probablement quelque chose comme l'algorithme de Dijkstra, dont je me souviens vaguement avoir appris un jour à l'université et que je n'avais jamais utilisé depuis, et j'en ai donné une explication rapide (et incorrecte) qui satisfaisait aux conditions spécifiques données par le question. L'enquêteur a souligné que ma solution se retrouverait dans une boucle infinie si le graphique était légèrement modifié, et que jogging ma mémoire, j'ai donc expliqué la bonne façon d'éviter ce problème. Et j'ai fini par décrocher le poste.

pour les postes de stagiaire, vous demandez peut-être un peu.

Je n'ai aucune idée de ce que vous entendez par la quatrième question. Quant à poser une question de récursivité, c'est un peu impraticable, passer par votre propre base de code et déterminer le nombre de zones de récursivité utilisées, je suis prêt à parier que ses quelques-aucune. Les situations d'entrevue sont stressantes, et s'attendre à ce que les candidats mettent en œuvre des stratégies rarement utilisées qui sont à l'envers par rapport à la plupart des choses que vous programmerez est injuste pour eux, en particulier vers le début d'une entrevue. Personnellement, je poserais des questions où ils doivent expliquer ce que signifient les concepts importants / comment ils sont utilisés, en fournissant des exemples prédéfinis. Je serais beaucoup plus intéressé par les candidats qui peuvent vous dire que X book ou Google Y search fourniront tout le nécessaire pour implémenter quelque chose dans votre base de code.

À mon humble avis, vos deux premières questions devraient pouvoir être résolues par quiconque se qualifie de programmeur, qu'il soit junior ou senior, directement sorti de l'école ou autodidacte.

Si je constate que l'intervieweur a des difficultés avec l'un ou l'autre de ces éléments, j'essayerais de reformuler le problème et de vérifier s'il a bien compris. Encouragez-la ensuite à utiliser un stylo et du papier, un tableau blanc, à dessiner des figures ou toute autre approche qu'elle préfère pour résoudre le problème. Je lui demande également de réfléchir à haute voix, d'avoir une vue sur son processus de réflexion et, si nécessaire, de donner de petits indices si elle est sur la bonne voie, n'ose tout simplement pas avancer ou a un obstacle. Mais si même plusieurs indices ne vous aident pas, ou - comme vous l'avez mentionné ci-dessus - je finis par résoudre le problème pour elle, je terminerais probablement l'entretien pour arrêter de perdre plus de temps. Dans une interview, je m'efforce toujours de voir et de me concentrer sur ce que la candidate sait, au lieu de ce qu'elle ne sait pas, mais si je n'arrive pas à trouver de connaissances importantes, j'abandonne après un certain temps.

Les 3e et 4e sont un peu plus difficiles, donc je pourrais accepter si un junior ne pouvait pas les obtenir, s'il (ou elle) avait fait preuve d'une bonne approche de résolution de problèmes et d'enthousiasme. Mais pour un senior, ils sont toujours un must.

J'ai dû chercher ce que vous vouliez dire par "FizzBuzz"; il s'avère que j'avais entendu parler du jeu et de ses règles, mais pas de ce nom et pas depuis un moment. Donc, ne pensez pas que vous ne devez donner AUCUNE information aux personnes interrogées.

Cela dit, ce sont tous des problèmes de codage de base que je m'attendrais à ce qu'une personne interviewant, même pour un poste de codeur d'entrée de gamme, puisse réfléchir, si elle ne pouvait pas coder une réponse par inspection. Nous sommes donc sur la même page là-bas. La réponse à votre problème dépend de la façon dont ils se trompent:

• Problèmes de syntaxe mineurs: si vous attendez du code dans une certaine langue, ne comptez pas trop lourdement s'il manque un point-virgule ou une faute d'orthographe lors de l'utilisation d'un identifiant. La plupart des IDE le verront immédiatement, et tout le monde fait des fautes de temps en temps. Dans presque toutes les interviews dans lesquelles je devais coder quelque chose, le "pseudo-C-ish" était acceptable tant que l'algorithme était correctement communiqué à l'intervieweur et que la logique était saine.

• Faille logique mineure: si l'algorithme se comportait comme prévu dans la plupart, mais pas dans tous, les scénarios attendus (par exemple lors du codage de FizzBuzz, 15 ne donnerait que "Fizz" ou "Buzz" mais pas les deux comme il est censé le faire), alors être le "testeur d'unité" et souligner que l'algorithme échouerait dans ce cas, et voir s'ils peuvent le réparer. Ils peuvent avoir ignoré ce cas particulier ou ne pas avoir suffisamment compris les exigences. Les deux sont encore une fois des événements quotidiens parfaitement compréhensibles dans le codage, qui devraient être facilement surmontés en fournissant simplement des informations ou des commentaires supplémentaires.

• Failles logiques majeures: si l'algorithme ne réussit pas la plupart des scénarios de test qui lui ont été donnés, signalez-le également et voyez s'ils peuvent le corriger. C'est plus un problème; soit ils ont mal compris une exigence très fondamentale du système, soit ils ont négligé un trou logique béant. Mais, s'ils peuvent le résoudre en donnant plus de détails sur le problème, sans qu'on leur dise exactement où leur code échoue, attribuez-le à des exigences peu claires et passez à autre chose.

• Je ne sais pas par où commencer / réponse codée en dur à des cas spécifiques / ne peut pas comprendre leur pseudocode: ce sont les drapeaux rouges. Si vous demandez à quelqu'un de coder un algorithme qui suit les règles de FizzBuzz, en leur expliquant ces règles et que vous obtenez un regard vide, l'interview est terminée. De même, s'ils peuvent mettre QUELQUE CHOSE sur le tableau mais qu'il échoue dans de grandes parties de l'espace du problème, et que vous devez tenir la main pour illustrer l'échec et comment y remédier, je ne passerais pas à une deuxième interview .

Si vous avez vraiment un stagiaire potentiel qui agit comme un cerf dans le phare parce qu'il n'a jamais été interviewé, a des problèmes d'anxiété, n'a jamais été dans une situation de la vie réelle comme ça (vous le remarquez généralement à partir de leur langage corporel), vous pouvez simplement commencer par en leur demandant sur quoi ils ont travaillé en dernier.

Ensuite, ce sera son territoire afin qu'il ne soit pas follement nerveux. Lorsque vous trouvez un endroit approprié, demandez: "Hé, comment avez-vous mis cela en œuvre?". S'il peut expliquer, cela pourrait vous donner un aperçu de sa façon de penser.

Mettez vos propres tests à l'ordre du jour après cela.

Fizzbuzz est une exigence absolue. S'ils ne peuvent pas coder Fizzbuzz, vous ne devriez pas les embaucher.

Je demande généralement au candidat une session de code pré-entretien, où nous utilisons Google Docs pour résoudre un problème de programmation (généralement Fizzbuzz + un problème de niveau supérieur s'il peut facilement terminer Fizzbuzz).

Je suis généralement au téléphone ou sur skype avec eux pendant cela, et comme je les regarde résoudre le problème (et leur parler de ce qu'ils pensent à certains moments), je peux être raisonnablement sûr qu'ils ne l'ont pas fait t juste google la réponse.

Tant que vos autres problèmes sont bien spécifiés (c'est-à-dire que vous leur donnez la formule pour chacun), alors vos questions sont très bien.

Lorsque j'interviewe des candidats, j'essaie de m'en tenir aux problèmes de programmation qu'ils sont susceptibles de rencontrer. J'adore les problèmes de manipulation de chaînes, car lorsque vous êtes sur le Web, à peu près tout ce que l'utilisateur doit faire concerne une sorte de manipulation de chaînes. Comment ils gèrent cela est important.

Cela dépend du calibre du poste que vous essayez de combler.

Si vous optez pour un développeur senior, je m'attends à ce qu'ils sachent tout cela. S'ils se trompaient et que je me sentais mal, j'arrêterais juste l'interview, merci et au revoir. Si j'étais d'humeur plus polie, je les remercierais et me précipiterais pendant le reste de l'interview.

Si j'allais pour un développeur junior, ces questions pourraient être considérées comme assez difficiles. Je serais plus intéressé à explorer leur capacité et leur volonté d'apprendre. J'essayais donc de leur donner des indices, de les guider et de voir comment ils réagissaient.

Les entretiens avec les stagiaires sont une autre race d'interview. Ce que je fais généralement, c'est utiliser mes questions de développeur standard (comme celles que vous avez fournies) pour évaluer où ils en sont dans leur formation. La capacité de résoudre ces problèmes variera considérablement des étudiants de deuxième année aux personnes âgées.

Après avoir obtenu ces informations, je concentre ensuite l'entretien sur d'autres compétences telles que: pourront-ils travailler en équipe, seront-ils enseignables, bénéficieront-ils d'un stage dans notre entreprise, seront-ils passionnés par le développement / l'apprentissage, etc.

Pour moi, ce sont les choses non techniques qui distinguent vraiment un stagiaire des autres candidats. Je préférerais de beaucoup passer quelques mois à encadrer / encadrer quelqu'un qui est déterminé à apprendre et à grandir, plutôt que quelqu'un qui veut juste un emploi pour le semestre.

Demandez-vous quelle valeur la personne interrogée est susceptible d'ajouter à votre entreprise. Tenez compte du coût de la participation d'un mentor, surtout s'il ne peut pas résoudre les problèmes au niveau du fizzbuzz. Si la réponse n'est pas proportionnelle au salaire prévu, vous avez de bonnes raisons économiques de ne pas les embaucher.

N'ayez pas peur de retourner voir votre manager et de dire "il n'y a pas de candidats qui ajouteraient suffisamment de valeur à notre entreprise pour que leur recrutement en vaille la peine". Cela doit être une meilleure ligne de conduite que de se retrouver avec quelqu'un qui a en fait une valeur négative, en raison du coût d'avoir constamment quelqu'un pour l'aider.

Ma réponse peut sembler un peu méchante ou dédaigneuse, mais je pense que cela fonctionne bien. Pour commencer, je donne au candidat une question très simple, qui sert de question d'échauffement pour aider à renforcer sa confiance. Qu'ils réussissent ou non, je passe à une question moins banale et directement liée à ce que le travail implique.

À ce stade, c'est tout ou rien. S'ils y naviguent, tant mieux, pas de problème. S'ils luttent un peu, pas de problème, je les aiderai à avancer, puis je passerai à d'autres questions pour évaluer d'autres capacités.

Si, cependant, ils n'ont absolument pas la capacité de le résoudre, je continue et je brûle le reste du temps d'entrevue pour les aider. Le candidat se sent toujours engagé dans l'entretien, mais je n'ai pas à orienter l'entretien dans des directions différentes et non pertinentes. C'est bon pour le candidat aussi, car cela peut être éducatif.

1. Essayez d'être gentil avec eux. Par vos questions, on voit que vous n'essayez pas d'être gentil même ici. Pensez-vous que tout le monde devrait connaître ce terme de "fizzbuzz"? Ou nous devrions chercher sur le net parce que vous étiez paresseux pour l'écrire vous-même? Au contraire, je pense que tout le monde ici sait ce qu'est le triangle rectangle.
2. Qu'est-ce que la "liste des structures"? Je ne sais pas. Je connais "la structure de la Liste". Qu'est-ce que cela signifie: Liste pour un entier? Liste d'entiers que vous voulez dire? Moi aussi, je ne saurais pas par où commencer. Et s'il vous plaît, ne parlez pas que vous n'êtes pas anglais. Moi aussi. Et même je n'avais jamais été dans un pays anglophone. Vous savez sûrement qu'un entier au pluriel sera un entier s . Si vous essayez de ne pas être compréhensible avec vos égaux ici, je peux imaginer comment vous faites là - bas .
3. Tout programmeur alphabétisé sait que la ligne de Fibonacci est un exemple de livre de ce qui ne devrait pas être fait par récursivité. Les testez-vous pour leur capacité à vous opposer ou pour les compétences de codage? Faites votre travail et trouvez un meilleur exemple pour tester les compétences dans l'utilisation de la récursivité.
4. «La capacité de travailler sous stress» pour un programmeur signifie qu'il pourrait travailler des nuits quand cela est nécessaire. Mais si vous voulez avoir de bons programmeurs, ils attendraient que leur chef soit un gars très gentil, compréhensif et serviable. Sinon, vous n'aurez jamais de bons programmeurs. Ce ne sont pas des mâles alpha-rat. S'ils ressentent une agression, ils fermeront simplement leur coquille et ne feront rien.

Donc, ma réponse est: soyez mieux préparé vous-même.

PS Vous êtes déjà un manager, donc vous devriez vraiment garder le stress.