Bons projets de programmation d'entrevues
Je suis à la recherche de petits projets de programmation que je peux donner à des employés potentiels pour évaluer leurs capacités de programmation. Ce seront des programmeurs tout droit sortis de l'université. Je recherche des projets qui prendraient quelques heures à quelqu'un et ils renverraient leurs réponses après l'entrevue.
Un exemple serait de prendre ce paragraphe de texte et de renvoyer une liste de mots uniques alphabétisés. Après chaque Parole, dites-moi combien de fois la Parole est apparue et dans quelle (s) phrase (s) la Parole a apparu.
Quelqu'un a-t-il de bonnes suggestions?
Je conclus depuis longtemps que rien de ce que quelqu'un peut faire en peu de temps ne peut me dire quelque chose d'utile sur cette personne. Mais chaque bon candidat a déjà écrit des projets personnels qui peuvent vous en dire beaucoup. J'ai donc remplacé les défis spécifiques par "donnez-moi un morceau de code dont vous êtes fier et heureux d'apposer votre nom".
Leur choix de projet vous en dit plus que n'importe quelle tâche d'une heure. Et puis vous pouvez passer une heure à en discuter pour en savoir encore plus.
Je suis tellement fatigué de cette merde jeu-esprit. J'ai été dans des endroits qui m'ont demandé des exemples de code, les ont déchirés, puis m'ont demandé d'expliquer un exemple de code de leurs systèmes qui semblait avoir été écrit par des enfants de 2 ans. On m'a demandé d'implémenter des algorithmes de tri obscurs, des services réseau, des guis, des structures de données (toujours soit une arborescence soit une liste liée). Chaque saveur de tripoter une question ennuyeuse sur ce que pense l'intervieweur est la partie la plus importante de la programmation.
En fin de compte, tout cela est à peu près inutile. La meilleure façon d'évaluer un employé est de l'embaucher pour 30 jours et de voir dans quelle mesure il fait le travail. Passez tout le temps que vous souhaitez développer des tests, et cela ne vous dira rien sur la façon dont quelqu'un travaille au quotidien.
Permettre à quelqu'un de réaliser un projet pratique à son rythme ne signifie pas nécessairement que ce soit lui qui le fait.
Tout le monde arrive tôt pour un entretien (enfin, au moins). Nous avons une feuille "pendant que vous attendez" pour qu'ils travaillent jusqu'à ce que nous soyons prêts à les voir. Il contient huit (8) questions qui testent les connaissances des candidats dans la langue que nous utilisons principalement.
Nous ne recherchons pas les bonnes réponses, car tout le monde peut les trouver avec un ordinateur devant eux. Nous recherchons un processus, tentent-ils même la question, comment parviennent-ils à leurs réponses.
Lorsque nous entrons dans l'entrevue, nous passons en revue avec eux et répondons à toutes les questions qu'ils peuvent avoir, ce qui peut également les conduire à obtenir la bonne réponse. Cela nous permet également de demander comment ils ont obtenu les réponses qu'ils ont trouvées.
Ceci, combiné avec des travaux antérieurs, nous trouvons, sont les meilleurs moyens de filtrer les candidats.
MISE À JOUR 2016/06/15
Nous avons considérablement modifié notre processus de recrutement de développeurs.
Phase 1: Un entretien téléphonique de 15 minutes où nous posons 7 questions. Les 2 premiers sont "Quelle est la chose la plus amusante sur laquelle vous avez travaillé?" (ne doit pas nécessairement être lié à la programmation) et "Que codez-vous pour vous amuser pendant votre temps libre?".
Phase 2: Un mini projet qu'ils réalisent à leur rythme. Nous faisons ensuite un partage d'écran avec eux et ils nous montrent ce qu'ils ont construit. Pendant le partage d'écran, nous leur demandons également d'apporter deux modifications à leur projet, puis de les regarder travailler et le faire fonctionner.
Phase 3: Entretien en personne.
Ce processus nous permet de comprendre la culture adaptée immédiatement (phase 1). S'ils peuvent faire le travail et suivre leur discours (phase 2). Enfin, assurez-vous que leurs valeurs correspondent à ce que nous recherchons (phase 3).
Vous voudrez peut-être vérifier Jon Jagger est fantastique Cyber-Dojo .
C'est un environnement intégré basé sur le Web conçu pour faire pratique délibérée de Test Driven Development et apprendre sur la dynamique de l'équipe. Il a beaucoup de petites tâches de programmation (kata) et prend en charge une gamme de langages, de Python et Ruby à Java et C++.
Contrairement aux IDE conçus pour la productivité, il n'y a pas de complétion de code, de mise en évidence de la syntaxe ou de refactorisation automatique, vous pouvez donc voir ce que votre interlocuteur peut faire sans ces derniers.
La meilleure chose est qu'après avoir fait un kata, vous pouvez ensuite revenir en arrière et regarder la progression rouge/verte (ou peut-être pas s'ils ne font pas TDD * 8 ') de chacun des kata. Chaque compilation/test valide les modifications dans un référentiel git avec les résultats du test.
Je pense que l'utiliser pour les tests de codage des entretiens pourrait vous en dire beaucoup non seulement sur la capacité des candidats à résoudre un problème, mais aussi sur leur approche de la résolution de problèmes et le processus qu'ils utilisent lorsqu'il n'est pas contraint par des facteurs externes, sélectionnez simplement un kata approprié au temps que vous souhaitez que le candidat y passe.
Si vous voulez votre propre serveur CyberDojo, le projet entier peut être trouvé sur github et il y a même une machine virtuelle d'appliance Linux clé en main liée à partir de là, ce qui signifie qu'en supposant que vous avez déjà VMware player ou VirtualBox installé, vous pouvez être opérationnel en quelques minutes après avoir téléchargé l'appliance!
Je n'ai interviewé qu'une seule fois une entreprise qui l'a fait. Ils ont donné une feuille de questions de 6 ou 7 problèmes. Les instructions étaient de faire une méthode pour résoudre chaque problème.
Une partie de la tâche consistait à réaliser que vous pouviez réutiliser du code. Les problèmes peuvent utiliser du code provenant d'autres solutions. Ce n'était pas non plus séquentiel. Par exemple, la question 3 pourrait être écrite en utilisant la méthode utilisée pour la question 5.
Je suggère d'essayer quelque chose comme ça.
Quant aux questions? Certaines des premières questions sur le site Project Euler sont bonnes.
Vous pouvez également essayer un jeu simple si vous voulez voir comment ils peuvent monter un projet.
Ou, si vous ne voulez pas trouver quelque chose, demandez-leur de vous envoyer du code d'un projet final.
Afin de demander aux gens de terminer un projet, vous devez avoir un ensemble spécifique de compétences que vous souhaitez évaluer à l'esprit et concevoir le projet pour tester ces compétences.
Un exemple serait de prendre ce paragraphe de texte et de renvoyer une liste de mots uniques alphabétisés. Après chaque Parole, dites-moi combien de fois la Parole est apparue et dans quelle (s) phrase (s) la Parole a apparu.
Que recherchez-vous avec cette question? Combien y a-t-il de façons de le résoudre et que vous apprend chaque approche sur la personne qui a écrit la réponse? Les compétences démontrées par une réponse efficace à cette question sont-elles les mêmes compétences qui sont les plus importantes pour votre entreprise?
Je ne veux pas les réponses à ces questions; Je veux juste que vous ayez réfléchi aux réponses avant de soumettre un groupe de candidats à votre processus. Si vous savez quelles compétences vous recherchez, créer une question pour rechercher ces compétences n'est pas difficile. Si vous utilisez la question de quelqu'un d'autre sans avoir une compréhension approfondie de ce qu'il a été conçu pour évaluer (le cas échéant), vous vous trompez vraiment et perdez le temps de tout le monde.
Un exemple serait de prendre ce paragraphe de texte et de renvoyer une liste de mots uniques alphabétisés. Après chaque Parole, dites-moi combien de fois la Parole est apparue et dans quelle (s) phrase (s) la Parole a apparu.
Dans quelle langue écriraient-ils cela? S'ils sortent d'une école qui se concentre fortement sur C, ce ne serait pas aussi rapide à écrire qu'une école qui enseigne Python/Perl/Ruby etc ... Ou même Java ou C #. Néanmoins, c'est un bon petit test.
J'en suggère quelques-unes plus faciles en fait pendant l'entrevue. Pas de questions pièges. Je suis avec TMN sur celui-ci. Donnez-leur quelques fonctions qui effectuent des tâches de base et demandez-leur ce qu'elles font (lire le code des autres). Donnez-leur ensuite quelques tâches de base (<20 lignes) pour écrire dans la langue de leur choix. Cela devrait être suffisant pour qu'un niveau d'entrée sache s'il peut coder ou non (à une position de niveau d'entrée). Cela, avec l'interview et GPA, devrait vous donner une bonne idée de ce que vous devez savoir.