Comment les compétences utilisées dans les questions d'entrevue typiques sont-elles appliquées dans le travail réel? [fermé]

Pour les travaux de développement d'applications SQL et C #, les enquêteurs posent généralement des questions sur les parcours d'arborescence, de graphiques et de listes liées à l'aide de C et de pointeurs purs. Au cours des 3 années que j'ai passées dans mon travail, je n'ai jamais eu à

trouver le chemin vers le 1er nœud à droite d'un nœud donné qui est un multiple du nœud donné

par exemple

Je peux voir que ces compétences peuvent être utilisées dans des emplois où vous devez écrire des compilateurs, des pilotes et travailler sur le noyau du système d'exploitation. À part ceux-là, où ces compétences sont-elles utilisées?

Lisez quelques-unes des réponses de Joel ci-dessous.

Notez en particulier quelque chose comme Schmiel le peintre. Au travail, vous n'aurez peut-être jamais à réécrire une liste chaînée, mais vous devriez certainement savoir sous le capot comment cela fonctionne, afin que vous puissiez éviter Schmiel.

Fondamentalement, si vous allez chez le médecin, vous voudriez que ce médecin ait étudié l'anatomie. Même si elle ne fait que vous prescrire un antihistaminique, un médecin aura appris à l'école de médecine que certains médicaments sont mauvais pour les personnes atteintes de «fractios diamadabada chroniques au fémur inférieur» ou autre. Ce type de connaissance approfondie de TOUT dans cette spécialité peut parfois faire la différence entre la vie et la mort, et dans les technologies de l'information entre la vie et la mort du produit ou d'un emploi.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

http://www.joelonsoftware.com/articles/fog0000000319.html

"... passez au moins un semestre à vous rapprocher de la machine ou vous ne pourrez jamais créer de code efficace dans des langages de niveau supérieur. ..."

"... vous programmez basé sur la superstition, en ce qui me concerne: un médecin qui ne connaît pas l'anatomie de base, distribuant des ordonnances basées sur ce que le vendeur de produits pharmaceutiques a dit fonctionnerait."

http://www.joelonsoftware.com/articles/CollegeAdvice.html

Ils ne sont pas. De nombreuses interviews sont réalisées par des personnes qui ne savent pas comment rechercher des développeurs compétents et qui ne savent pas quelles questions elles devraient ou ne devraient pas poser.

La plupart des enquêteurs ne posent pas du tout de questions techniques et se concentrent davantage sur des choses dénuées de sens mais mesurables , comme le nombre de projets auxquels vous avez participé (plus c'est mieux pour ces enquêteurs) ou le diplôme universitaire (plus c'est mieux pour eux ). Ils sont heureux d'embaucher une personne qui a perdu cinq ans à l'université sans rien apprendre, puis a passé dix ans à faire des dizaines de sites Web de commerce électronique, mais ils n'embaucheront pas une personne qui a abandonné l'université après quelques années et travaillait sur quelques-uns grands projets techniquement difficiles.

Poser au moins des questions théoriques est préférable à n'en poser aucune. Cela a l'avantage de vérifier que la personne a suffisamment de connaissances théoriques et n'est pas un codeur qui peut avoir quelques années d'expérience en programmation, mais ne comprend pas vraiment ce qui se passe sous le capot. Les développeurs qui n'ont pas cette connaissance théorique ¹ ne connaissent généralement pas la différence entre une liste, une liste chaînée, une recherche ou un ensemble de hachage, et les utilisent de manière interchangeable.

Bonnes questions (techniques), mauvaises questions

Lors des entretiens, vous pouvez rencontrer des questions allant de très bonnes à extrêmement mauvaises:

1. (Nocif) "Quelle est la longueur en lignes du plus long programme de travail que vous avez écrit dans cette langue?"

   Cette question est manifestement erronée. J'ai déjà expliqué pourquoi dans une autre réponse . L'entreprise où les intervieweurs posent de telles questions a de fortes chances d'évaluer la productivité des développeurs en LOC / mois. Si je dois donner un conseil: vous n'avez pas besoin d'un tel travail.

   Cet exemple est différent des choses dénuées de sens mais mesurables que j'ai citées au début de ma réponse. Ici, l'intervieweur montre également qu'il n'a même pas la compréhension la plus élémentaire des mesures en en choisissant une qui est bien connue pour être nuisible.

2. (Mauvais) "Qui est Dennis Ritchie?"

   Avoir au moins une certaine culture est en effet très utile, mais poser cette question manque le point. Si l'entreprise recherche des développeurs talentueux capables de gérer des projets de développement logiciel et d'écrire du code, le fait qu'ils ne connaissent pas le nom de la personne qui a créé C et Unix ne devrait pas trop d'importance.

3. (Bon) "Quelles sont les nouvelles fonctionnalités de .NET 4.5?"

   Cette question est beaucoup plus intéressante que celle de Dennis Ritchie. Si le candidat ne peut pas parler des nouvelles fonctionnalités de .NET 4.5, pourquoi se fait-il appeler développeur C #? Le manque de telles connaissances:

   • Montre que la personne peut ne pas être vraiment intéressée ni par le langage de programmation, ni par la communauté .NET,

   • Indique que la personne peut manquer de connaissances cruciales sur les fonctionnalités de C # /. NET que les autres développeurs utilisent sinon quotidiennement, au moins fréquemment.

   Voir également la réponse de Jerry Coffin qui contient une analyse plus détaillée de ce type de questions.

4. (Moyenne) "Lequel est le plus rapide, SSD ou RAM?"

   Cela peut être utile et indique si la personne a suffisamment de connaissances en matériel, mais tout de même, un candidat qui ne peut pas répondre à cette question ne doit pas être rejeté.

5. (Moyenne) "Comment la pile et la file d'attente sont-elles implémentées?"

   C'est le genre de questions dont vous parlez. Ils sont théoriques, peut-être même trop théoriques, mais savoir ce qui se passe sous le capot peut aider à écrire un meilleur code.

   Je ne rejetterais pas un candidat qui ne peut pas répondre à cette question, mais vérifierai plus attentivement s'il connaît vraiment les choses, par exemple en posant une question connexe mais moins théorique:

6. (Bon) "Comment pouvez-vous traverser un arbre sans utiliser la récursivité?"

   Si le candidat répond à cette question, en parlant de FILO / FIFO et des avantages et inconvénients de l'utilisation d'une pile par rapport à une récursivité pour la traversée des arbres, peu importe qu'il n'ait pas pu répondre à la question précédente.

   Poser cette question est également un bon moyen de détecter les candidats qui ont passé des années à faire leur diplôme CS, mais qui n'ont aucune expérience sur le terrain.

Comment poser de bonnes questions techniques?

Le commentaire de kojiro est intéressant et mérite une réponse plus longue:

Parfois, vous devez embaucher quelqu'un précisément parce qu'il devrait en savoir plus sur un sujet que vous, donc par définition, vous n'êtes pas qualifié pour faire l'entretien. Vous ne pouvez pas obtenir de l'aide de manière fiable, même en faisant l'entretien pour la même raison. Le mieux que vous puissiez faire est d'essayer de poser des questions en fonction de l'endroit où votre compréhension recoupe le domaine problématique et j'espère que vous aurez de la chance.

Trouver de bonnes questions peut être difficile, en particulier lorsque vous embauchez votre tout premier développeur ou lorsque vous embauchez un développeur qui devrait être plus qualifié que tous les développeurs qui travaillent réellement dans l'entreprise.

Voici trois conseils qui peuvent vous aider:

1. Trouvez un ami / collègue que vous croyez compétent et demandez- lui de faire les évaluations. Cela nécessite beaucoup de confiance, mais peut grandement profiter à votre entreprise.

2. Trouvez un consultant que vous croyez compétent et demandez-lui de vous aider ou de faire la partie technique de l'entretien.

3. Tapez "questions d'entrevue" dans Google. Cela fonctionne plutôt bien et explique généralement les réponses possibles. Exemple:

   • Python : ces dix questions semblent assez bonnes. Ils sont peut-être un peu basiques, mais aideront à filtrer 95% des candidats que vous ne souhaitez pas embaucher de toute façon.

   • SQL par Dave Pinal, excellent comme d'habitude.

   • C # : un peu trop basique, mais encore une fois, ils filtreront 95% des candidats,

   • JavaScript : les questions sont plus ouvertes, ce qui peut ne pas être la bonne chose pour les questions techniques si vous voulez que l'entretien soit court et que vous ayez plus de temps pour les questions non techniques ouvertes. La liste permet toujours de filtrer facilement les candidats qui ne comprennent pas les concepts de base en JavaScript.

   L'inconvénient de cette approche est que le candidat peut utiliser la même technique pour s'entraîner à l'entretien. S'il a examiné chaque question du premier site Web qu'il a trouvé dans Google, il peut obtenir de bons résultats, sans avoir réellement les compétences requises.

^{¹ Il y a des développeurs qui ne seront pas en mesure d'expliquer ce qu'est un arbre B (à part que c'est "une certaine structure de données"), mais sont toujours capables de se développer correctement.}

D'après mon expérience dans mon entreprise où j'ai réalisé de nombreux entretiens, il y a de fortes chances que la personne qui interroge ne sache pas comment procéder correctement. Ils ont donc préparé un ensemble de questions techniques et calculé un score de cela et en faire votre CV. Cela présente cependant de nombreux inconvénients et ne doit pas être fait pour les raisons suivantes:

• Vous demandez des connaissances ponctuelles. S'il arrive que le programmeur n'ait jamais fait quelque chose dans ce domaine, il / elle pourrait toujours être un excellent collègue, mais ne connaît tout simplement pas cette réponse particulière. À l'opposé: si quelqu'un s'était préparé pour l'entretien et avait trouvé la réponse à cette question particulière sur le net, vous obtenez la bonne réponse, mais cette personne n'a peut-être aucune idée du sujet réel.

• Les gens sont nerveux lors des entretiens d'embauche. Le cerveau a cette grande fonctionnalité pour fermer de nombreux domaines de niveau supérieur (comme la logique) en cas de panique, ce qui signifie: si vous êtes nerveux, vous pourriez ne pas fournir la qualité des réponses que vous auriez dans une situation quotidienne. Certaines personnes peuvent faire face à une situation stressante comme une interview, beaucoup ne le peuvent pas.

• Avec une seule réponse correcte, vous testez les compétences de cette personne pour trouver cette réponse particulière. C'est l'une des nombreuses compétences dont un collègue a besoin, mais pas la seule et la seule requise. Par conséquent, une ou deux de ces questions devraient être suffisantes pour tester ce domaine de connaissances, puis d'autres compétences devraient être interrogées. Un entretien qui ne contient que des questions de résolution de problèmes teste encore et encore la même compétence.

Quelles sont les bonnes questions de tâches de programmation?

Ces fameuses questions "Pouvez-vous écrire un programme court" ont l'énorme problème que la plupart des programmeurs ne peuvent pas écrire une seule ligne de code sans que leur IDE les aide. Mais cela ne pose aucun problème dans les situations de travail quotidiennes, car le programmeur a toujours son IDE pour l'aider. Donc, en demandant des choses comme "Trouver l'erreur", "Ecrire 50 lignes de code qui font ..." ou même des questions simples doivent prendre en compte, que le demandeur n'a pas ses outils (IDE, Google) disponibles.

Par exemple, je peux vous répondre à n'importe quelle question en moins d'une minute si Google m'aide, mais sans connexion Internet, je semble impuissant. J'appelle cela de la mémoire externalisée, et au lieu de me gêner, cela m'aide beaucoup à me concentrer sur ce qui est vraiment important - comprendre la mécanique sous-jacente - parce que tout le reste peut être recherché. Mais ne me demandez pas les détails des API aléatoires, car je ne les connais pas, j'ai Google pour ça.

Cela dit, une bonne question de tâche de programmation ne doit pas se concentrer sur la connaissance des API ou des compétences de codage spéciales, sauf si cela est une exigence absolue pour le travail. Les connaissances peuvent être acquises, il est donc préférable de savoir dans quelle mesure cette personne est en mesure d'acquérir des connaissances que de demander ce qu'elle sait déjà.

Une bonne question pour une tâche de programmation devrait être courte, simple, capable d'être codée dans toutes les langues avec seulement quelques lignes de code et elle - surtout - devrait vous en dire autant que possible sur la façon dont la personne travaille et trouve des réponses. Exemple:

"Écrivez une fonction dans la langue de votre choix qui prend un tableau d'entiers et les réordonne de manière à ce que le premier entier soit ensuite le dernier, et tous les autres changent en conséquence."

Le premier que tout candidat devrait demander à ce stade est: "Désolé ... pouvez-vous s'il vous plaît expliquer la tâche?". Parce qu'aucun programmeur n'a reçu de description claire de ce qu'il faut faire. Ceci est suivi par l'explication, que le code dans les questions doit faire un décalage à gauche du contenu du tableau avec le débordement ajouté à droite.

Cette tâche est si simple que toute personne diplômée d'une forme quelconque de programmation devrait être en mesure de répondre correctement. Cela tient compte du fait que le programmeur doit travailler sans ses outils et que la nervosité réduit la capacité de penser logiquement. Cependant, il vous indique toujours comment les gens résolvent les problèmes simplement de la façon dont la question est formulée et de la façon dont les gens l'abordent, tout simplement parce qu'un décalage à gauche est contraire à l'instinct commun de «gauche à droite» et oblige les gens à réfléchir une seconde.

Il existe de nombreuses réponses possibles à cette question, donc examiner de près la façon dont le code est développé est la partie importante, pas si la solution fonctionnerait réellement. Le demandeur teste-t-il la nullité? Comment le débordement est-il stocké? Est-ce qu'une boucle ou un jeu de memes est utilisé? Comment le demandeur vérifie-t-il l'exactitude du code? Cette simple question vous donne une biographie complète sur le fonctionnement de cette personne.

Quelles sont les bonnes questions de culture générale?

Les bonnes questions sont faciles à répondre, permettent un grand nombre de réponses (appelées `` questions ouvertes '') et vous permettent d'en apprendre le plus possible sur le demandeur dans la courte période de temps dont vous disposez.

Exemples:

(Demander à un programmeur C ++): "Quelles autres langues à côté de C ++ connaissez-vous?"

Il s'agit d'une question de niveau d'entrée, qui donne au demandeur une chance équitable de renflouer en ce moment s'il ne sait rien du sujet posé. Un «non» à ce stade est mieux que de le tourmenter avec plusieurs autres questions auxquelles il / elle doit répondre: «Désolé, je ne sais rien à ce sujet.

J'ajoute que cela vous dit tout d'abord quelles autres langues cette personne connaît, en plus vous apprenez à quel point cette personne est intéressée pour avoir une vue plus large du monde de la programmation, ou si vous avez quelqu'un avec seulement une langue singulière (et donc des fonctionnalités / techniques ) vue.

(Ensuite, disons qu'il connaît Java): Quelles sont les trois principales différences entre C ++ et Java à votre avis? "

Il s'agit d'une question ouverte qui permet de nombreuses réponses, de sorte que le demandeur a une bonne chance d'en trouver au moins trois. Demander le top 3 (opinion personnelle) limite non seulement les réponses possibles, mais oblige également le demandeur à trier en fonction de la priorité. Pourtant, il est (ou devrait être) facile de répondre.

Il s'agit d'une question simple qui teste beaucoup de connaissances approfondies sur les différents langages de programmation. Quelle est vraiment la connaissance de ces sujets? À partir de ces réponses, vous pouvez en dire beaucoup sur la connaissance et la compréhension réelle des mécanismes sous-jacents des langages de programmation. Combien cette personne a dépensé avec les détails sales, ou si elle est juste quelqu'un qui relie les différentes fonctions de l'API sans aucune idée de ce qui se passe en dessous.

Ce concept de questions d'entrée de gamme suivi de simples questions de connaissances approfondies peut également être utilisé pour la plupart des autres sujets. Toujours dans ce schéma: question de renflouement, question de vérification, question approfondie. Un autre exemple (extrait d'une interview Java):

1. "Comment évalueriez-vous votre expérience avec le développement multi-thread?"
2. "Veuillez nommer ce que vous pensez être les trois choses les plus importantes à considérer lors du développement d'une application multi-thread."
3. "Veuillez nommer trois classes de l'API Java qui peuvent vous aider à développer ces applications et donner une brève description de leur utilisation."

Ces trois questions vous en diront plus que toute question technique sur ce que le candidat sait vraiment sur ces sujets, tout en étant juste de répondre compte tenu de la connaissance des points et du niveau de stress.

Ainsi, la prochaine fois que quelqu'un vous posera 20 questions de codage d'affilée, vous saurez qu'il ou elle n'a pratiquement aucune idée de la manière d'interviewer correctement quelqu'un. ;)

Avertissement: ceci est écrit comme (une sorte de) commentaire sur la réponse de @ MainMa, mais 1) il est trop long pour tenir dans un commentaire, et 2) je pense que cela ajoute une perspective quelque peu différente sur les questions constructives, donc c'est une vraie réponse en soi .

Dans sa réponse, @MainMa classe "Quelles sont les nouvelles fonctionnalités de .NET 4.5?" comme une "bonne" question.

Je ne suis pas d'accord. Comme il l'a formulé, je dirais que c'est au mieux une question assez médiocre. Une bonne question serait plus comme: "En quoi le code que vous écrivez aujourd'hui diffère-t-il du code que vous avez écrit il y a N ans?" (pour une valeur de N inférieure aux années d'expérience listées sur le CV, de préférence environ 3 à 5).

Comme il l'a formulé, la question porte sur la mémorisation. Ce candidat a-t-il complètement mémorisé la liste des fonctionnalités? De droit, celui qui cite la liste de Microsoft le plus précisément devrait être le gagnant.

Ce dont vous devez vous soucier, c'est de sa programmation. Comment cela a-t-il affecté son code? Laquelle de ces fonctionnalités utilise- t- il vraiment ? Plus important encore, affiche-t-il un bon jugement sur le moment d'utiliser quelles nouvelles fonctionnalités et quand les anciennes suffisent parfaitement?

Le simple fait de pouvoir dire "LINQ" ne vous dit pratiquement rien d'utile sur le candidat. Pouvoir dire: "LINQ a aidé à rendre mon code beaucoup plus compact et lisible car je peux exprimer les concepts X, Y et Z de manière claire et directe, où je devais auparavant sauter à travers les cerceaux enflammés suivants pour faire ces choses." (ou quelque chose de similaire) vous en dit long sur le candidat, le type de code qu'il écrit, son jugement, sa flexibilité, etc. Cela vous donne également beaucoup plus de possibilités de questions de suivi sur la façon dont cette personne pense aux problèmes, écrit le code, pense au code, etc. Enfin, cela vous donne une bien meilleure idée de savoir si c'est un candidat qui a vraiment N années d'expérience, ou quelqu'un qui a une année d'expérience, répété N fois.

Résumé: pouvoir citer une liste de fonctionnalités d'il y a quelques années est inutile, et vous en dit peu sur le candidat qui sera vraisemblablement utile. Les progrès du candidat en tant que programmeur sont susceptibles d'être beaucoup plus intéressants, il est donc préférable de poser des questions plus directement à ce sujet.

La réalité est que la plupart des tâches quotidiennes que la plupart des développeurs accomplissent dans leur vie professionnelle sont triviales; Cela signifie que certaines des questions auxquelles vous êtes confronté lors d'un entretien d'embauche peuvent ne jamais vous confronter en réalité, mais cela ne signifie pas qu'il est inutile de poser ces questions.

Disons qu'il y a un poste ouvert dans votre entreprise et que vous interviewez actuellement des personnes. Vous avez déjà 20 à 30 développeurs dans la file d'attente. Alors, comment choisiriez-vous le meilleur candidat pour ce poste? Disons que la tâche la plus difficile à accomplir dans ce travail est d'ouvrir un fichier à partir du système de fichiers, de lire les données ligne par ligne, de les modifier légèrement et de les replacer dans le fichier d'origine.

Allez-vous leur demander comment ouvrir un fichier? Je parie que vous ne pouvez pas voir une très grande différence entre les réponses. Vous devez donc trouver une solution pour faire la distinction entre les développeurs qui savent uniquement ouvrir un fichier et ceux qui peuvent développer une application bad-ass en temps réel. Même si vous ne voulez pas qu'ils créent une telle application, vous souhaitez tout de même embaucher le meilleur candidat.

Comme toute autre chose dans notre vie, il y a des points sur lesquels vous vous rendez compte que vous devez aller en savoir plus. Si vous ne savez pas ce qu'est une liste chaînée, pour moi en tant que programmeur, cela signifie littéralement que vous n'avez pas vraiment atteint ce stade de votre vie professionnelle pour sentir que vous devez aller apprendre cette chose spécifique. Pourquoi? Tout simplement parce que vous n'avez jamais participé à un projet suffisamment important pour vous obliger à améliorer vos compétences jusqu'à ce niveau. Si vous êtes au niveau d'entrée, vous pouvez dire que je n'ai pas vraiment d'expérience de travail pour ce travail spécifique, mais si vous le savez, cela signifie que vous êtes suffisamment motivé pour vous mettre au-dessus de la moyenne au moins.

Les compétences requises pour effectuer ces tâches sont rarement importantes. Les compétences démontrées dans l'approche de la réponse à la question et dans le dialogue qui s'ensuit constituent l'essentiel.

Lorsque j'interviewe des développeurs, je recherche (a) intelligent (b) fait avancer les choses (c) s'intégrera. compétences. L'entretien consiste à cocher ces cases.

Ma préférence est de lire le code écrit par un candidat. Je n'aime pas les questions d'entrevue en conserve, mais elles fournissent de quoi parler en l'absence de code. Je préfère poser des questions sur RAII ou IOC ou sur la mise en œuvre d'IDisposable plutôt que sur la liste et les collections, mais tout fera l'affaire tant que nous pourrons l'obtenir suffisamment technique .

La pire crainte de l'intervieweur est d'embaucher quelqu'un qui ne connaît pas grand-chose au codage. Vous devez parler d'autre chose que de l'expérience de travail pour éliminer les contrefaçons.

Ces questions sont destinées à éliminer les personnes qui ne peuvent pas programmer. Parfois, les personnes qui ne peuvent pas programmer mais connaissent beaucoup de futilités postulent à des emplois de développement, et les faire écrire quelque chose d'utile et non trivial prend trop de temps pour une interview.

Je peux voir que ces compétences peuvent être utilisées dans des emplois où vous devez écrire des compilateurs, des pilotes et travailler sur le noyau du système d'exploitation. À part ceux-là, où ces compétences sont-elles utilisées?

Que diriez-vous d'écrire des moteurs de recherche, des serveurs Web, des navigateurs Web, des traitements de texte, des feuilles de calcul, des éditeurs d'images, des programmes de dessin, des serveurs de bases de données, de la bioinformatique, des programmes commerciaux, des jeux, des simulateurs de physique, etc.

Je vous garantis que la majorité des travaux de logiciels impliquent d'extraire des données d'une base de données, de les afficher sur un écran, de les modifier, de les supprimer de l'écran et de les remettre dans une base de données. Cependant, même dans ce cas, vous pouvez éventuellement exécuter une application où les contraintes ne peuvent pas être satisfaites par les fonctionnalités intégrées d'une plate-forme. À ce stade, vous pouvez soit abandonner, soit accéder à votre boîte à outils d'algorithmes et de structures de données et tenter de résoudre le problème.

Les objets théoriques sont utilisés pour plus de commodité car vous êtes censé savoir ce qu'est une implémentation moyenne d'arbre / graphique / liste, donc savoir comment résoudre un problème de traversée aléatoire, mais ces questions ne concernent pas du tout les objets théoriques.

Il s'agit de pouvoir travailler avec un modèle abstrait, de comprendre un problème abstrait et de le résoudre avec un algorithme de quelque nature que ce soit. C'est une pure compétence de développement là-bas, donc ça compte. C'est pourquoi ces questions ont un sens, non pas parce qu'elles sont censées être des situations réelles précises.