Question:
Comment puis-je déterminer si une tâche de codage est trop difficile pour un candidat à une entrevue?
libik
2017-11-07 14:27:08 UTC
view on stackexchange narkive permalink

Je suis ingénieur logiciel senior et développeur principal dans une entreprise de 250 employés. La société embauche des développeurs de niveau intermédiaire à senior. Je fais des entretiens techniques, même si je suis ici depuis seulement 2 mois. Je n'ai pas beaucoup d'expérience dans le domaine des entretiens car mon entreprise précédente était beaucoup plus petite et l'embauche de nouveaux ingénieurs backend était très rare.

Une partie des entretiens consiste en un codage en direct, généralement via Skype. Les candidats peuvent utiliser leur propre IDE ou utiliser un éditeur collaboratif en temps réel, tel que CollabEdit. Ils ont 20 à 30 minutes pour terminer la tâche. Je me fiche de la syntaxe, le but de la tâche est de prouver la capacité de trouver la solution et de la mettre en œuvre.

Beaucoup de candidats prometteurs (ayant une bonne expérience, des connaissances et une capacité à évaluer pourquoi un un cadre / une technologie particulière est utilisé) échouent sur ce que je pense être des tâches de codage faciles (par exemple, trouver le deuxième plus grand nombre dans un tableau). Je comprends qu'ils sont sous pression, mais j'essaye de les guider et de les mettre à l'aise. Je leur fournis généralement des squelettes de code pour les démarrer.

J'ai consulté le responsable technique. Il dit que si le candidat est incapable de faire cela, nous ne devons pas continuer, car nous recherchons des programmeurs et nous attendons d'eux qu'ils écrivent du code.

Puisque tant de candidats prometteurs échouent à ces tâches de codage, je me demande si elles sont vraiment aussi "faciles" que je l'avais supposé. Comment puis-je déterminer si une tâche de codage demandée lors de l'entretien est trop difficile?

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (http://chat.stackexchange.com/rooms/68396/discussion-on-question-by-libik-how-can-i-determine-if-a-coding-task-est trop difficile).
Concevez une tâche qui peut être effectuée par n'importe quel développeur, mais qui donnera beaucoup d'opportunités à un bon développeur de faire un meilleur travail.
* Développeurs de niveau intermédiaire à senior * - s'ils ne peuvent pas trier le tableau des nombres grands à petits et obtenir l'indice 1, ils ne sont évidemment pas qualifiés pour le poste ...
Vous n'avez même pas besoin de trier.Vous analysez simplement le tableau une fois et conservez le plus grand et le deuxième plus grand nombre.Je me considère comme un développeur senior, et cela m'a pris 6 minutes à implémenter dans un langage que je ne connais pas un peu: j'ai dû rechercher un exemple d'analyse de tableau, obtenir une solution de travail initiale, réaliser qu'il y avait un bogue, etcorrige le bogue.Au cours de ma thèse, j'ai utilisé pour TA "structures de données et algorithmes".Nous avons demandé à des étudiants de premier cycle de mettre en œuvre des problèmes plus difficiles, sur papier, pour une fraction de la note.Certes, certains d'entre eux n'ont pas fait la partie codage, mais je ne conseillerais pas à OP de les embaucher.
Sept réponses:
Eric Lippert
2017-11-08 00:39:48 UTC
view on stackexchange narkive permalink

Comment puis-je déterminer si une tâche de codage est trop difficile pour un candidat à une entrevue?

Votre question est ambiguë. Laissez-moi essayer de le croustiller. Je pense que ce que vous demandez vraiment, c'est:

Nous avons un processus pour obtenir un signal de la part de candidats sur leur forme . Si le processus produit un signal «sans embauche» pour les candidats qui sont réellement aptes, alors la partie de la question technique du processus pourrait être trop difficile. Comment puis-je déterminer si une question est trop difficile?

C'est facile; comme d'autres l'ont dit, faites suivre le processus à vos collègues qui sont connus pour être en forme; si le processus les rejette systématiquement, il y a quelque chose qui cloche dans le processus.

Mais ce n'est pas le problème que vous rencontrez . Ceci est un site de questions et réponses, et vous avez posé la mauvaise question.

Le problème que vous rencontrez en fait est qu’une fraction importante des candidats est manifestement inapte , et cela représente une perte de temps, d’efforts et d’argent qui pourraient être mieux dépensés ailleurs.

Vous avez un problème de pipeline, pas un problème de question de codage. Quelque chose dans votre pipeline de candidats produit une grande partie de candidats manifestement inaptes. Comme chacun le sait, un grand nombre de candidats à un poste en programmation n’ont aucune capacité à écrire des programmes, même simples : https://blog.codinghorror.com/why-cant-programmers-program/

Demandez autour de vous et voyez si d'autres enquêteurs ont des problèmes similaires. Si tel est le cas, repoussez la direction et le recrutement pour voir s'ils peuvent comprendre ce qui incite le recrutement à continuer de vous envoyer des candidats non qualifiés.

Votre solution suppose fortement que la tâche de codage est une difficulté appropriée pour cet entretien, ce que vous ne pouvez pas supposer.Si la tâche de codage est en effet trop difficile, nous ne pouvons rien supposer de l'aptitude des candidats.
@TheSoundDefense L'exemple de tâche de codage est de trouver le deuxième plus grand nombre dans un tableau ... très simple pour quiconque pourrait légitimement prétendre être un programmeur professionnel.
@TheSoundDefense: J'irais même plus loin que MaybeFactor, et je dirais que c'est sacrément facile.Non seulement le candidat devrait être en mesure de réussir, mais aussi sous une forte pression.Autrement dit, trouver de bons candidats est difficile, et parfois, il vaut mieux ne pas embaucher personne que d'embaucher une personne inapte car «il faut prendre quelqu'un».
@gazzz0x2z: Je ne suis pas d'accord avec votre "parfois".Il est ** TOUJOURS ** préférable de ne pas embaucher quelqu'un que d'avoir une personne inapte.N'avoir personne signifie que leur travail n'est pas terminé.Avoir une personne inapte * ralentit également tous les autres membres de l'organisation *.Vous n'avez jamais * à * prendre quelqu'un.
@EricLippert: tu as raison, j'ai été trop prudent dans mon commentaire
Si quelqu'un ne peut pas préparer du code qui trouve le deuxième plus grand nombre dans un tableau, je ne suis même pas sûr que je l'envisagerais pour un poste de stage.Sans parler des développeurs de niveau intermédiaire à senior.Le problème est vraiment celui suggéré par @EricLippert.
DarkCygnus
2017-11-07 23:08:03 UTC
view on stackexchange narkive permalink

Comment puis-je déterminer si une tâche de codage demandée lors de l'entretien est trop difficile?

Il semble que ces candidats qui échouent prouvent que votre tâche de codage peut être plus difficile que tu penses.

Empiriquement, vous pouvez déterminer si les futures tâches de codage sont "trop ​​difficiles" si vous voyez plusieurs candidats échouer ou prendre trop de temps pour les faire.

Vous pouvez également demander à vous-même ou à des collègues techniques d'essayer d'effectuer les tâches de codage, de prendre votre temps pour le faire, puis de comparer vos résultats avec vos attentes concernant ces tâches particulières. Vous pouvez ensuite déterminer si cela nécessite une certaine simplification pour être en mesure d'effectuer une interview de codage régulière.

Gardez à l'esprit que, généralement, les interviews ou les tests de codage ne doivent pas être trop longs . Sinon, vous n'évaluerez pas réellement les connaissances en la matière, mais vous verrez simplement qui est le meilleur en prétendant connaître un langage de programmation (en 2 heures, n'importe qui peut rechercher et devenir un "expert" sur n'importe quelle balise Stack Overflow). Habituellement, des questions ou des tâches simples et directes sont plus efficaces pour mesurer les connaissances linguistiques ainsi qu'une certaine créativité et improvisation.

Je vous suggère également de jeter un œil à cette question, où plusieurs réponses sont données qui pourraient aider à décider si une tâche spécifique doit être supprimée ou non.

+1 pour avoir demandé à des collègues de faire cela.Si un collègue échoue, OP doit également demander «est-ce que je licencierais cette personne?Si la réponse est non, la tâche est soit trop difficile, non appropriée au poste, soit ne doit pas être le facteur décisif.
D'accord, @Kathy.Si tous les candidats viables doivent être en mesure de répondre à vos questions d'entrevue, il va de soi que tous ceux qui y sont réellement employés devraient également être en mesure d'y répondre.S'ils ne le peuvent pas, vous devriez probablement recalibrer.De plus, poser des questions à des collègues permet de s'assurer que vos questions ne sont pas diffusées dans le reste du monde, ce qui les rendrait moins utiles pour vous.
@Kathy c'est vrai.Lors de la définition des tests de codage, vous devez d'abord les essayer avant de les implémenter.Penser et imaginer une tâche de codage est une chose et la réaliser en est une autre et ce degré de difficulté doit être pris en compte à tout moment.
Je considérerais qu'une grande partie des candidats qui ne parviennent pas à accomplir des tâches insignifiantes dans le cadre d'un entretien est une preuve qu'il y a quelque chose de profondément faux dans la génération de prospects et la sélection initiale par le recrutement, et non une preuve que le processus est trop difficile pour les candidats qualifiés.
@EricLippert est également vrai, qu'il y a un malentendu dans ce que le dépistage recherche chez les candidats et ce que les enquêteurs de code leur demandent de résoudre, il * pourrait * être que ces objectifs ne sont pas alignés, mais ce serait spéculer sans plus de retour deOP (auquel cas pourrait probablement appartenir à une autre question)
@JoeStrazzere bonne suggestion, c'est donc une configuration plus réaliste.Vous pouvez toujours continuer et le faire de toute façon, sans limite de temps.Après cela, si vous voyez que cela prend plus de 20 à 30 minutes (une entrevue de codage régulière), vous savez que vous devez le réduire d'une manière ou d'une autre.Cela, ou voyez quelles tâches peuvent être accomplies dans ce délai, puis choisissez-les comme questions d'entrevue.
Par "trop long", vous entendez "beaucoup plus que nécessaire pour résoudre la tâche donnée" ou voulez-vous dire "plus de X minutes".Bien que je sois d'accord avec les deux, je pense que les longues interviews chronologiques sont un problème pour une raison différente - si vous avez réellement besoin d'utiliser tout le temps imparti, il ne restera plus grand-chose à passer beaucoup de temps à rechercher des choses.
Le long de la ligne * qui est le meilleur pour prétendre connaître un langage de programmation * certaines personnes sont bonnes pour savoir quelles tâches techniques certaines entreprises demandent habituellement, il serait donc préférable d'avoir un pool suffisamment grand à votre disposition et de ne pas toujours utiliser lemême.Et n'oubliez pas si vous demandez à vos collègues, ils doivent avoir à peu près le même poste que celui que vous recherchez.
@EricLippert Ce sont des tonnes de gens qui ont des diplômes dans divers domaines liés à l'informatique qui sont juste assez bons pour assembler des copier-coller et finalement "faire fonctionner".
JDługosz
2017-11-08 01:47:09 UTC
view on stackexchange narkive permalink

J'ai eu des problèmes similaires, avec des questions de codage très simples. Il semble que beaucoup de gens soient ce que nous avons appelé «les apprentis de l'assistant» après l'assistant générateur de code IDE et le dessin animé Micky Mouse. Ils pensent connaître le C ++ mais ne savent vraiment pas comment écrire une classe, même simple.

Voici la première. Je le lis toujours de manière à donner exactement le même libellé à tout le monde, mais de mémoire maintenant: «Ecrivez une classe dont le constructeur prend deux arguments intégraux et a des membres pour renvoyer leur somme et leur différence.»

Je m'attendais à pour voir différents niveaux de contrôle des spécifications avant de commencer, et les personnes qui utilisaient des modèles plutôt que de choisir un type spécifique, etc.

Ce que j'ai obtenu, c'est un nombre surprenant de personnes qui pouvaient pas d'écrire une classe, point.


par exemple, trouver le deuxième plus grand nombre d'un tableau

Comme je l'ai dit, clouer les choses avant codage:

  • Puis-je modifier le tableau?
  • Voulez-vous dire le deuxième élément dans l'ordre trié, ou voulez-vous dire la deuxième plus grande valeur unique ([1,2, 2,3,3,3] est la réponse 3 ou 2?)?
  • Doit-il traiter des tableaux qui ont moins de 2 éléments (ou des éléments uniques, en fonction de la réponse précédente)? Lancer une exception, planifier une valeur de retour facultative, ou quoi?

Dois-je clarifier les spécifications (et me faire approuver) puis écrire des cas de test critiques, comme dans la «vraie vie»?

Vos objectifs déclarés sont en contradiction avec les spécifications peu claires. Comme indiqué, vous devez d'abord tester les compétences en ingénierie , puis en codage. Et voulez-vous vraiment embaucher quelqu'un qui jettera ensemble un désordre illisible trop intelligent et non maintenable? Je remets en question la sagesse de ne pas se soucier de la syntaxe.

Si vous voulez juste savoir s'ils peuvent aborder le problème, faites des oraux plutôt qu'une tâche de codage. Faites-lui expliquer comment il le ferait: par exemple , je connais l ' algorithme standard, alors duh. Si cela fait ce que vous vouliez vraiment. Soyez impressionné par le fait que j'ai des références utiles mises en signet et toujours ouvertes, et ne vous inquiétez pas de la dernière étape de l'écriture d'un exemple de programme contenant une ligne qui appelle cette fonction.

Je me demande donc si votre test est vraiment prêt pour quelqu'un à simplement coder, ou si les problèmes que j'ai signalés paralysaient le candidat à qui on dit qu'il s'agit d'une spécification complète prête à coder?

En tant qu'intervieweur, j'utilise des spécifications peu claires pour voir comment le candidat résout l'ambiguïté.Posent-ils des questions de clarification?Leurs hypothèses sont-elles raisonnables?La résolution de spécifications ambiguës est quelque chose avec laquelle tout codeur expérimenté devrait avoir de l'expérience, donc tester cette compétence semble juste.
@meriton oui, je suis entièrement d'accord.C'est pourquoi je dis à l'OP que demander du code de travail piraté (uniquement) à partir de spécifications peu claires peut faire partie de son problème.
enderland
2017-11-07 23:22:54 UTC
view on stackexchange narkive permalink

Comment puis-je déterminer si une tâche de codage demandée lors de l'entretien est trop difficile?

Il existe plusieurs méthodes. De loin, le plus simple est de trouver une communauté de personnes que vous souhaitez embaucher et de leur demander.

Il peut s'agir d'un groupe de type Meetup. Cela pourrait être des personnes internes. Peut-être des forums en ligne. Pour les programmeurs, vous obtiendrez des tonnes de commentaires car la plupart des programmeurs peuvent être facilement snipés avec "hé, pouvez-vous m'aider à voir combien de temps prend cette question de programmation?"

Trouvez également une introduction standard à vos questions, afin que tout le monde reçoive les mêmes informations. Peut-être une feuille de discussion pour l'intro du problème. L'entretien peut être stressant pour les deux parties.

Ensuite, une fois que vous avez du temps pour la tâche, multipliez-le par au moins 1,5 pour tenir compte de la nervosité inhérente à l'interview et bam, vous avez une estimation du temps cela devrait prendre. Si la plupart de vos collaborateurs internes vous donnent une réponse en 20 minutes, il est déraisonnable pour une personne soumise à la pression beaucoup plus forte et plus gênante d'une interview de le faire systématiquement.

Deuxièmement, il est utile de motiver certaines personnes . Parlez-leur à l'avance de l'outil que vous utiliserez lors de votre inscription à l'entrevue. Dites aux candidats quel langage ils peuvent / ne peuvent pas utiliser (je peux programmer beaucoup mieux en Python qu'en Java, donc je peux résoudre des problèmes 10% du temps en Python plutôt qu'en Java). Assurez-vous qu'ils savent à quoi s'attendre. L'outillage peut être très maladroit au départ et vous ne voulez pas vraiment rejeter les gens à cause de cela.

Et enfin, au fur et à mesure que vous parlez des problèmes, encouragez les candidats à parler à voix haute avec leurs pensées. Cela fera une variété de choses:

  • Identifiez ce qui n'est pas clair sur le problème afin qu'il puisse être clarifié
  • Séparez les personnes qui sont nerveuses et font des erreurs de syntaxe qu'elles connaissent conceptuellement de personnes qui n'ont aucune idée
  • Vous donner plus d'informations sur leurs compétences que juste le code
meriton
2017-11-08 10:54:32 UTC
view on stackexchange narkive permalink

Depuis que j'ai interviewé quelques dizaines de candidats au moyen d'une tâche de codage, je pense que je pourrais avoir un aperçu:

Pour évaluer les compétences en programmation du monde réel, le test doit être effectué dans un environnement réel. Cela signifie un IDE, pas un tableau blanc. Cela signifie un accès à Google et un environnement de travail calme, sans être constamment interrompu par les questions ou les conseils d'un intervieweur.

La réussite du test ne devrait pas exiger un programme parfait, car les programmes du monde réel ne sont généralement pas parfaits à la première tentative. Je suis satisfait de voir de bons progrès vers une solution de travail. Si des bogues persistent, je vérifie que le candidat est capable de reconnaître le bogue à l'invite et peut décrire un correctif raisonnable.

Pour évaluer la difficulté du test, faites-le vous-même ou donnez-le à certains collègues (en reflétant les conditions d'entrevue aussi étroitement que possible). Regardez également les candidats que vous avez finalement embauchés malgré un test de codage marginal. Le test a-t-il prédit leur performance réelle au travail?

Cela dit, même si votre test est parfait, il est tout à fait normal de rencontrer un candidat occasionnel qui ne peut pas programmer sa sortie d'un sac en papier. Je ne pense pas que j'oublierai jamais le candidat qui a prétendu être un expert Java, mais qui n'a réussi à rien dans l'exercice de codage. Curieusement, pour une performance aussi médiocre, la fenêtre de leur navigateur est restée impeccable - mais ils avaient oublié d'effacer l'historique du navigateur, ce qui a révélé des recherches Google comme "comment déclarer une classe en Java". Il n'a pas décroché le poste, mais j'ai dû me répéter 4 fois avant que le responsable du recrutement ne me croie que le candidat qui avait parlé avec tant de confiance de sa vaste expérience n'avait en fait aucune idée.

Si vous avez beaucoup de mauvais candidats, il est également possible que la sélection initiale soit insuffisante. Un manque total de candidats qualifiés peut également signifier que votre offre d'emploi est trompeuse ou insuffisamment annoncée - ou peut-être qu'il n'y a tout simplement pas assez de codeurs à la recherche d'un emploi dans votre région.

user3748541
2017-11-08 00:27:41 UTC
view on stackexchange narkive permalink

Lorsque je sélectionnais les candidats à embaucher, je faisais des tests de codage en direct. J'avais l'habitude de dire: "n'hésitez pas à utiliser Google si vous avez besoin de chercher une inspiration". Ce que je cherchais, plus que la capacité de se souvenir par cœur de toutes les bibliothèques d'un langage déterminé, c'était la compétence de "focaliser le problème, construire une idée sur la façon de le résoudre, chercher un moyen de l'implémenter" Je tenais vraiment à tester. Cela ne me dérange pas vraiment s'ils recherchent une approche similaire dans Stack Overflow. Avec cette approche, je ne me souciais pas tellement de l'ampleur du problème (en considérant toujours, bien sûr, que le défi devrait être accompli dans un laps de temps raisonnable) ...

bien que vous ayez un point, je pense que cela ne répond pas à la question réelle posée ici
Strader
2017-11-08 04:01:42 UTC
view on stackexchange narkive permalink

L'OMI, les modèles et les squelettes à remplir sont plus déroutants qu'une simple tâche à partir de zéro, en particulier lorsque nous parlons de solution de 3-4 lignes. Que diriez-vous de la tâche de description d'algorithme étape par étape? il peut s'appeler programmeur. Et si le candidat peut écrire un algorithme, il peut l'implémenter.

Peut-être pensent-ils que vous essayez d'en tirer le travail utilisable sous prétexte de tâche de test.

Si vous gardez la tâche courte et simple sans aucun lien apparent avec la convivialité réelle, vous ne devriez pas avoir de problèmes.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...