Comment réagir à des questions erronées / non répondues lors de l'entretien?
Aujourd'hui, j'ai tenu ma première entrevue avec des stagiaires potentiels. Bien que cela ait été surtout ouvert des questions, j'ai eu des tâches de programmation triviales pour eux:
- Écrivez une fonction qui retourne true si les côtés triangulaires (tous les entiers) A, B et C peuvent représenter un triangle droit .
- Fizzbuzz.
- Calculez le nième élément de Fibonacci à l'aide de la récursion (si elles ne savaient pas ce qu'était Fibonacci , je les écrirais même la définition F(n) = F(n-1) + f (n-2); F(1) = 1; F(0) = 1).
- Implémentez la liste des structures pour la fonction entier et d'écriture pour l'inverser.
Ce sont des tâches évidemment très faciles et je n'étais pas préparé pour quelqu'un de ne pas les résoudre.
Comment devrais-je agir quand ils luttent avec ces questions? Devrais-je abandonner la réponse? Donner une pointe par TIP (je l'ai fait et avons fini par résoudre le problème moi-même)? Ou juste passer à autre chose (ou peut-être juste arrêter) avec l'entretien?
ps. En ayant des problèmes de questions, je ne veux pas avoir un bogue, je veux dire s'ils ne peuvent même pas commencer. C'était un cas avec Fibonacci et des questions de liste.
Vous avez dit que vous interviewez des postes de stagiaires dans la question de sorte que cela vient 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 n'auraient peut-être pas achevé leurs études et qu'ils ont peut-être également entré au collège sans aucun contexte précédent en programmation et en informatique. En tant que tel, vous devez accélérer les attentes à ce que vous pouvez raisonnablement vous attendre à ce que quelqu'un sache et au degré de prestige du poste (c'est-à-dire que Google peut s'échapper avec les attentes qu'une entreprise n'a pas entendu parler de CAN).
En examinant les questions que vous avez présentées, je les considérerais probablement comme suit dans une interview:
1) Écrivez une fonction qui retourne true si les côtés triangulaires (tous les entiers) A, B et C peuvent représenter un triangle droit.
Application de base de la géométrie avec un codage simple, la plupart des étudiants devraient pouvoir le faire sans trop de difficulté. Au plus rappel du théorème de Pythagoreen pourrait être nécessaire s'ils montrent un peu de stress en raison d'une entrevue. Cela pourrait presque être considéré comme un problème de "ego boost" en ce sens qu'il peut aider à régler certaines personnes si elles sont très nerveuses dans l'entretien.
2) FIZZBUZZ
Encore une fois, une autre application de quelques déclarations de contrôle de base. Les étudiants qui n'ont pas été exposés à l'opérateur du module ou ne l'ont pas beaucoup utilisé, il faudra peut-être le rappeler, mais ne devrait pas rencontrer de problèmes réels résolvant le problème.
3) Calculez le nième élément de Fibonacci à l'aide de la récursivité (s'ils ne savaient pas ce que Fibonacci était, je les é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 commun, donc la plupart des élèves (sinon tous) le verront à un moment donné avant leur diplôme. La capture est que cela apparaît généralement lorsque la récursivité est présentée aux élèves, car elle se prête bien ou une solution à base de boucle qui peut alors être comparée pour que les étudiants de différentes écoles puissent la voir à des moments différents en fonction de la séquence de cours. En pratique, si quelqu'un ne pouvait pas venir avec la récursive, je demanderais une alternative utilisant des boucles et si elles ne pouvaient pas trouver que je serais plus préoccupé par leur capacité potentielle.
4) Implémentez la liste des structures pour la fonction entier et en écriture pour l'inverser.
Cette question pourrait en réalité être un peu trop ouverte, car elle est écrite, elle pourrait également être une bonne question à voir comment le candidat recherche des informations supplémentaires (par exemple, devriez supprimer des fonctions, la conversion en tableaux, etc.), mais donné un puits Déclaration de problème définie ("Mettre en place une structure de liste de base pour les entiers qui permettent d'ajouter des chiffres à la fin ou à un indice arbitraire, supprimé et inclure une fonction pour renvoyer une copie inversée de la liste") Les étudiants doivent pouvoir résoudre Le problème tant que les listes sont une structure commune présentée dans un cours de structures de données précoce ou dans un cours d'informatique de base précoce.
En termes de traiter avec les candidats, s'ils se débattent, assurez-vous qu'ils sont détendus et leur permettent d'avoir une anxiété de performance, car cela pourrait être leur première réelle entrevue. Des conseils sur la résolution des problèmes peuvent être nécessaires, le plus dans le cas des troisième et quatrième problèmes, par opposition aux deux premiers.
En outre, structurer le processus d'entretien global de sorte qu'il existe des points "Gracieux sortie" intégrés. Par exemple, vous pourriez avoir l'agenda suivant:
- Rencontrer et saluer, procédures d'entrevue.
- Entretien abrégé avec programmeur (s) de personnel, questions de base sur l'arrière-plan.
- Présentation du questionnaire de programmation.
- Casser
- Retour de la pause, le renvoi de certains candidats qui ne sont pas un bon ajustement.
- Entretien prolongé avec programmeur (s) du personnel (s).
- Entretien avec les ressources humaines (si nécessaire).
- Conclure.
Ce flux d'entrevue a tendance à bien fonctionner si vous voulez pouvoir licencier les candidats tôt, car ils savent dès le début qu'ils pourraient être licenciés après la pause. L'entretien court avant que le quiz signifie également qu'ils ne sont pas simplement présentés pour prendre le test qui leur obtiennent une pratique d'entretien et peut également leur permettre de décider qu'ils ne sont pas un bon ajustement. S'il y a d'autres programmeurs observant le quiz ou en aidant le candidat au cours de cela, cela leur donne également une chance de réussir/échouer au candidat pendant qu'ils prennent une courte pause.
À tout moment lorsque vous interviewez pour un stage et que les candidats sont des élèves, vous devez vous rappeler qu'ils sont toujours des étudiants et qu'ils n'auront peut-être pas beaucoup de pratique avec des entretiens (conduisant à une éventuelle anxiété de performance) et n'auront pas non plus atteint le point dans leurs études à Même être capable de répondre aux questions qui signifie que cela pourrait être une bonne idée de leur envoyer sur leur chemin avec une copie de la "solution idéale (s)" aux problèmes qu'ils sont donnés.
Mon objectif pour tout entretien d'embauche, quel que soit le côté que je suis sur le côté, est de finir par avoir ressenti comme je parle à un collègue. Les collègues entrent dans mon bureau tout le temps quand ils sont bloqués sur un problème. Je demande à mes collègues de l'aide quand je me suis coincé moi-même. Donc, dans une interview, j'essaie de recréer cette dynamique.
En d'autres termes, que diriez-vous si un collègue devait mettre en œuvre une séquence de fibonacci et ne savait pas ce que c'était? Vous leur l'expliqueriez jusqu'à ce qu'ils la saisissent suffisamment pour continuer leur propre. Il n'y a aucune honte dans l'ignorance tant qu'elle n'est pas permanente.
Si vous passez à travers cet exercice et que vous ne pouvez toujours pas vous imaginer travailler avec cette personne, alors ils ne sont pas un bon ajustement pour le travail.
Le point de donner des questions comme celle-ci dans une interview est de déterminer si une personne peut déterminer comment résoudre des problèmes. Le travail d'étant un programmeur consiste généralement en deux choses: "Prends ces exigences et les mettre en œuvre dans le code" et "déterminer pourquoi la mise en œuvre ne correspond pas aux exigences et corrige-la." Donc, ce que vous recherchez vraiment n'est pas une solution à ces questions spécifiques, mais la capacité de comprendre les choses.
Comprendre cela, je donnerais un indice ou deux pour que quelqu'un commence quelqu'un et peut-être encore plus s'il est clair qu'ils font des progrès réels, mais il manque un détail quelque part. Mais si cela devient clair qu'ils ne pouvaient tout simplement pas comprendre comment résoudre le problème, vous avez votre réponse et il n'est pas nécessaire de continuer avec l'exercice.
Pour donner un exemple, lorsque j'ai interviewé mon emploi actuel, on m'a donné 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'avais probablement utiliser quelque chose comme l'algorithme de Dijkstra, que je me souvenais vaguement d'avoir appris environ une journée au collège et n'avait jamais utilisé depuis et donné une explication rapide (et incorrecte) qui satisfait aux conditions spécifiques données par le question. L'intervieweur a souligné que ma solution se retrouverait dans une boucle infinie si le graphique a été légèrement modifié, et que je me suis fermé ma mémoire, j'ai donc expliqué la bonne façon d'éviter ce problème. Et j'ai fini par avoir le travail.
pour les postes de stagiaires, vous pourriez demander un peu beaucoup.
Je n'ai aucune idée de ce que vous entendez même par la 4ème question. En ce qui concerne la question de la restauration, c'est un peu impraticable, passez par votre base de code et déterminez le nombre de zones de récursivité de zones, je suis disposé à parier que ses quelques-aucun. Les situations d'entrevue sont stressantes et les candidats à la mise en œuvre de stratégies rarement utilisées en arrière par rapport à la plupart des choses que vous allez jamais programmer est injuste pour eux, en particulier vers le début d'une interview. Personnellement, je poserais des questions sur lesquelles ils doivent expliquer quels concepts importants signifient/comment ils sont utilisés, fournissant des exemples en conserve. Je serais beaucoup plus intéressé par les candidats qui peuvent vous dire que la recherche X ou Google Y fournira tout ce qui est nécessaire pour mettre en œuvre quelque chose à votre base de code.
IMHO, vos deux premières questions devraient être résolvibles à tous ceux qui lui appellent un programmeur, que ce soit junior ou senior, tout droit à l'école ou autodidacte.
Si je vois que l'intervieweur a du mal à l'une ou l'autre, j'essaierais de reformuler le problème et de vérifier s'il l'a parfaitement compris. Ensuite, encouragez-la à utiliser le stylo et le papier, le tableau blanc, dessiner des chiffres ou toute approche qu'elle préfère lutter contre le problème. Je lui demande également de penser à haute voix, d'avoir une idée dans son processus de pensée et, si nécessaire, donnez de petites astuces si elle est sur la bonne piste, n'ose tout simplement pas avancer ou a un obstacle. Mais si même plusieurs astuces ne vous aident pas, ou - comme vous l'avez mentionné ci-dessus - je finis à résoudre le problème pour elle, je terminerais probablement l'entretien pour arrêter plus de perdre notre temps. Dans une interview, je m'efforce toujours de voir et de me concentrer sur ce que le candidat sait, au lieu de ce qu'elle ne le fait pas, mais si je ne peux pas sembler trouver une connaissance importante, j'abandonne après un moment.
Les 3ème et 4ème sont un peu plus difficiles, je pourrais donc accepter si un junior ne pouvait pas les obtenir, si (s), il a également démontré une bonne approche et enthousiasme de résolution de problèmes. Mais pour un senior, ils sont toujours indispensables.
Je devais regarder ce que vous vouliez dire par "fizzbuzz"; Il se trouve que j'avais entendu parler du match et de ses règles mais pas par ce nom et pas de temps en temps. Alors, ne pensez pas que vous ne devez pas donner d'informations aux interviewés.
Cela dit, il s'agit de tous les problèmes de codage fondamentaux que je vous attendrais à une interview d'une interview pour même une position de codage d'entrée de gamme pour pouvoir penser à leur chemin, s'ils ne pouvaient 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 mineure : Si vous attendez du code dans une certaine langue, ne comptez pas trop trop si elles manquent un point-virgule ou une mauvaise utilisation d'un identifiant. La plupart des idées vont attraper cela immédiatement et tout le monde fait de temps en temps de temps en temps. Dans presque tous les entretiens dans lesquels je devais coder quelque chose, "pseudo-c-ish" était acceptable tant que l'algorithme a été communiqué correctement à l'intervieweur et la logique était sonore.
Frame logique mineure : Si l'algorithme se comporterait comme prévu dans la plupart des scénarios attendus (par exemple, lorsque le codage FIZZBUZZ, 15 n'entraînerait que "Fizz" ou "Buzz" mais pas tous les deux Comme c'est supposé), alors soyez le "testeur de l'unité" et soulignez que l'algorithme échouerait dans ce cas et voyez s'ils peuvent le réparer. Ils ont peut-être oublié ce cas particulier, sinon ils n'ont peut-être pas compris les exigences suffisamment totalement. Les deux sont à nouveau complètement compréhensibles, des occurrences quotidiennes dans le codage, qui doivent être facilement surmontées en fournissant simplement des informations supplémentaires ou des commentaires.
défauts logiques majeurs : Si l'algorithme ne réussirait pas la plupart ou les scénarios de test, cela a été donné, signalez-le aussi et voyez-le s'ils peuvent le réparer. C'est plus un problème; Soit ils ont mal compris certaines exigences très fondamentales du système, soit ils ont négligé un trou logique béant. Mais, s'ils peuvent réparer cela donnant plus de détails sur le problème, sans être dit exactement où leur code échoue, la craque de manière peu claire et passez à autre chose.
Ne sait pas où commencer/la réponse à codée 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 expliquant ces règles, et vous obtenez un regard vide, l'entrevue est terminée. Par la même jeton, s'ils peuvent mettre quelque chose sur le tableau, mais il échoue à de grandes portions de l'espace problématique, et vous devez vous tenir la main lors de l'illustration de l'échec et de la manière de le réparer, je ne ferais pas passer à une deuxième interview .
Si vous avez vraiment eu un stagiaire potentiel qui agit comme un cerf dans le phare parce qu'il n'a jamais été interrogé, a des problèmes d'anxiété, n'a jamais été dans une situation de vie réelle comme celle-là (vous remarquez habituellement de leur langage corporel), vous pouvez simplement commencer par leur demander ce qu'ils ont travaillé enfin.
Ensuite, ce sera son territoire afin qu'il ne soit peut-être pas follement nerveux. Lorsque vous trouvez un endroit approprié, demandez: "Hé, comment avez-vous mis en œuvre cela?". 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 d'une session de code de pré-interview, où nous utilisons Google Docs pour travailler via un problème de programmation (généralement un problème de niveau de niveau supérieur si elle peut facilement compléter Fizzbuzz).
Je suis généralement sur le téléphone ou sur Skype avec eux pendant cela, et puisque je les regarde, remplissez le problème (et en leur parlant de ce qu'ils pensent à certains points), je peux être raisonnablement confiant qu'ils ne voulaient pas 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 bien bien.
Lorsque j'utilise des candidats, j'essaie de vous engager à la programmation de problèmes auxquels ils sont susceptibles de rencontrer. J'adore les problèmes de manipulation de chaîne car lorsque vous êtes sur le Web, à peu près tout ce que l'utilisateur est confronté a à voir avec une sorte de manipulation de chaîne. Comment ils gèrent cela est important.
Cela dépend du calibre de la position que vous essayez de remplir.
Si vous allez pour un développeur senior, alors je m'attendrais à ce qu'ils connaissent tout cela. S'ils ont eu tort et que je me sentais mal, je voudrais juste arrêter l'interview, merci et au revoir. Si j'étais d'humeur plus polie, je les remercierais et me précipiterais dans le reste de l'entretien.
Si j'allais pour un développeur junior, ces questions pourraient être considérées comme assez difficiles. Je serais plus intéressé à explorer leurs capacités et leur volonté d'apprendre. Je vais donc essayer de leur donner des allusions et de les guider et de voir comment ils répondent.
Demandez-vous quelle valeur l'interviewé est susceptible d'ajouter à votre entreprise. Facteur dans le coût d'un mentor impliqué, surtout s'ils ne peuvent pas résoudre les problèmes au niveau de Fizzbuzz. Si la réponse n'est pas à la mesure du salaire prévu, alors vous avez un bon cas économique pour ne pas les embaucher.
N'ayez pas peur de revenir à votre responsable et de dire "il n'y avait pas de candidats qui ajouteraient une valeur suffisante à notre entreprise pour en faire la mise en œuvre". Cela doit être un meilleur plan d'action que de finir par une personne qui est en réalité de valeur négative, en raison du coût d'une personne qui les aide constamment.
Ma réponse peut sembler un peu méchant ou décourager, mais je pense que cela fonctionne bien. Pour commencer, je donne une question au candidat très facile, ce qui sert de question de réchauffement pour aider à renforcer leur confiance. Ils réussissent ou non, je passe à une question moins triviale et directement liée à ce que le travail implique.
À ce stade, tout est tout ou rien. S'ils naviguent bien, bon, pas de problème. S'ils luttent un peu, aucun problème, je vais aider à les pousser et ensuite à passer à d'autres questions pour gêner d'autres capacités.
Si, toutefois, ils manquent totalement de la capacité de le résoudre, je vais de l'avant et brûlez le reste de la durée de l'entretien qui les aidait. Le candidat se sent toujours engagé dans l'entretien, mais je n'ai pas à diriger l'entretien dans des directions différentes et non pertinentes. C'est bien pour le candidat, aussi, car il peut être éducatif.
- 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 "fizzbuzz"? Ou nous devrions rechercher le net parce que vous étiez paresseux pour l'écrire vous-même? Au contraire, je pense que tout le monde ici sait quel est le vrai triangle.
- Quelle est la "liste de structures"? Je ne sais pas. Je connais "la structure de la liste". Qu'est-ce que cela signifie: liste pour entier? Liste des entiers que vous voulez dire? Moi aussi, je ne saurais pas commencer à 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 savoir que l'entier au pluriel sera entiers. Si vous n'essayez pas d'être compréhensible avec vos égaux ici, je peux imaginer comment vous allez là-bas .
- Tout programmateur alphabète sait que Fibonacci Row est un exemple de livre de ce qui ne devrait pas être fait par récursivité. Les tests-tu pour la capacité de vous opposer à vous ou à des compétences de codage? Faites votre travail et trouvez un meilleur exemple pour tester les compétences en utilisant la récursivité.
- "Capacité à travailler sous stress" pour un programmeur signifie qu'il pourrait travailler pour les nuits quand il est nécessaire. Mais si vous voulez avoir de bons programmeurs, ils attendraient que leur chef est un très bon, compréhensif et serviable. Si vous n'êtes pas, vous n'aurez jamais de bons programmeurs. Ce ne sont pas des mâles alpha-rat. S'ils ressentent une agression, ils feront simplement fermer dans leurs coquillages et ne feront rien.
Donc, ma réponse est la suivante: soyez mieux préparé vous-même.
P.s. Vous êtes déjà un gestionnaire, donc, vous devriez vraiment faire du stress.