Fournissez au candidat un véritable test de programmation lors de l'entrevue - un ordinateur portable connecté à un projecteur avec un projet défectueux, avec un mélange de bogues basiques à complexes, et demandez-leur d'ajouter des fonctionnalités, allant de basique à modérément complexe. C'est quelque chose que personne ne peut vraiment étudier et qui fournira en fait une vitrine de leurs compétences. Demandez à des techniciens là-bas de parler au candidat pour avoir une idée de sa personnalité et de la façon dont il aborde les problèmes rencontrés.

Pour l'entretien d'embauche pour mon rôle actuel, j'avais passé 2 semaines à étudier les principes de programmation, les modèles de conception , des bases de données, etc. J'ai pu bien répondre à toutes les questions théoriques et je pense que je suis bien tombé

On m'a ensuite remis un ordinateur portable qui était connecté au projecteur et on m'a montré une solution contenant un site Web cassé avec un nombre défini d'erreurs que j'ai dû déboguer et ajouter des fonctionnalités simples. Bien que je ne sois pas très familier avec le framework front-end utilisé par l'entreprise, j'ai pu corriger environ la moitié des bogues, puis donner ma meilleure estimation des causes des bogues restants en fonction de ce que j'ai pu voir, et c'était assez bon pour me faire passer la porte.

Le tout, entre les questions théoriques et la session de débogage du site Web a duré environ 2 heures.

une fois que vous aurez effectivement obtenu le poste, vous ne rencontrerez probablement plus jamais aucun de ces problèmes du livre d'entretien d'embauche

Si leur travail n'implique pas de résoudre ce genre de problèmes, pourquoi les tester sur eux en premier lieu?

Pourquoi ne pas leur donner un vrai problème qu'ils rencontreraient au travail?

C'est ma recommandation. Vous aurez sûrement de nombreux exemples de problèmes réels au travail parmi lesquels choisir pour en trouver un qui vous convient.

Il y a environ un an, j'ai commencé à discuter avec les candidats. Il existe de nombreux sujets controversés dans l'industrie et qui n'ont pas qu'une seule bonne réponse. Les réponses aux questions sur ces sujets commencent généralement par "Cela dépend…" - par exemple:

• Quel cadre est le meilleur?
• Quelle base de données préférez-vous et pourquoi?
• Un certain modèle de conception est-il réellement utile?
• Concentrez-vous d'abord sur les nouvelles fonctionnalités ou corrigez les bogues?

Je demande d'abord aux candidats leur opinion. Une fois qu'ils ont compris leur point de vue, je choisis simplement le contraire et je m'oppose à cela. Ou je donne un exemple dans lequel leur choix ne serait pas une bonne réponse et leur demande si et comment ils veulent changer leur réponse avec ce nouvel exemple / exigence? La discussion suivante m'en dira beaucoup.

• Ont-ils seulement mémorisé quelques faits pour l'entrevue ou ont-ils réellement de l'expérience dans ce domaine et de bons exemples pour prouver leur point? En fait, j'ai été très surpris par la fréquence à laquelle leur argument est: parce que je l'ai toujours fait de cette façon
• Dans quelle mesure sont-ils capables de faire passer leurs arguments et les détails techniques complexes? Sont-ils bons dans l'enseignement?
• Comment gèrent-ils la résistance? Essayent-ils de convaincre, essaient-ils de plaire ou commencent-ils à être agressifs ou arrogants? Sont-ils ouverts à l'apprentissage?

Je suis conscient que cela peut être très stressant pour le candidat. Par conséquent, cela doit être fait très soigneusement.

• Avoir plusieurs intervieweurs . Vos ingénieurs les plus forts de l'équipe devraient participer au processus d'entrevue - ils veulent vraiment travailler avec des gens mieux que ceux qui ont des difficultés, n'est-ce pas? Laissez les autres ingénieurs mener leur propre entretien individuel. Et demandez à un autre ingénieur de faire les premiers écrans du téléphone.

• Posez une question de conception ouverte . pour un problème de complexité moyenne. Demandez au candidat d'écrire le fichier d'en-tête, les déclarations de classe, les diagrammes en boîte, etc ... Le candidat pose-t-il des questions de clarification? Une fois qu'il a terminé avec une conception de base, introduisez une nouvelle exigence qui briserait sa conception. Est-il capable de pivoter? Choisissez une partie de sa conception et explorez plus en profondeur.

• Posez une question pour savoir s'ils ont une compréhension approfondie des principes fondamentaux de la plate-forme . Quelques exemples que j'ai demandés:

  • "Comment le compilateur C ++ implémente-t-il des méthodes virtuelles?"
  • "Comment fonctionnent les fermetures en JavaScript?"
  • "Expliquez quand vous voudriez utiliser UDP au lieu de TCP."
  • "Après avoir saisi www.foo.com dans la barre d'adresse d'un navigateur, parlez-moi de toute l'activité réseau et des protocoles impliqués pour afficher le contenu à l'écran."

• Sondez pour un réel intérêt pour la programmation . Cela vaut davantage pour les candidats universitaires et les ingénieurs juniors et moins pour les embauches expérimentées. Un exemple de questions est «Parlez-moi d'un programme que vous avez écrit pour le plaisir et qui n'était pas pour le travail ou l'école». Un bon candidat vous parlera d'une application, d'un site Web ou d'un hack qu'il a fait pour son plaisir personnel. Un candidat plus faible ne vous parlera que du programme qu'il a écrit pour trouver quelque chose pour le travail / l'école.

J'ai passé la plus grande partie de ma vie en tant qu'ingénieur électricien et, dans les années 90, de nombreuses entreprises avec lesquelles j'ai interviewé ont cessé de me poser des questions sur l'électrotechnique. Entre ma scolarité et mon CV de travail, il était évident pour eux que j'en savais suffisamment sur l'électrotechnique pour répondre à leurs besoins. Qu'est-ce qu'ils ont demandé?

Ma personnalité. Ma capacité à travailler (et à diriger) une équipe. Mes compétences transversales. Ma capacité à apprendre.

Pour être impitoyablement brutal, les compétences en ingénierie (en particulier les compétences en programmation) sont un centime à la douzaine. Il y a tellement de gens fondamentalement compétents qu'il n'y a rien sur la programmation ou l'ingénierie qui vaille la peine d'être demandé (à moins que vous n'interrogiez un nouveau diplômé sans expérience de stage).

Ce qui est important, c'est d'être sûr que le candidat est adapté à votre environnement. Dans quelle mesure travailleront-ils avec les personnalités existantes dans votre entreprise? Apportent-ils plus que les compétences nécessaires pour le travail de base? À quelle vitesse peuvent-ils s'adapter aux changements d'orientation de l'entreprise? La technologie? ou normes de conception? Sont-ils disposés à travailler au-delà du travail de base, en fournissant (par exemple) des articles savants, des présentations à des conférences, des brevets et d'autres activités visant à «faire honneur à l'entreprise»? Et peuvent-ils montrer qu'ils peuvent faire tout cela?

Je peux résumer cela avec un commentaire que j'ai fait aux recruteurs de Philips Semiconductor il y a longtemps (en tant qu'employé). Je peux apprendre à un enfant de 10 ans à relier les points lorsqu'il s'agit de conception microélectronique. Leur apprendre POURQUOI vous reliez ces points est une autre affaire. Par conséquent, vous ne pouvez pas juger un nouvel employé sur la façon dont il relie les points. Vous devez trouver des moyens de découvrir à quel point ils savent pourquoi ils font ce qu'ils font. C'est là que le travail d'équipe et les activités parascolaires entrent en jeu. Ils montrent une profonde compréhension.

Le problème fondamental ici est que vous n'utilisez pas correctement les problèmes de codage comme technique d'interview. Il semble que votre technique d'entretien ressemble à ceci:

• Poser un problème
• Le candidat a-t-il réussi à résoudre le problème? LOUER. Sinon, PAS DE LOCATION

Cette technique d'entretien est, comme vous l'avez découvert, (1) très facile à «jouer» par les candidats, et (2) vous donne un signal de mauvaise qualité "sur leurs capacités réelles qui sont pertinentes pour le poste.

Voici comment je donne un entretien avec un problème de codage:

• Posez un problème. Le problème doit être un problème qui pourrait être facilement résolu par n'importe qui dans ce poste, il doit être pertinent pour le poste, et il ne doit pas dépendre de "culture spécifique" connaissance. En particulier, cela ne doit pas nécessiter un aperçu "aha-moment" .

Par exemple, lors d'un entretien pour un poste où le candidat rédigerait une bibliothèque standard pour un langage de programmation, je demanderais comment implémenter l'une des méthodes les plus simples de cette bibliothèque. Lorsque le poste conçoit des outils qui détectent les défauts, je mets du code légal mais bogué et je demande au candidat de trouver des défauts et de décrire pourquoi ils sont des défauts et quelle en est la gravité. Lorsque la position implique la manipulation d'arbres d'analyse dans un compilateur, je poserais des questions sur l'extraction de faits sur les arbres, par exemple si une propriété d'équilibre est violée. Et ainsi de suite.

• Assurez-vous que le candidat comprend le problème en travaillant quelques exemples simples.

Ces exemples simples sont des cas de test ; le candidat doit le reconnaître lorsqu'il est temps pour lui de justifier sa solution.

• Donnez au candidat l'occasion de poser des questions de clarification.

Ceci est particulièrement important si le problème est sous-spécifié. "Devons-nous prendre en compte l'heure d'été dans ce calcul de date?" "Savons-nous avec certitude que l'arithmétique des nombres entiers est un complément à deux 32 bits?" "L'arbre est-il suffisamment peu profond pour que nous puissions écrire un algorithme non récursif à la queue?" et ainsi de suite.

C'est un signal précieux sur la capacité du candidat à analyser un problème, à communiquer à son sujet et à résoudre une situation ambiguë. Ce sont toutes des compétences professionnelles précieuses. Utilisez ce signal .

• Une fois que le candidat peut commencer à résoudre le problème, comment commence-t-il? Utilisent-ils le style "piloté par les tests", où ils écrivent d'abord certains cas de test? Ecrivent-ils un en-tête de fonction clair qui décrit les entrées et sorties souhaitées? Respectent-ils les pratiques standard de dénomination? S'il utilise un langage OO, le candidat suit-il de bons principes de conception OO? En bref, peuvent-ils utiliser efficacement l'abstraction de la fonction?

• Si la fonction a des cas d'erreur qui ne sont pas détectés par le système de types, le candidat utiliser des contrôles de validité, des affirmations ou toute autre technique pour s'assurer que les conditions préalables sont remplies?

• Existe-t-il des cas "faciles à résoudre" qui peuvent être traités après des vérifications d'erreurs? Le candidat écrit-il du code pour les sorties faciles? Peuvent-ils décrire pourquoi ils ont fait ce choix? Les cas faciles à résoudre nous offrent un compromis entre la complexité du code et les performances; dans quelles circonstances ce compromis est-il justifié?

• Une fois que la méthode entière est écrite, la méthode écrite est-elle une implémentation valide et correcte de la spécification? Le candidat peut-il vous en convaincre ? Si le code n'est pas correct, essaient-ils de vous convaincre qu'il est correct? Peuvent-ils utiliser des cas de test dont ils disposent déjà pour prouver leur exactitude? Peuvent-ils proposer de nouveaux cas de test? Existe-t-il des affirmations qui vérifient les postconditions? Travaillez avec le candidat jusqu'à ce que vous soyez tous les deux convaincus que le code est correct parce qu'il est correct.

• Nous avons maintenant une implémentation correcte. Nous ne sommes même pas encore près d'avoir terminé . Le problème aurait dû être si simple que trouver une mise en œuvre correcte ne prend pas en compte la totalité de l'entretien. Question suivante: analysez les caractéristiques de performance de l'algorithme que vous venez d'écrire. Quelles ressources le candidat identifie-t-il? Comprennent-ils que les performances concernent les besoins des utilisateurs et non la vitesse brute? Peuvent-ils faire des compromis entre l'espace et le temps? Comprennent-ils les performances amorties par rapport aux performances les plus défavorables? Comprennent-ils le débit par rapport au temps jusqu'au premier résultat? Peuvent-ils vous décrire des effets exogènes sur les performances comme la pression de collecte dans les langages gc'd? Peuvent-ils donner correctement l'ordre asymptotique? Quelles modifications peuvent-ils apporter au code pour ajuster ses performances?

• Nous voyons maintenant à quel point la boîte à outils du candidat est profonde. Modifiez l'énoncé du problème pour le rendre plus difficile. "Et si ces deux dates pouvaient être dans des fuseaux horaires différents?" "Et si nous exécutions ce code sur une machine où les pointeurs pourraient être de tailles différentes?" "Et si nous savions que l'arbre était susceptible d'être fortement déséquilibré à gauche et que nous ne pourrions pas faire de récursion à gauche?" "Et si nous sommes dans un environnement à mémoire limitée et que nous ne pouvons pas allouer arbitrairement de nombreux objets?" etc. Toutes ces situations sont des situations que j'ai rencontrées au travail. Prenez des exemples de situations réelles auxquelles vous avez dû faire face . Obtenez un bon signal de la façon dont le candidat les traite.

En bref , Peu m'importe si le candidat a déjà vu mon problème car résoudre le problème est la chose la moins intéressante qu'il va faire pendant l'entretien . Je ne recherche pas la possibilité de produire une solution standard à un problème standard; Je suppose que je vais l'obtenir, et si je ne le fais pas, c'est un simple "pas d'embauche". Je recherche une capacité à concevoir, spécifier, clarifier, implémenter, tester, justifier, analyser et étendre des solutions

Essais payants temporaires.

Bienvenue nouvel utilisateur, j'en suis venu à croire que le seul moyen de trouver des ingénieurs en logiciel est, une fois que vous avez trouvé quelqu'un qui semble savoir de quoi il parle dans la technologie spécifique à portée de main,

• Payez-les simplement pour un contrat indépendant d'une ou deux semaines. En fait, demandez-leur de se lancer et de réaliser un vrai projet sur votre produit réel avec la vraie équipe.

Cela devient de plus en plus courant.

Je pense que c'est tout.

C'est la seule façon de savoir.

Tout le reste est inutile, comme le souligne le PO.

Le temps / argent que vous consacrerez aux diverses alternatives ... pourrait aussi bien les mettre sur le projet pendant une semaine.

(Selon votre style et votre projet, vous pourriez les conserver pour une période de temps (une semaine) ou une "tâche" pour $ x. Dans les deux cas.)

Si vous adoptez systématiquement cette approche, vous découvrirez après un an ou deux que, l'argent que vous avez gaspillé cette approche était en effet bien moindre que les autres coûts de recherche et d'embauche.

"Parce que je suis franchement fatigué d'embaucher des développeurs de logiciels prometteurs qui répondent parfaitement à chaque question dans les questions d'entretien d'embauche, et alors quand vous les voyez réellement coder dans une situation réelle, vous réalisez à quel point ils en savent peu. "

Essais payants temporaires.

Quelques réflexions supplémentaires , la teneur de ce contrôle qualité est

• Pour les ingénieurs logiciels, les processus de recrutement échouent - en fait, ils sont souvent «sans espoir». (L'un des sommets, et celui suscité par la frustration de l'OP, est que les programmeurs pleins d'espoir ne font plus que «jouer» la phase des «questions techniques» des choses.)

• Notez que même «google- style «processus de recrutement absurdement détaillés / étendus ............ échouent souvent complètement. Les programmeurs (en particulier) "ne fonctionnent tout simplement pas", peu importe comment la prudence des processus de recrutement.

• Par tous les moyens, quel que soit le secteur ou le mode d'occupation, les gens «ne réussissent parfois pas» même après un recrutement minutieux. Cependant, c'est surtout un problème pour les ingénieurs en logiciel - c'est notoire .

{Vous vous demandez peut-être pourquoi? Comment se fait-il que ce soit particulièrement un problème avec les programmeurs? Je sais précisément pourquoi, et certaines personnes ont leurs propres théories à ce sujet, mais pas besoin de commencer un autre argument!}

Encore plus de pensées!

Cette réponse contient un gros tas de votes négatifs et un gros tas de votes positifs.

Apparemment

• pour beaucoup de gens c'est un idée totalement évidente

• mais pour d’autres, c’est un truc bizarre et fou .

Après tout, mis de côté la programmation en soi, dans les années 90, l'une des clés du succès fulgurant de General Electric à l'époque était le plan de Jack Welch où chaque manager licenciait simplement les 10 derniers % de personnes chaque année! (Son livre est formidable BTW.)

Et je grince des dents pour taper l'expression "l'économie des concerts", mais dans "l'économie des concerts", nous sommes tous "à l'essai" - de jour en jour et pour toujours .

Le vannage des programmeurs est incroyablement, notoirement, difficile.

Utilisez des entretiens sur le tableau blanc et posez des problèmes liés aux compétences et au domaine d'activité qui vous intéressent. Recherchez des personnes avec lesquelles vous pouvez travailler, même si elles ne correspondent pas parfaitement au poste, car vous pouvez formez toujours la bonne personne si elle a du potentiel. Demandez aux employés existants des recommandations (et offrez des frais de recherche)

Après avoir répondu à suffisamment de questions de base pour montrer qu'ils ont une capacité minimale (selon mes besoins) à écrire du code, je passe à la partie la plus difficile de l'entretien, basée sur deux domaines, leur travail et mon travail.

Demandez des informations sur un projet récent pour leur travail actuel. Même en ce qui concerne les NDA et les restrictions IP, ils devraient être en mesure d'expliquer le problème commercial, la complexité des problèmes et la façon dont ils les ont surmontés. S'ils ne peuvent pas m'expliquer leur propre travail afin que je puisse comprendre et évaluer, alors je m'inquiète de leur succès.

Demandez-leur de mettre sur un tableau blanc une conception / solution à l'un de vos problèmes. L'attente ne doit pas être une solution de travail mais la façon dont ils abordent le problème. Fournissez suffisamment d'informations pour qu'ils aient une portée de haut niveau pour le problème. Ils devraient poser de bonnes questions et vous devriez fournir de bonnes réponses pour qu'ils puissent continuer. Ils devraient pouvoir esquisser une sorte de solution. En fin de compte, leur solution peut ne pas fonctionner, mais vous pourrez voir comment ils travaillent sur un problème et s'ils devraient ou non être en mesure de travailler sur les projets que vous aurez.

Simplement. Il vous suffit de griller les candidats sur les détails de la mise en œuvre et de modifier leurs exigences pour voir comment ils répondent. Faites-leur utiliser ce qu'ils ont mémorisé comme éléments de base.

Pour être franc, la mémorisation des problèmes n'est pas un problème. La mémorisation est en fait l'une des techniques clés utilisées par les joueurs d'échecs pour apprendre le jeu. En mémorisant des algorithmes, vos candidats développent une bibliothèque de solutions à partir desquelles travailler. Cela signifie qu'ils pourront mieux résoudre les problèmes à l'avenir, si les modèles et la mise en œuvre des modèles qu'ils apprennent sont réellement utiles.

Ce que vous devez tester, c'est cette dernière partie. En variant le problème en temps réel, vous voyez à quel point le candidat comprend réellement comment utiliser ce qu'il a mémorisé. Cela signifie que vous pouvez leur demander de meilleures façons de résoudre la question et vous pouvez même leur demander de composer leur solution dans un flux de travail pour faire quelque chose de complètement différent.

Ce que vous voulez, c'est quelqu'un qui peut résoudre les problèmes. Ce que vous ne voulez pas, c'est quelqu'un qui résout les problèmes comme vous voulez les voir résolus. Si tout le monde mémorise des solutions, il ne vous reste plus qu'à tester sa capacité à utiliser ce qu'il a mémorisé. En fin de compte, chacun utilise ce qu'il sait pour décomposer ce qu'il ne sait pas. Si vos développeurs peuvent utiliser des modèles qu'ils maîtrisent déjà pour résoudre des problèmes de complexité croissante, ils auraient pu inverser une liste chaînée s'ils n'avaient jamais vu personne le faire auparavant.

En tant que recruteur, c'est tout ce que vous pouvez raisonnablement attendre sans essayer d'obtenir de la main-d'œuvre gratuite de vos candidats.

À certains égards, étudier pour l'entrevue est une bonne chose. Vous demandez probablement déjà que les gens étudient environ quatre ans dans une université pour se préparer à l'entrevue.

Maintenant, si votre processus d'entrevue est scénarisé et que le script manque de toute variante, alors c'est juste une question de temps avant que les réponses ne soient mémorisées dans la population. Les solutions incluent:

1. En tant que questions qui sont générées, avec des champs variables qui nécessitent le travail à faire spécifique à cette pose de la question.
2. Changer l'ensemble de questions à partir du temps à temps, pour minimiser le temps nécessaire pour créer le pool de réponses.
3. Changez l'approche entière, en leur donnant un projet trivial avec des bogues spécifiquement ajoutés, en leur demandant de le corriger et d'ajouter une fonctionnalité connue.

Aussi, considérez le problème au sens large, si vous demandez des informations lors d'un entretien et que les informations ont été mémorisées, alors ce devrait être un candidat idéal, sauf si vous demandez les mauvaises informations .

Vous décidez que les informations ne sont pas ce que vous voulez, vous pourrez donc peut-être résoudre le problème en demandant le bon type d'informations.

Être capable de trouver une solution sur place n'est pas vraiment une excellente qualification non plus, du moins à mon humble avis. J'ai certainement mis au point de nombreuses solutions sur place qui, rétrospectivement, n'étaient pas si bonnes, et j'ai parfois passé des semaines ou des mois à trouver une solution décente à un problème vraiment difficile. (Et parfois, la solution consiste simplement à se souvenir que j'ai vu quelque chose de similaire dans un exemple de code quelque part ...)

Vous ne dites pas si vous essayez d'embaucher de nouveaux diplômés ou des développeurs expérimentés, mais dans l'un ou l'autre cas je pense que vous devez vraiment trouver un moyen de regarder ce qu'ils ont fait auparavant. Parfois, il regarde des articles publiés (même si la personne n'est pas l'auteur principal), parfois c'est une recommandation personnelle, parfois simplement en leur demandant de vous montrer quelque chose qu'ils ont fait et dont ils sont fiers. FWIW, je ne pense pas avoir jamais obtenu un emploi pour lequel j'ai interviewé qui ne comportait pas au moins une de ces choses.

Je pense que vous comprenez mal la raison pour laquelle les grandes entreprises posent des questions sur les algorithmes. L'écriture de l'algorithme pour le tri rapide n'est probablement pas une compétence très utile pour la majorité des développeurs. De même, trouver la meilleure façon d'analyser une chaîne de 1 million de caractères n'est pas quelque chose que les gens font régulièrement au travail. Cependant, savoir comment résoudre ces problèmes est un excellent moyen de filtrer les candidats stupides. Si quelqu'un est trop stupide pour le travail, il ne sera pas en mesure de répondre de manière cohérente à l'une des énigmes d'entrevue fréquemment posées lors des entretiens d'embauche. Même s'ils mémorisent toutes les réponses, vous pouvez facilement briser leur schéma en posant une variante légèrement différente de la question ou en ajoutant une question bonus sur place. En revanche, un bon candidat n'aurait aucun problème à se préparer au «test» et réussirait avec brio.

L'entretien consiste à filtrer les mauvais candidats, plutôt qu'à trouver les meilleurs candidats en soi. Il n'y a aucun mal à demander à quelqu'un de se préparer à l'avance, car cela n'aiderait pas quelqu'un qui n'est pas prêt à travailler au bon niveau.

Le problème est que vous ne testez pas les compétences que vous recherchez.

Un processus que j'ai utilisé à la fois comme intervieweur et interviewé qui a bien fonctionné:

La plupart des réponses (actuellement) les mieux notées à cette question suggèrent une sorte de codage en direct dans le cadre de l'interview. Je déconseillerais fortement cela car ce n'est pas du tout représentatif d'un scénario réel. C'est une situation sous haute pression et non naturelle où un candidat est susceptible de produire une solution inférieure à ce qu'il ferait autrement, sans avantage supplémentaire.

En tant que candidat, j'ai remarqué certaines choses qui peuvent encore être testées lors d'un entretien, même si vous n'êtes pas vous-même dans le domaine informatique:

• Questions basées sur le comportement

L'objectif n'est pas de clouer la personne que vous avez devant vous, mais de voir quel genre de personne elle pourrait être. Cela donne une brève fenêtre de savoir si elles pourraient ou non être adaptées pour travailler dans l'entreprise.

• Questions sur l'expérience passée

[Pourriez-vous] me parler d'une situation où ...

Pour celui-ci, l'objectif est d'inviter la personne à vous en dire plus sur son expérience dans une situation précise. Ce type de question permet d'affirmer leurs compétences ainsi que leur être.

Cela peut être utile si vous savez que les équipes informatiques ont des situations qui peuvent être difficiles à gérer (devoir gérer beaucoup de tâches dans un court délai, avoir à gérer des clients fatigués, etc.).

• Question basée sur la résolution de problèmes

Vous avez mentionné que vous cherchiez un solutionneur de problèmes.

Une fois, j'ai eu une interview avec une entreprise où les intervieweurs n'ont posé aucune question basée sur la programmation. Afin d'affirmer mes compétences en résolution de problèmes, ils m'ont plutôt parlé d'une situation et on m'a dit de réfléchir à voix haute pour qu'ils puissent être témoins de mes compétences en résolution de problèmes en action. Par exemple:

Nous avons un avion de 50 sièges et 50 passagers en attente de rentrer. Les deux premiers passagers ont perdu leur carte, ils vont donc s'asseoir sur un siège au hasard. Le prochain passager s'assiéra à son siège s'il le peut (s'il n'est pas déjà occupé); sinon, ils s'asseoiront dans un siège aléatoire. Quelle est la probabilité pour le dernier passager de s'asseoir à son propre siège?

L'objectif n'est pas pour eux de trouver la solution, mais de vous montrer comment ils abordent le problème.

~~~~~~~~~~

Pour chacune de ces questions, n'oubliez pas de prendre note de la réponse du candidat. De cette façon, vous pouvez mieux en discuter avec le responsable du service informatique.

Je ne pense pas que vous ayez besoin de changer les questions, mais comment et ce que vous demandez.

C'est arrivé au point où vous ne pouvez pratiquement pas poser de question sans le candidat ayant déjà pré-étudié au moins une version de cette même tâche et sait donc, en gros, quelle est la solution.

Ce n'est pas une chose à somme nulle, vous pouvez vous nourrir de la solution pour un entretien complet seul si vous le souhaitez, et obtenez une compréhension approfondie des compétences de la personne interrogée (en supposant que vous avez vos propres compétences techniques).

Vous présentez la question, la personne interrogée crée une solution (peut-être du code, peut-être un tableau blanc). Voici le début:

• Expliquez-moi comment cela fonctionne
• Quels facteurs vous ont amené à choisir cette solution?
• Existe-t-il d'autres moyens de le faire?
• Pourquoi votre solution est-elle meilleure que les autres?
• Y a-t-il des avantages potentiels dans les autres solutions qui manquent à votre solution? Quels scénarios cela pourrait-il s'appliquer?
• Ayant juste écrit ceci de la manchette, les refactorisations que vous aimeriez faire maintenant que vous l'avez examiné?
• Si vous ne l'avez pas fait ce test piloté, quels tests chercheriez-vous à écrire / faire pour vous assurer que c'est correct?
• Avez-vous remarqué des bogues?
• Pensez-vous que le code est de qualité de production? Un autre développeur pourrait-il le soutenir / le refactoriser sans transfert de connaissances de votre part? Que devriez-vous changer pour vous assurer que son intention est bien comprise?

Quelqu'un qui a mémorisé un algorithme ou un modèle sans le comprendre ne pourra pas approfondir les détails, mais un bon développeur devrait être en mesure d'avoir des discussions sur ces sujets, même si leur solution brute n'était pas parfaite (et voir quelqu'un découvrir une meilleure solution tout en vous parlant et être prêt à l'appeler montre une maturité dans les revues de code / conception et le refactoring qui sont très souhaitable).

La meilleure interview que j'ai jamais donnée a été l'une des interviews les plus simples que j'ai données et a également été la meilleure que mes compétences aient jamais été mesurées. Voici ce qu'étaient ses 5 tours:

1. Téléphonique avec le recruteur: qui m'a demandé d'expliquer verbalement la réponse à un simple problème de codage. (Le recruteur n'était pas technique.) Lui répondre a démontré que je peux expliquer ma solution à des personnes non techniques, prouvant qu'il existe un réel lien entre les compétences mentionnées sur mon CV et l'aspect pratique.

2. Sur site 1: Un des développeurs senior de l'entreprise m'a fait une démonstration de son produit. Il a prêté attention aux questions que je posais pendant et après avoir connu leur produit. Cela les a aidés à évaluer avec précision mon intérêt pour ce domaine et à déterminer si j'étais vraiment curieux.

3. Sur place 2: Un responsable technique de l'entreprise a apporté un de leurs propres morceaux de code et m'a demandé ce que j'en pensais. Le code avait des problèmes de base - comme ne pas utiliser try-catch, ne pas fermer les ressources, classes et variables mal nommées, etc. Le code fonctionnait, mais n'était pas écrit de manière responsable. Les corrections que j'ai suggérées ont démontré mes compétences en conception. Si l'on n'est pas un programmeur responsable, cet entretien finirait par être le plus difficile. Surtout pour les agresseurs de solutions.

4. Sur le site 3: Un développeur senior a discuté avec moi de la conception de Merge Sort et, une fois que la conception correcte a été atteinte, a demandé moi pour le mettre en œuvre dans la langue de mon choix. La discussion sur la conception a été relaxante car j'étais sûr que lui et moi étions sur la même longueur d'onde sur ce que nous allions mettre en œuvre.

5. Sur site 4: Un autre développeur senior m'a demandé de lui expliquer l'un de mes propres projets. Cela a démontré que je comprenais réellement les choses qui se faisaient dans mon travail actuel au lieu de faire des correctifs de code à court terme et absurdes.

Toutes les rondes étaient très pertinentes et je n'ai jamais eu le sentiment qu'on me demandait de faire quelque chose à l'improviste, spécialement pour cette interview. Chaque tâche mesurait à quel point j'étais un développeur de logiciels, plutôt que le nombre de réponses que j'avais mémorisées.

Sans surprise, cette entreprise était très bien notée sur Glassdoor et avait une très faible attrition. Les employés n'écrivaient pas beaucoup sur ce qu'ils faisaient mais ils étaient tous vraiment investis dans leur entreprise et leur travail.

Dans mon travail, la bonne solution aux problèmes difficiles est venue après discussion entre coéquipiers . C'est ce qu'une bonne interview essaierait de simuler. Le simple fait de poser des problèmes difficiles lors d'un entretien n'est généralement pas utile.

Un certain nombre de personnes ont répondu "Les questions ne correspondent pas aux besoins du travail" - et que la solution consiste à changer les questions en quelque chose qui reflète plus précisément ce qui est nécessaire pour savoir comment faire le travail.

Je vais prendre un angle différent: Cela a probablement beaucoup à voir avec les recruteurs / intervieweurs qui ne prennent pas le temps de créer leurs propres questions.

Dans notre groupe, nous interviewons actuellement des développeurs .NET, et voici quelques-unes des questions de notre processus d'interview:

• Nous avons ces deux tables SQL avec ces colonnes. Écrivez une requête qui rassemble les données X, en filtrant vers le bas en fonction de Y, avec un cas d'angle de Z traité d'une manière spécifique.
• Voici une fonction C # de 8 lignes mal écrite; Vérifiez le code.
• Ecrivez une fonction C # qui prend une entrée d'un nom de fichier et affiche le nombre d'octets avant le premier octet nul dans ce fichier.

Les réponses à ces questions ne se trouveront probablement pas dans «140 questions à mémoriser avant une interview» - parce que nous avons proposé les questions à partir de zéro. Nous ne les avons pas copiés à partir d'une autre entreprise, ni ne les avons stockés sur un site «Good Interview Questions». Oui, cela demande plus de travail ... mais nous n'avons pas à nous soucier du fait que quelqu'un a déjà la réponse mémorisée.

Si vos candidats réussissent vos entretiens en étudiant, n'est-ce pas une indication forte de leur capacité à étudier et à apprendre? Si vous embauchez de nouveaux diplômés, c'est vraiment la compétence la plus précieuse pour laquelle embaucher.

Si un candidat expérimenté le fait, cela signifie au minimum qu'il est très motivé pour étudier pour votre entretien. Ce qui signifie qu'ils sont très intéressés à venir travailler pour votre entreprise. Et aussi, c'est un signal fort qu'ils n'ont pas perdu leur capacité à apprendre et à travailler après avoir quitté l'université. Vous devriez toujours leur poser des questions sur leur expérience de travail, leurs réalisations et leurs collaborations avec des collègues pour avoir une meilleure idée de leur capacité globale.

Ce sont des solutions de problèmes que nous voulons, pas des problèmes- mémorisateurs.

Très peu de gens peuvent proposer un tri rapide, ou l'algorithme de détection de cycle de Floyd, ou trouver la sous-séquence croissante la plus longue dans la durée d'un entretien sans avoir jamais étudié la solution. Il est peu probable que ceux qui le peuvent passer des entretiens dans votre entreprise pour des emplois de développement réguliers. Sans vouloir vous offenser, je suis sûr que c'est une excellente entreprise, mais statistiquement, la plupart de vos candidats ne seront pas de ce calibre - car très peu de programmeurs dans le monde le sont.

D'un autre côté, si votre les candidats sont capables d’appliquer des solutions à des problèmes qu’ils ont déjà rencontrés, à des variantes de ce problème ou à des problèmes connexes, c’est un signe qu’ils sont bons pour faire correspondre les modèles et identifier le type de problème qu’ils re regardant. À l'inverse, s'ils n'ont jamais vu ce type de problème avant, vous avez également un signal indiquant qu'ils savent comment rechercher une solution et la comprendre - car après tout, ils ont étudié et réussi votre entretien.

J'ai dû recruter 5 développeurs de niveaux de compétences différents au cours de l'année écoulée et ce n'a pas été un processus facile. La meilleure méthode que nous avons trouvée était d'utiliser des tests de programmation en ligne pour filtrer les candidats les plus faibles avant notre entretien.

Nous avons choisi un site Web de test de codage (CodinGame, bien que d'autres alternatives soient disponibles) et avons demandé aux candidats de s'asseoir un test avant de les interviewer.

Pour:

• Nous avons filtré les candidats «qui ont l'air bien sur papier» qui ne sont pas à la hauteur de leur CV. li>
• Nous a permis de voir le travail du candidat - nous avons offert des entretiens à des personnes qui n'avaient pas obtenu de bons résultats au test, mais en examinant ce qu'elles avaient fait pour résoudre le problème, nous avons eu une bonne idée de leurs capacités d'analyse.
• Nous avons considéré que les candidats qui n'étaient pas assez sérieux au sujet du poste pour faire un test en ligne de 50 minutes ne valaient pas la peine d'être interviewés, cela les a filtrés.
• Nous avons pu définir des tests à différents niveaux de compétence.

Cons :

• Certains candidats, confrontés à plusieurs entretiens, opteraient pour le chemin de moindre résistance et choisiraient ceux qui n'impliquaient pas une test de codage.
• Vous avez besoin de quelques candidats pour passer le test afin d'obtenir une évaluation de ce qu'est un score décent.
• Il y a un coût à payer pour passer le test.

Flip it: faites-en un test pour les joueurs. Choisissez ceux qui échouent ...

Chaque fois que vous avez une métrique qui est intensément jouée , la métrique devient inutile.

Mais c'est pire. D'excellentes performances sur la métrique deviennent un drapeau pour un joueur .

Et cela le rend meilleur :)

Alors vous le retournez. Vous optimisez ces tests pour identifier les personnes qui ont appris à bien tester. Ne rendez pas vos tests résistants aux joueurs - rendez-les encore plus vulnérables aux joueurs, de sorte que les joueurs s'en tireront extrêmement bien, et les personnes qui ne se sont pas "entraînées sur les livres d'interview" ne le feront pas. Incluez également d'autres entretiens ou tests auxquels les livres de formation aux entretiens ne peuvent pas vous préparer.

Vous allez maintenant voir un motif / signal . Vous verrez des candidats qui obtiennent de très bons résultats au test du joueur, mais qui patinent sur vos autres choses. Ce sont des joueurs, ne les embauchez pas. À l'inverse, vous voyez des candidats qui affichent un score relativement médiocre dans le test de joueur, par exemple dans le 25-50e centile par rapport aux autres candidats. ils ne sont pas incompétents, ils sont juste battus par les joueurs ... et ils s'en sortent très bien sur les autres choses. Engagez-les.

Vous dites

"Maintenant, ce ne serait bien sûr pas un problème si la connaissance de ces problèmes est ce que nous recherchons ... sauf que ce n'est pas ce que nous recherchons pour. "..." Ce sont des résolveurs de problèmes que nous voulons, pas des mémorisateurs de problèmes. " .

Vous venez de répondre à votre propre question. Si vous souhaitez tester leurs compétences en résolution de problèmes, demandez-leur simplement d'expliquer leurs projets précédents et de travailler en détail. Posez-leur des questions comme pourquoi ils ont choisi une plate-forme / un langage de programmation particulier. Demandez-leur quelles étaient les exigences et comment elles ont été mises en œuvre, etc. Des questions comme celles-ci vous donneront une idée de la complexité que le candidat a gérée auparavant. Certains ont suggéré de leur poser de réels problèmes de débogage pendant l'entretien. Bien que ce soit une bonne approche, cela peut prendre du temps. De plus, chaque bogue est différent et même les grands programmeurs ont du mal s'ils ne connaissent pas l'histoire du code.Je pense que vous pouvez avoir un mélange des trois approches, c'est-à-dire des questions de manuel + projets précédents + bogues réels.

Au lieu de poser des questions spécifiques pré-préparées, demandez au candidat d'apporter des échantillons de son travail. Pour les diplômés qui pourraient être des choses qu'ils ont faites dans leur cours ou comme passe-temps.

Vous pouvez ensuite en discuter avec eux, leur demander d'expliquer ce que cela fait et toutes les parties particulièrement intéressantes de celui-ci. Vous obtiendrez beaucoup plus de ce processus que vous ne poseriez simplement une question technique. Vous pouvez voir à quel point ils sont critiques de leur propre travail et comment ils pensent à la résolution de problèmes.

Cela les soulage également. Si vous leur demandez de faire des tâches de codage sous la pression du temps et avec vous, ils risquent de ne pas bien fonctionner, et c'est un environnement très artificiel et quelque chose auquel ils ne sont probablement pas habitués.

Vous pouvez utiliser cette discussion comme un Point de départ pour parler de choses plus spécifiques à l'emploi, mais l'accent avec les diplômés a tendance à être sur la capacité de penser et d'apprendre.