Les entretiens techniques ont-ils tendance à être subjectifs? [fermé]

Sur la base de mon expérience dans les entretiens techniques, j'ai constaté que la plupart ont tendance à être subjectifs car l'intervieweur a déjà sa propre réponse. Même si la réponse du candidat est correcte, parce que l'intervieweur n'était pas préparé à cette réponse, le candidat n'obtient pas le poste.

Dans une interview récemment, j'ai dit quelque chose sur l'utilisation d'un algorithme d'arbre AVL pour résoudre un problème spécifique qui a été posé. L'intervieweur a répondu: "Qu'est-ce qu'un arbre AVL?". Un autre exemple concerne tout ce qui concerne la syntaxe; J'ai rencontré cela principalement dans des interviews qui nécessitent du code Ruby car il existe de nombreuses façons d'implémenter une solution à un problème donné. Les problèmes autour des conceptions orientées objet sont très courants.

Dans cette situation, la personne interrogée n'a aucun moyen de réussir. Est-ce que quelqu'un d'autre a ressenti cela ou est-ce juste moi? Si ce n'est pas seulement moi, comment pouvons-nous améliorer les entretiens techniques?

Je pense que vos propres angles morts vous conduisent à une supposition invalide quant à la raison pour laquelle vous n'obtenez pas le poste.

Il est possible de tout répondre correctement lors d'un entretien d'embauche et de ne pas obtenir le poste car vous êtes en concurrence avec d'autres personnes qui ont peut-être également tout obtenu correctement. Lorsque vous n'avez qu'un seul emploi et trois personnes que vous pensez pouvoir faire le travail, vous ne pouvez toujours en embaucher qu'un. C'est un marché difficile et beaucoup de gens expérimentés le recherchent. Vous ne savez jamais à quel point vos concurrents se sont bien comportés dans leurs interviews.

Oui, les entretiens sont subjectifs, ils recherchent des personnes qui ont non seulement des compétences techniques mais qui s'intégreront dans le groupe existant. Continuez à essayer si vous en êtes capable, vous trouverez le bon endroit et ils vous embaucheront.

Tout intervieweur qui a renvoyé un candidat simplement parce qu'il n'a pas fourni la réponse attendue est un mauvais intervieweur. Si une entreprise encourage cela et que je ressens ce sentiment lors d'une entrevue, c'est un grave signal d'alarme à propos de l'équipe et de l'entreprise qui m'interviewent.

Si une personne interrogée m'a fourni une réponse à laquelle je n'avais pas pensé, je m'attendrais à ce qu'il soit en mesure d'expliquer la solution utilisée et ses avantages / inconvénients. Comme vous l'avez dit, il existe souvent plusieurs solutions, allant du choix d'un algorithme aux structures syntaxiques utilisées, et presque toujours des compromis sont impliqués. Je sonderais même la personne interrogée pour trouver des solutions alternatives pour voir si elles peuvent trouver d'autres, surtout si c'est une solution évidente, et demander les avantages / inconvénients de chacune.

Quelle que soit la manière dont vous menez l'entretien, cela va être subjectif. Chaque intervieweur, en tant que personne, aura des préjugés. En tant que personne interrogée, vous pouvez simplement faire de votre mieux, être minutieux (mais pas trop verbeux) lorsque vous répondez à des questions, et expliquer vos réponses et comment vous y êtes arrivé. Cela vous prendra un long chemin.

Un que j'ai trouvé récemment, c'est quand j'ai dit quelque chose sur l'utilisation d'un algorithme d'arbre AVL pour résoudre un problème spécifique qui a été posé. L'intervieweur m'a demandé en retour: "Qu'est-ce qu'un arbre AVL?".

En tant qu'intervieweur, je demanderais cela aussi, même si je savais tout sur les arbres AVL (je ne sais pas), pour savoir ce que le candidat sait. Faire semblant d'ignorance peut être une astuce pour voir si le candidat peut bien expliquer. Mais évidemment, si vous trouvez un algorithme / une structure de données qui résout le problème, que je ne connais pas et que vous pouvez expliquer correctement, je vous embaucherais. Sinon, honte à moi. Ne pas embaucher des gens parce qu'ils sont plus intelligents que vous n'est pas une bonne stratégie d'embauche.

Mais d'une manière générale: oui, les entretiens techniques sont toujours subjectifs. Et ils doivent l'être. Si vous allez passer 8 heures + tous les jours avec une personne, il ne serait pas raisonnable de choisir quelqu'un qui parvient à vous rendre fou dans une interview de 60 minutes.

Trivia Les questions sont anti-modèles aux entretiens. Si vous vous retrouvez coincé dans une telle interview, essayez de les renvoyer à ce que vous savez. Concentrez-vous sur votre CV. Si cela ne fonctionne pas ... pensez à chercher ailleurs.

Les enquêteurs doivent poser des questions ouvertes concernant votre CV. Bien qu'il soit possible d'avoir une idée des compétences de communication d'une personne, il est difficile d'évaluer les capacités de développement d'une personne en posant simplement des questions. C'est en partie pourquoi tant de gens (y compris Joel sur le logiciel) recommandent, pas besoin que les personnes interrogées écrivent du code (et sautent à travers plusieurs autres cerceaux d'ailleurs).

Le fait demeure que le développement de logiciels consiste toujours principalement à résoudre un ensemble inconnu de problèmes dans un laps de temps inconnu. Il n'y a aucun ensemble de tests qui prouvent, ok ce type peut construire "un pont". Nous réussissons mieux à transformer la création de logiciels en un processus d'ingénierie plus défini, mais nous n'en sommes pas encore là.

Les "vraies" interviews techniques que j'ai eues étaient toutes du genre: "Voici le problème, utilisez ces technologies, vous avez 3 heures". Après cela, nous avons examiné le code et expliqué pourquoi j'ai fait ce que j'ai fait. De cette façon, il a vu ce que je sais déjà et où je manque de connaissances.

Ensuite, nous avons parlé un peu des technologies et de mes objectifs en général et c'était tout. Les entretiens sont, à mon avis, conçus pour avoir une idée du candidat. Vous ne pouvez pas tout tester. Il faut beaucoup de temps pour bien connaître quelqu'un, de sorte qu'à mon avis, vous devriez vous concentrer sur les choses qui sont importantes pour votre projet et voir comment les gens gèrent ces problèmes. Le reste vient avec l'expérience au fil du temps

J'ai peur que la partie subjective ne puisse pas être supprimée, seulement diminuer. J'ai fréquemment des entretiens techniques, où l'intervieweur "pollue" l'entretien avec ses propres idées subjectives.

Un exemple simple, comme vous le mentionnez, est que l'intervieweur veut une réponse très proche de sa propre réponse. Un autre exemple est celui où un enquêteur est plus intéressé à sonder qu'il en sait plus que le candidat. Et un autre simple, c'est quand l'intervieweur veut que le candidat connaisse l'emplacement du menu spécifique pour une opération d'un IDE de programmation, (Visual Studio, Eclipse, NetBeans).

J'ai été sur plusieurs comme ça, et c'est très frustrant.

Et, bien sûr, il y a aussi la discrimination cachée, où l'intervieweur ne veut pas que le candidat soit pauvre, sexe, idées politiques, race, école, tout ce que vous voulez. Et sa recherche d'une excuse pour rejeter le candidat.

La partie la plus étrange, c'est que, étant diplômé de CS, je connais un peu de psychologie, (allait étudier cette profession), et parfois, détecte une grande partie des "interférences" subjectives. Ou, lorsque l'intervieweur se rend au bureau d'à côté et dit explicitement à ses collègues, il / elle ne veut pas embaucher un candidat, pour une raison subjective.

Il est important de considérer que de nombreuses universités ou entreprises enseignent aux informaticiens / techniciens à réaliser des entretiens d'embauche et que l'enseignement comprend à la fois les facteurs techniques et humains, et pas seulement techniques.

Voici comment je le fais:

• Je demande d'abord au candidat de résoudre un problème réaliste. Habituellement, c'est un problème que je peux résoudre facilement; généralement en beaucoup moins que le temps alloué.

• Une fois le candidat terminé; Je deviens l' étudiant . J'ai le candidat parler et pointer à travers leur solution et me montrer comment ils l'ont résolu. Je pose des questions sur leurs idées, et s'ils connaissent des solutions alternatives, et pourquoi ils ont choisi cette solution plutôt que cela.

Voici ce que je recherche.

• Ce n'est pas parce que je connais une bonne solution au problème que je recherche cette solution. Toute solution valide dans les limites des contraintes initiales est acceptable. Je suis intéressé par la façon dont ils ont planifié leur solution, comment ils ont utilisé les outils fournis. Je suis intéressé par les lacunes qu'ils sont capables d'identifier dans leurs propres solutions.

• Je m'intéresse également à la façon dont ils écoutent et communiquent. Ont-ils pu comprendre et mettre en œuvre toutes les exigences initiales? Dans quelle mesure ont-ils bien expliqué le fonctionnement de leur solution?

À la fin de tout cela, une fois que j'aurai une bonne idée de ce que le candidat apporte réellement à l'ouverture, je pourrais offrir certains des points de ma propre solution, où je pense que mes choix seraient meilleurs.

Si le candidat dit quelque chose comme "C'est une bonne idée, j'aurais aimé y penser" ou "Oh, je ne connaissais pas cette technique", ou même "j'ai pensé à ça, mais j'ai utilisé ça à la place" et fournit une raison sensée comme "Je comprends mieux cette méthode" ou "Je pensais que vous cherchiez ce type de solution", tout cela compte fortement en faveur du candidat.

S'il s'avère que le candidat a choisi différemment de moi, cela pourrait signifier que je me trompe. Ou si j'ai raison et que le candidat est suffisamment ouvert pour discuter des différences de solutions, c'est un bon signe que le candidat peut être poussé assez facilement pour faire de meilleurs choix.

Voici comment je sais qu'un candidat est un mauvais choix:

• le candidat essaie de rechercher une solution attendue de l'intervieweur.
• la solution fournie ne résout pas le problème déclaré ou enfreint d'une manière ou d'une autre certaines des contraintes énoncées d'une manière que le candidat ne peut expliquer.
• le candidat discute des contraintes pour essayer de changer le problème qu'il est censé résoudre (rappelez-vous qu'il s'agit d'un problème pour lequel j'ai une solution qui peut être mise en œuvre en beaucoup moins de temps que prévu).
• le candidat est «bloqué» et passe une grande partie du temps alloué à ne rien faire. Idéalement, un candidat attaquerait le problème sous un autre angle ou demanderait à l'intervieweur de savoir ce qu'il devrait faire lorsqu'il ne peut pas continuer.
• le candidat ne sait pas "pourquoi" il a utilisé une technique, même s'il ne connaît pas d'alternatives. Les réponses comme «Je ne connais aucun autre outil qui fait cela» ou «Je ne sais pas comment cet outil fonctionne, mais il fonctionne» sont correctes, mais «parce que je l'ai fait» sont discutables.

Pensez-vous qu'en tant que personne interrogée, votre acceptation d'un emploi n'est pas subjective, dans une certaine mesure? Le recrutement est un processus à double sens.

En tant qu'intervieweur, si mes collègues et moi «cliquons» avec un candidat, ils ont de bonnes chances d'être en lice pour le poste, en supposant que d'autres facteurs tels qu'un exercice de codage à domicile et des problèmes de tableau blanc fonctionnent bien. «Cliquer», c'est être sur ma longueur d'onde, avoir une conversation fructueuse, partager des valeurs communes sur le processus de développement. Dans quelle mesure cela peut-il être objectif?

Sur la question de l'arbre AVL, je serais intéressé à ce que le candidat explique comment il fonctionne et donne un aperçu des propriétés et de l'utilisation. Pour faire mieux que l'explication sur Wikipédia. Gardez à l'esprit que votre public peut être quelqu'un dans un environnement d'entreprise où la dernière référence à O (log n) dans une discussion technique était fondamentalement ... jamais.

En tant qu'intervieweur, je veux donner à un candidat toutes les chances de briller. J'imagine que cela s'appliquerait à toute organisation pour laquelle vous voudriez travailler.

Un bon intervieweur ne posera pas de question là où il attend une réponse spécifique, à moins que la question ne soit quelque chose de trivialement simple où il n'y a qu'une seule bonne réponse. Un bon enquêteur verra comment vous abordez un problème, comment vous y réfléchissez et comment vous arrivez à votre réponse - si votre réponse est valide, ils ne devraient pas vous en vouloir parce que vous n'avez pas fait les choses comme ils le feraient. .

On dirait que vous venez d'être soumis à des enquêteurs moche plus soucieux de montrer leur «supériorité» au candidat que d'évaluer réellement les compétences techniques.

Une compétence très importante lorsque vous travaillez en équipe est de pouvoir justifier votre propre solution et évaluer équitablement celle de quelqu'un d'autre. Vous devez être capable à la fois d'apprendre de vos collègues et de leur enseigner.

Si vous souhaitez utiliser un arbre AVL pour résoudre un problème et que les autres membres de votre équipe s'en souviennent vaguement de l'université et n'y ont pas pensé depuis, vous feriez mieux de pouvoir leur expliquer ses avantages. Si quelqu'un présente une solution que vous ne comprenez pas, vous feriez mieux de vouloir poser des questions jusqu'à ce que vous le fassiez. Si quelqu'un présente une solution clairement inférieure, vous feriez mieux de pouvoir expliquer pourquoi. Si quelqu'un présente une solution supérieure, vous feriez mieux de pouvoir reconnaître cela et de mettre votre ego de côté.

Ce sont les compétences que je recherche lorsque je pose une question technique lors d'un entretien. Qu'ils aient trouvé la bonne réponse du haut de leur tête est en grande partie hors de propos. Ce n'est important qu'à l'école.