Quelle aide devrais-je donner lors des entretiens techniques? [fermé]

On me demande de jouer ou d'assister à de nombreux entretiens techniques. Nous posons des questions de logique et des problèmes de programmation simples que l’enquêté doit pouvoir résoudre sur papier. (Je préférerais qu’ils aient accès à un clavier, mais c’est un problème pour une autre fois.) Parfois, j’ai l’impression que les gens savent comment aborder un problème, mais ils sont suspendus à la nervosité ou à une question de second choix ( ils ne sont pas destinés à être des questions pièges).

Je n'ai jamais entendu mon patron donner de l'aide ou des allusions. Il remercie simplement la personne interrogée pour la réponse (qu'elle soit bonne ou mauvaise) et passe à la question ou au problème suivant. Mais je sais que quelque chose à propos du terrier des lapins que la défaite et les nerfs peuvent vous mener vers le bas, et comment cela désactive votre esprit, et je ne peux pas m'empêcher de me demander si nous aiderions un jour ou l'autre à nous aider à nous retrouver avec des programmeurs plus compétents. de plusieurs interviews échouées.

Devrais-je fournir des conseils et de l'aide aux personnes interrogées confuses (et si oui, jusqu'où dois-je aller tout en restant juste pour les candidats plus préparés)?

Lorsque j'étais dans une position similaire, je disais à la personne interrogée: "Imaginez que je suis Google. Si vous devez rechercher quelque chose, dites-le simplement."

Dans une question, les personnes interrogées devaient pouvoir déterminer le volume d'un cylindre, alors cela ne me dérangeait pas que quelqu'un me dise: "Je devrai rechercher Google pour la formule du volume d'un cylindre." Je voulais savoir s'ils savaient comment résoudre le problème, pas s'ils avaient mémorisé des formules. Pour ce faire, ils devaient bien comprendre comment traduire le monde réel en logiciels, donc c'était un concept important.

D'autre part, je n'allais pas leur dire qu'ils avaient besoin de cette formule.

Vous avez raison de dire que les nerfs peuvent être un problème, mais je m'attends toujours à ce que les gens soient capables d'exprimer leur processus de pensée, même s'ils sont nerveux. Ne pas donner de réponse était inacceptable.

Vous avez deux approches qui fonctionnent à la fois pour la résolution de problèmes et les questions techniques courtes:

1. La première est utilisée par votre patron: ne fournissez aucune aide afin de tester le comportement de la personne dans un contexte stressant. C'est une approche parfaitement valable et peut donner des indications sur la personne. Après tout, une fois que vous aurez embauché cette personne, elle ne pourra plus recevoir l’aide constante de tous ses collègues.

2. La seconde consiste à fournir des conseils et un soutien. Le niveau de soutien importe peu; la seule chose qui compte, c'est que plus vous apportez d'aide à la personne, moins vous aurez à valoriser son succès.

Personnellement, je pense que vous devriez prendre suffisamment de temps pour vous assurer que la personne est incapable de résoudre elle-même un problème et lui faire sentir qu'elle est incapable de le résoudre sans aide. Mais ensuite, vous pouvez fournir une aide progressive jusqu'à ce que vous disiez à la personne la réponse elle-même.

Exemple:

- Pouvez-vous me dire comment créer des propriétés en lecture seule en C #, c'est-à-dire des propriétés avec une valeur qui ne peut être initialisée que dans un constructeur et ne peut pas être modifiée ultérieurement?
- Bien sûr. Je viens d'utiliser le mot clé readonly.
- Êtes-vous sûr? Pouvez-vous m'expliquer la différence entre une propriété et un terrain?
- Hm. Une propriété est ... vous voyez ... prenez et mettez ...
- Ok. Ainsi, un champ est une variable déclarée dans une classe ou une structure et valide dans la portée de la classe / struct, alors qu'une propriété ressemble à un champ, mais fournit également un mécanisme pour lire, écrire ou calculer une valeur. Et maintenant readonly? Est-il utilisé avec des propriétés?
- Je crois que c'est utilisé seulement pour les champs ...
- D'accord. Alors qu'en est-il des propriétés?
- Ils ne peuvent pas être lus seulement.
- Êtes-vous sûr? Qu'en est-il des propriétés qui n'ont que des accesseurs?
- Ils sont en lecture seule.
- Cela signifie-t-il que leur valeur restera toujours la même?
- Oui.
- Non, pas vraiment. Le fait que vous ayez une propriété avec un getter ne signifie pas que sa valeur ne change pas pendant la durée de vie de l'instance de la classe. Si le getter fait référence à un champ qui est incrémenté à chaque fois que vous accédez à la propriété, la valeur renvoyée augmente continuellement.
- Droite.
- Alors? Avez-vous une idée de la façon dont vous pouvez implémenter une propriété avec une valeur qui ne change jamais?
- Non.
- Vous pouvez utiliser un champ en lecture seule. Savez-vous ce qu'est un champ de support?
[...]

Donner la réponse est une bonne idée dans tous les cas. Dans plusieurs cas, la personne interrogée a commenté ma réponse d'une manière intéressante, montrant que même s'il était incapable de répondre à la question en premier lieu, il savait toujours des choses connexes.

En outre, en posant simplement une question sans aide supplémentaire, vous n’avez pas trop d’informations sur la personne, mis à part le fait qu’elle connaît ou ne connaît pas la réponse . Fournir une aide progressive peut vous permettre de voir comment la personne pense à un problème.

Il peut également montrer d'autres choses que la personne ne sait pas. Prenons l'exemple ci-dessus: si je m'arrêtais à la première réponse, je n'aurais pas su que la personne ne peut pas expliquer la différence entre un champ et une propriété ou qu'elle ne sait pas ce qu'est un champ secondaire.

Si la personne répond immédiatement, c'est bien. Si elle a besoin d'aide, il n'y a rien de mal à cela. Si vous répondez vous-même à la question, c'est un mauvais signe et nous espérons que l'interviewé sera en mesure de répondre aux autres.

J'aime toujours aider les personnes interrogées si elles sont bloquées sur quelque chose de simple (comme le nom d'un motif particulier si elles savent évidemment de quoi il s'agit) et leur permettre de dissimuler des éléments tels que les détails de l'établissement d'une connexion à une base de données. S'ils essaient de concevoir quelque chose, cependant, je ne dis pas grand chose parce que je ne veux ni les guider ni les jeter au loin s'ils pensent à autre chose que ce que je suppose qu'ils vont bien.

Je me souviens que l'intervieweur qui avait un résultat très précis en tête posait une question particulière à la résolution de problèmes, mais il n'a pas été en mesure de me la communiquer clairement. Ceci décrit la situation dans laquelle de nombreuses personnes interrogées se sont heurtées. Parfois, le regard vide n’est pas dû au fait que la personne ne résout pas bien le problème, mais au fait que la personne qui pose la question n’explique pas clairement ce qu’elle demande. Dans ce cas, l'approche de votre collègue consistant à ne rien dire et à prouver ne fait que prouver que le candidat ne pense pas comme son collègue ou qu'il ne l'est pas. Je pense que fournir une clarification de la question dans des termes différents pourrait fournir de meilleurs résultats pour toutes les personnes impliquées.

Étant donné que les programmeurs (du moins la plupart d'entre nous) ne travaillent pas en vase clos et que les entretiens sont suffisamment stressants sans limites artificielles, je serais enclin à offrir autant d'aide que le demandera ou ce dont il a besoin.

Mais tenez compte de tout lorsque vous vous prononcez sur le niveau de compétence réel du demandeur.

Quelqu'un qui cherche un poste supérieur mais qui a besoin de beaucoup d’aide sonnerait l’alarme.

Pour les "seniors", je propose des questions courtes et ouvertes et je prête plus d’attention aux questions qu’ils posent qu’à la réponse. Je trouve des personnes seniors qui écoutent, communiquent, utilisent une écoute active, clarifient, puis fournissent des solutions que je préfère.

Pour les "ingénieurs de ligne", j’ai utilisé la technique de programmation pour des tests qui consistent à donner à un candidat un ordinateur, un problème et quelques heures, puis à revenir. Dans cette situation, nous avons demandé au demandeur à l’avance quels systèmes d’exploitation et quels outils il préférait (également une partie intéressante de l’expertise d’un programmeur). Une fois leur travail terminé, nous leur avons demandé de présenter la solution et pourquoi elle était meilleure que d’autres solutions - une révision du code. Toutes les compétences que j'attends d'un ingénieur expérimenté le premier jour.

Il est important de noter que toute l’équipe d’intervieweurs avait pris un après-midi pour faire le même test, nous savions donc que le test était juste. Nous avons passé une heure à examiner l'approche de chaque personne, comme nous le ferions avec une personne interrogée, ce qui nous a donné une idée des approches différentes.

Cette deuxième technique nous a permis de découvrir certains des meilleurs programmeurs "méconnus" (curriculum vitae moche, techniques d'entrevue moche) que j'ai jamais rencontrés.

Je préfère commencer les entretiens avec une question facile à mettre en confiance pour que le candidat soit à l'aise avec le processus. Lorsque cela fonctionne, il vous permet néanmoins de recueillir le plus d'informations possible à partir de questions ultérieures, sans donner l'avantage aux candidats qui comprennent mieux le langage corporel que les informations relatives à l'emploi.

Parfois, minor hintslors de l'entretien oral, il est utile de voir dans quelle mesure le candidat comprend le (s) sujet (s). Cependant, il devrait exister no hintsdes tests standard que chaque candidat est invité à passer.

En gros, two main thingsvous voudrez peut-être connaître le candidat potentiel:

a) Caractéristiques personnelles - s'intègre-t-il bien dans votre entreprise ou votre équipe

b) Compétences techniques - a-t-il de bonnes connaissances techniques et est-il intéressé à découvrir de nouvelles choses?

Pour en savoir plus sur ces points mentionnés, vous devez engager le candidat potentiel dans une conversation. Il est également important de s’assurer que le candidat est comfortable during the interviewcapable d’obtenir une compréhension maximale de ses compétences actuelles (techniques et techniques) ainsi que de son potentiel à effectuer le travail.

En outre, les compétences en communication du candidat potentiel sont aussi importantes que ses compétences techniques et son aptitude à résoudre les problèmes.

Une partie de ce qui devrait être examiné est des compétences de communication. Si le candidat ne comprend pas bien la question, il devrait poser des questions pour clarifier. C'est une bonne chose, à mon avis. Trop souvent, de mauvaises décisions sont prises parce que certaines hypothèses sont formulées lors de la lecture du cahier des charges ou, dans ce cas, du traitement d'une question d'entretien. Le candidat peut répondre sur la base de ces hypothèses et manquer totalement le point voulu. La question peut être erronée, ou peut-être le candidat. Dans les deux cas, permettre une clarification par la communication démontre une compétence précieuse, que les employeurs devraient rechercher.

Je pense que cela dépend en fin de compte de votre personnalité en tant qu’interviewer et de ce que vous pensez être important et qui, par conséquent, évalue réellement le candidat.

Personnellement, j’apprécie la capacité pratique / pragmatique par rapport aux questions académiques / ésotériques. Je suis beaucoup plus intéressé par un candidat qui peut entrer, se rendre au travail et contribuer efficacement, de manière utile, au (x) projet (s) sur lequel (lesquels) il est embauché (e) pour travailler, au lieu de savoir à quel point sa mémoire est minutieuse.

Je vais donc en cerner un peu si le candidat est coincé sur quelque chose d'ésotérique, sur une nuance rarement utilisée ou sur un cas particulier qui pourrait être pertinent dans une question d'entretien fantasmagorique mais qui est rarement, voire jamais, pertinent dans la vie réelle. Surtout tout ce qu'ils pourraient obtenir avec quelques minutes sur Google ou avec une référence pratique sur le bureau, ou du type "règle-le et oublie-le".

Cependant, je ne les encadrerai pas dans des activités du monde réel, communes, traditionnelles, fondamentales et professionnelles. Ce sont les choses que je veux être innées pour eux.

Je pense que cela dépend de la situation de l'entretien et des questions. J'ai utilisé les deux techniques.

Pourquoi pourrais-je vouloir ne pas poser de questions de suivi? Lorsque j'essaie de connaître la réaction de la personne au stress. Nous avons interrogé des personnes pour des emplois dans des environnements très stressants et notre capacité à gérer le stress était un facteur critique dans nos évaluations. Nous avons donc posé des questions extrêmement difficiles auxquelles personne ne pouvait répondre sans stress.

Lorsque j'essaie de connaître leurs connaissances techniques, je pose des questions de suivi qui peuvent contenir des indices sur ce que je recherche. Contrairement à la pensée du responsable qui a dit que vous deviez poser à tout le monde les mêmes questions pour être juste, je pense que cela est juste tant que plusieurs conditions sont remplies. Tout le monde se pose d'abord la même question de base. Deuxièmement, vous ne devriez pas poser de questions de suivi pour aider une seule personne. Si vous avez laissé les autres patauger sans aide, vous devez tout laisser sans aide. Deuxièmement, vous devriez comparer les résultats des candidats sur la question, non seulement en termes de réponse finale, mais également en termes de difficulté à les en extraire. Ce processus traite toujours tout le monde équitablement.

Cela dépend du type de programmeur que vous voulez. Un introverti capable d’écrire 20 lignes de code sur papier aura l’air agréable pour votre patron. Un développeur de logiciels capable de travailler efficacement sur des millions de bases de code de ligne au sein d'une équipe ne produira probablement pas de très bons résultats. J'adore ce type d'entretiens en tant que candidat. Ils me disent beaucoup de choses sur la manière dont le patron traite son personnel et sur la culture de travail. Dans un cas comme celui-ci, au moment de quitter l'entretien, j'ai dit: "Merci. Permettez-nous de gagner un peu de temps. Si vous ne m'appelez pas, je ne vous appellerai pas." Quand on m'a demandé pourquoi, j'ai indiqué que je ne voulais pas travailler pour une entreprise qui me préparait à l'échec.

Votre approche est susceptible d'obtenir de meilleures sélections pour le développement de logiciels. Votre approche, vous feriez bien pour les ramasseurs d’ordures et les gars qui tiennent les sucettes Stop / Go aux travaux routiers.

Le développement de logiciels est un effort d'équipe, pas un jeu en solo / mental / non interactif. Combien de projets échouent parce que le logiciel répond à la demande et non à la demande.

J'étais récemment dans une situation similaire. Mon directeur et les ressources humaines m'ont indiqué que nous devions être tout à fait équitables envers les six personnes interrogées. J'ai donc dû poser le même ensemble de questions techniques avec une aide minimale pour voir le comportement de chaque personne interrogée. Parfois, quand ils connaissaient la réponse mais restaient coincés dans un terme technique ou quelque chose, je les aidais indirectement avec des questions qui les guidaient vers ce terme. Après la série technique, il y a eu une deuxième série d'entretiens sur les traits de personnalité et de comportement s'ils parvenaient à passer au premier tour.

Une partie de ce que vous voulez chez un employé est une personne qui peut interagir avec le reste de l'équipe. Vous avez besoin de quelqu'un avec les compétences requises, c'est vrai. Mais vous avez également besoin de quelqu'un qui sait quand ils ont besoin de demander de l'aide et qui a la connaissance de soi et les compétences sociales pour le faire. Ce dernier ensemble définira la société mieux à long terme que n'importe quel langage informatique particulier, Du-jour.

À mon avis, une entrevue est une séance d'essai de coworking, pas un test . J'essaie principalement de répondre à la question "qu'est-ce que ça fait de travailler avec cette personne?" Parfois, je prétends même avoir oublié la réponse à la question, pour que l'exercice se sente plus collaboratif.

Avez-vous déjà travaillé avec une personne avec laquelle vous ne pouviez tout simplement pas vous retrouver chaque fois que vous parliez d'un problème? Ou quelqu'un qui a posé trop de questions au lieu de se lancer et de résoudre des problèmes? Dans une interview, je m'assure surtout que la personne à qui je parle n'en fait pas partie. Il y a un élément fort de la chimie là-bas.

Au cours du processus, j'apprendrai bien sûr aussi des choses telles que "écrit-elle du code propre", "connaît-elle les concepts requis" et "peut-elle résoudre intelligemment un problème pour en arriver à une compréhension?" Le candidat sera toujours celui qui "conduit" et écrit le code. Mais en chemin, j'espère qu'elle sera plus détendue et que je verrai une version d'elle plus proche de ce que je verrais réellement au quotidien en tant que collègue.