Vous avez besoin d'un test de programmation. Mais cela devrait durer de 5 à 10 minutes. 30 minutes maximum. Il n'y a pas de test de 2 heures qui vous dise exactement à quel point un programmeur est bon. Vous ne pourrez pas dire s'il écrit continuellement du code maintenable, s'il commente toujours correctement, ou s'il propose des solutions “intelligentes” illisibles à des problèmes, etc. En deux heures, la seule chose que vous pourrez faire est de découvrir qui ment carrément sur sa connaissance d'un langage ou d'un programme.

Sauf que vous devriez pouvoir repérer les fraudes flagrantes en bien moins de deux heures. 5 minutes à écrire FizzBuzz et 2 ou 3 questions rapides sur les caractéristiques spécifiques d'une langue vous diront si elles sont absolument sans valeur. Et c'est à peu près le mieux que vous puissiez faire dans un entretien d'embauche.

Laissez-moi vous dire ce que je penserais si je recevais un examen de 2 heures pour le privilège de mener un entretien :

“Soit ces personnes pensent que cela a de la valeur, ce qui signifie qu'elles n'ont aucune idée de ce qu'elles font, OU, elles savent que c'est une perte de temps, mais pour une raison quelconque (probablement en suivant aveuglément la paperasserie des RH), elles sont prêtes à faire perdre du temps aux candidats avant même que le candidat ne soit engagé. Imaginez ce qu'ils penseront pouvoir faire une fois qu'ils m'auront payé.

De toute façon, je ne veux pas travailler là-bas”

Il y a autre chose qui pourrait faire fuir les candidats : La longueur de votre processus d'entretien. Vous avez des gens qui font un entretien téléphonique. Puis un test à emporter chez soi qu'ils ont une semaine pour terminer. Ensuite, vous passez en revue les tests. Ensuite, vous organisez un entretien en face à face avec la direction. Ensuite (je suppose), vous faites quelques entretiens en face à face. Ensuite, vous récupérez le type que vous voulez engager. Qu'est-ce que ça prend ? Deux semaines ? Plus longtemps ?

Pendant ce temps, j'ai déjà reçu 3 offres. J'en ai accepté une et je commence la semaine prochaine. Tu crois que je vais aller faire ton test de 2 heures ?

Permettez-moi de commencer par dire que l'embauche d'employés en général est une science pathétiquement inexacte, et vous obtiendrez divers résultats quoi que vous essayiez. Cela étant dit, j'ai pensé que je devais partager mes réflexions à ce sujet.

Je pense que les exercices de programmation sont un échec, principalement parce que vous aurez des gens désespérés qui auront beaucoup trop de temps pour les réaliser. S'ils ont un emploi à plein temps, vous devez leur demander combien de temps/énergie mentale ils prennent à leur employeur actuel pour travailler pour quelqu'un qui ne les paie même pas. Voulez-vous qu'ils vous fassent ce genre de choses ?

En outre, s'ils sont bons, ils passent très probablement des entretiens avec de nombreux employeurs. Devinez lesquels ils vont privilégier ? Ceux qui ne demandent pas à terminer les projets avant même d'avoir parlé au téléphone avec un responsable de l'ingénierie.

Il y a aussi le problème du plagiat. Bien sûr, ils seront découverts lors de l'entretien en personne, mais d'ici là, vous aurez déjà perdu le temps de faire passer un entretien à cette personne par des personnes (probablement) très bien payées de l'entreprise.

Mon entreprise actuelle l'a bien fait, et c'est la voie que je suivrais à votre place. Donnez-lui une petite tâche qui ne devrait prendre que 90 à 120 minutes, et dites-lui de justifier dans les commentaires pourquoi il a choisi ce moyen de résoudre le problème. C'est quelque chose qui peut être fait en une nuit et qui vous donnera un aperçu de leur réflexion.

Je peux vous dire dès maintenant que si je reçois un projet qui prend plus de 8 heures à faire, je leur dis merci mais je ne suis pas intéressé. J'ai un bon travail et une vie. Si un manager voit cela comme un problème, cela me dit qu'il ne se soucierait pas de mon équilibre entre vie professionnelle et vie privée au travail (surtout s'il ne se soucie pas de avant que je l'aie). Aucune entreprise, à l'exception peut-être de Google, Apple ou Facebook, ne pourrait s'en tirer comme ça.

D'après mon expérience, les projets à emporter n'éliminent pas les mauvais codeurs, et font probablement en sorte que les bons codeurs trouvent un emploi où ils n'ont pas à sauter à travers un cerceau pour parler au responsable du recrutement.

Pensez-y de cette façon. Un bon codeur peut facilement obtenir des entretiens téléphoniques et en personne. Chaque obstacle supplémentaire qu'il doit franchir signifie qu'il prendra le chemin le plus facile et qu'il sera interviewé (et embauché) par quelqu'un d'autre qui paiera tout autant. **Si vous obligez les gens à faire des efforts, assurez-vous qu'ils voient que cela en vaut la peine dès le départ. Vous ne les verrez pas prendre 4 fois plus de temps ; vous verrez juste le test terminé. Vous ne les verrez pas non plus demander l'aide de Google ou de leur ami pour une déclaration if.

Ma dernière entreprise a fait cela, et la grande majorité des personnes que nous avons fait venir pour un entretien en personne ont échoué Fizz buzz (environ 65 %). Je pense que cela s'est produit parce que nous avons par inadvertance éliminé de bonnes personnes occupées qui n'avaient pas besoin de l'entretien d'une autre entreprise, et en même temps, nous avons fait pendre un entretien facile devant de mauvais codeurs.

Ce que je pense que nous aurions dû faire à la place

Au lieu de donner aux gens un devoir à emporter qui prenait 15-20 minutes à noter, nous aurions dû faire un entretien de 15-20 minutes sur Skype où nous avons posé des questions comme Fizz buzz. Cela aurait pris le même temps, mais j'aurais probablement éliminé les mauvais programmeurs avant un entretien en personne de deux heures.

FYI -> Voici un article très détaillé sur Fizz-buzz et les pratiques générales d'entretien.

Un point de vue contrasté, de la part de quelqu'un qui se trouve dans les tranchées des deux côtés de cette question. Je pense que cette réponse attirera des votes négatifs, mais c'est une opinion très éclairée, développée depuis plusieurs décennies dans ce domaine. Parce que j'aime le faire, j'écris encore du code tous les jours pour gagner ma vie et comme passe-temps dans mon “copieux temps libre”, mais j'ai aussi été le décideur final pour l'embauche d'une vingtaine de programmeurs, et j'ai aidé à faire passer des entretiens et conseillé pour l'embauche d'un nombre assez important d'autres personnes.

Lawrence a raison : l'embauche est terriblement inexacte. Mais nous nous améliorons avec le temps. Plus que les chats en face à face, plus que les questions triviales, les courts défis de programmation sur site en sont une partie de plus en plus essentielle : non seulement pour les compétences, mais aussi pour l'attitude.

Notez que j'ai dit “court ”. Nous donnons aux candidats un ordinateur portable équipé d'un Eclipse (notre IDE choisi) correctement installé lorsqu'ils se présentent à l'entretien. Une installation correcte signifie qu'ils ont accès à la source jdk, mais qu'il n'y a pas d'internet, et on leur demande de ne pas utiliser de téléphones portables pendant le test. Ils disposent d'une heure pour résoudre de zéro à cinq problèmes, en commençant par “FizzBuzz”, et en allant vers un système simple de production et de consommation multiple. Personne n'a jamais résolu les cinq problèmes en une heure, et je ne pense pas que quelqu'un le fera un jour (je peux écrire des solutions pour cinq problèmes en moins d'une heure, mais bien sûr, j'ai déjà vu les problèmes et les ai tous résolus, donc je ne suis pas un test équitable). Permettez-moi de le répéter : nous avons eu une poignée de candidats qui n'ont pas réussi à compléter FizzBuzz correctement. Généralement en ne suivant pas les instructions, mais la lecture des spécifications est une partie essentielle du métier de développeur.

Nous leur faisons écrire du code alors qu'ils sont ici dans nos locaux plutôt que de leur donner des devoirs pour plusieurs raisons, en partie le risque de tricher, et en partie pour donner à chaque candidat une chance égale de travailler les problèmes. Nous faisons également tourner les problèmes à l'intérieur et à l'extérieur de l'ensemble des défis, et nous discutons des solutions avec les candidats par la suite.

J'ai un sentiment très fort sur cette question. Je n'ai jamais vu un candidat refuser un poste ou abandonner le processus d'entretien à cause de notre test de programmation. Mais cela peut être influencé par le fait que nous disons aux recruteurs qui nous servent que le processus comprend une programmation sur place. Il se peut donc que nous ne voyions pas les candidats qui pensent que le fait de leur demander d'écrire une heure de code est un “travail non rémunéré”. Si c'est le cas, bon débarras. S'ils pensent qu'une heure de codage ressemble plus à du “travail” qu'une heure de réponse à des questions triviales, ou que leurs réponses aux problèmes du test peuvent produire quelque chose d'utile, je n'ai pas besoin de leur attitude.

Nous avons une fois eu un candidat qui s'est plaint du test, parce qu'il pensait être trop senior pour avoir à faire ses preuves (ce n'est pas de la spéculation - il l'a dit). Et il a bien relevé les défis, et il avait toute l'expérience que nous voulions. Mais c'était un employé terrible : il pensait aussi apparemment qu'il était trop senior pour prendre des directives ou apprendre, et finalement nous avons dû le laisser partir.

Une des choses que j'ai décidées au fil des ans, c'est que toute entreprise qui ne passe pas le test a moins de chances de m'avoir comme employé. Par exemple, leurs réponses à des questions comme ce qu'ils utilisent pour le contrôle des sources, etc., le fait qu'une entreprise teste m'en dit long sur leur compétence dans le domaine du développement de logiciels.

Donc, que devriez-vous faire ? *Vous devriez faire ce qui fonctionne pour votre organisation, mais mon conseil est de continuer les tests, mais de les faire sur place, dans le cadre de l'entretien. Dites-leur à l'avance que cela fait partie du processus, et faites-le avant qu'ils ne rencontrent la direction (mais vous devriez les rencontrer d'abord pour les mettre à l'aise). Et en fait : évitez l'entretien avec la direction s'il n'a pas lieu. Ne vous inquiétez pas de la popularité des candidats ou des affiches sur Internet. *Le coût d'une mauvaise embauche est bien pire que le coût de retarder jusqu'à ce que vous ayez fait une bonne embauche.

Pourquoi pas de tests à domicile ? Même si nous ignorons la possibilité de tricher et le filtre inversé qui fait que les bons et honnêtes candidats évitent les sociétés qui proposent des tests de codage à domicile, la valeur des tests de codage à domicile est limitée. Si c'est pour un poste de supérieur, un développeur senior ayant des compétences en relations humaines sera capable de dire en moins de 10 minutes si le développeur senior à l'autre bout du fil est bon ou s'il invente des choses. Nous ne saurons pas exactement à quel point il est bon, mais nous en saurons autant, voire plus, que ce que tous les tests de codage imaginables à domicile nous disent.

Si c'est pour un poste de cadre supérieur , nous n'attendons pas grand-chose en termes d'expertise technique. Nous recherchons l'enthousiasme, la volonté d'apprendre et le talent - qui ne sont pas repérés par un test de codage à domicile. Il y a trop de choses que les juniors sont autorisés à ignorer. Si nous les engageons, nous devons les former de toute façon.

Comment tester à la place ?

Comme filtre, donnez-leur 10 minutes pour résoudre une variante FizzBuzz sur place pendant la première série d'entretiens ou, si vous êtes submergé de bons CV et que vous avez besoin d'un autre filtre, faites-le sur Skype avant la première véritable série d'entretiens.

Une fois qu'ils ont passé les filtres, vous devez en savoir plus sur les capacités de codage de vos candidats. Je recommande de passer 30 minutes à 2 heures maximum de programmation en binôme ou d'examen des codes - un vrai travail, plutôt qu'un exercice. Répétez l'exercice une ou deux fois avec des partenaires différents. L'avantage de la programmation par paires et des révisions de code est que le développeur a déjà suffisamment de connaissances pour y contribuer.

Ne vous inquiétez pas du fait que le test soit différent pour chaque embauche - le but du processus d'embauche n'est pas de trouver la personne qui obtient le meilleur score dans quelques tests mesurables et répétables. L'objectif est d'engager une seule personne qui fera bien le travail.

Hier ist ein weiterer Punkt, der meines Erachtens in den vorhandenen Antworten (die meiner Meinung nach das Thema im Allgemeinen gut abdecken) nicht abgedeckt ist. Ich würde mir genau und ernsthaft anschauen, wie lange die Leute tatsächlich brauchen, um das Thema abzuschließen. Ich hatte vier Bewerbungsgespräche, bei denen ich eine Programmierübung zu absolvieren hatte, die jeweils unterschiedlich durchgeführt wurde (und jedes hatte seine eigenen Vor- und Nachteile). Zwei der vier (Nummern 3 und 4 unten) dauerten viel länger, als sie sagten, und beide habe ich schließlich wegen des schwierigen Niveaus aufgegeben. Ich habe sie im Folgenden beschrieben und sie aus meiner Sicht von der besten bis zur schlechtesten Stufe eingeordnet.

1. Während des technischen Interviews setzten sie mich an einen Computer, der eine abgespeckte Version ihrer Codebasis hatte, und ließen mich drei relativ kurze Probleme lösen, die damit zusammenhingen (einen Fehler finden und beheben, den sie absichtlich hinzugefügt hatten, ein neues Feld zu einer Infotabelle hinzufügen usw.). Sie gaben mir dafür genau eine Stunde Zeit, und nach einer Stunde gingen sie meine Lösung sowie meine Herangehensweise an die Probleme durch. Dadurch erhielten sie mehr Einblick in mich als Programmierer, während sie meine Zeit respektierten, indem sie sie kurz und auf den Punkt brachten.
2. Während des technischen Interviews ließen sie mich ein Problem, auf das sie während der Entwicklung gestoßen waren, an einem Whiteboard durcharbeiten, während ich gleichzeitig in der Lage war, Ideen von ihnen abzuprallen. Dies war die kürzeste Möglichkeit, während sie gleichzeitig die Möglichkeit hatten, zu sehen, wie ich Probleme bearbeite und wie sehr ich die notwendige Arbeit tatsächlich leisten kann.
3. Während des technischen Vorstellungsgesprächs (für eine Junior-Ruby on Rails-Position in der Webentwicklung) wurde ich damit beauftragt, eine Webanwendung von Grund auf zu entwickeln, die zu einer Website navigiert, mehrere Formulare ausfüllt, während sie präsentiert werden, Daten von der resultierenden Seite kratzt und diese dem Benutzer präsentiert. Sie sagten, dies sollte eine schnelle Übung sein, und es mag für einen hochrangigen Webentwickler gewesen sein, aber da ich zu diesem Zeitpunkt erst ein Jahr Berufserfahrung hatte, verbrachte ich vier Stunden damit, alles zum Laufen zu bringen, bevor ich aufgab und nach Hause ging (alle Interviewer waren Stunden vor mir gegangen, weil es ein Nachmittags-Interview war; sie sagten, ich solle einfach das fertige Programm speichern, wenn ich fertig war). Das ist eine lächerliche Aufgabe für die aufgeführte Stelle, sie hatten keine Ahnung von meinen Fähigkeiten im Codieren und es schien mir, als wollten sie nur freie Arbeit aus dem Deal herausholen. Unnötig zu sagen, dass ich die Stelle nicht einmal wollte, als ich an diesem Tag ging.
4. Noch bevor ich überhaupt ein technisches Vorstellungsgespräch hatte, gaben sie mir den Auftrag, eine Webanwendung zu erstellen, die die Vorteile einer API nutzen würde, mit der ihr Unternehmen “etwas Interessantes zu tun” hatte. Dies war genau so umfangreich, wie es sich anhört. Dazu musste ich Folgendes tun, bevor ich überhaupt versuchte, die Anwendung zu erstellen: einen Entwickler-Account für die API erstellen, das API-Entwicklungskit herunterladen, eine öffentlich zugängliche Webanwendung (mit einem anderen Entwickler-Account) erstellen, die API erlernen und eine Datenablage für den Zugriff mit der API erstellen. Dies nahm natürlich viele Stunden in Anspruch, nur um anzufangen, und kurz nachdem ich mit der Webanwendung selbst begonnen hatte, bekam ich ein anderes Vorstellungsgespräch und kurz darauf ein Stellenangebot, so dass ich die Arbeit an der Aufgabe einstellte. Es ist verrückt, so etwas als Teil eines Bewerbungsgesprächs zu haben, denn wer will schon all die Zeit und Mühe in die Entwicklung eines Programms stecken, nur um eine kleine Chance zu haben, im Bewerbungsgesprächsprozess weiterzukommen?

Um Ihre Frage direkter zu beantworten, sollten Sie also eine Programmierübung machen? Ja, aber stellen Sie sicher, dass sie so zugeschnitten ist, dass sie das testet, was Ihnen tatsächlich wichtig ist, und nicht eine Tonne Fremdarbeit für den Interviewten erfordert. Wollen Sie etwas über ihr algorithmisches Denken wissen? Geben Sie ihnen ein algorithmisches Problem. Wollen Sie etwas über ihren Codierstil wissen? Geben Sie ihnen ein Codierungsproblem. Wollen Sie etwas über ihren Entwicklungsprozess wissen? Diskutieren Sie ihren Prozess mit ihnen, während sie ein Problem durcharbeiten.

Permettez-moi de commencer par :

• On m'a donné des tests à faire à la maison qui duraient de 15 minutes à 10 heures.
• On m'a donné des tests en ligne à faire.
• On m'a demandé de rédiger la réponse à FizzBuzz et à d'autres tests Internet à la mode sur des tableaux blancs.
• On m'a demandé de parler des plaques d'égout carrées et rondes.

En bref, j'ai traité à peu près de toutes les différentes façons dont les développeurs aiment gérer les interviews. Pour être tout à fait honnête - je doute sérieusement que la grande majorité des personnes qui m'ont interrogé aient compris les résultats potentiels de chacun de ces tests et aient finalement embauché des personnes en leur disant si elles les “aimaient” ou non.

Avant même de publier une offre d'emploi, vous devriez vous asseoir et passer en revue exactement ce que vous essayez d'embaucher et “développeur” n'est pas une réponse, du moins, ce n'est pas une réponse appropriée. Une bonne réponse à cela serait quelque chose comme “expert en domaine hypothécaire”.

Trouver quelqu'un qui peut écrire un peu de code ou chercher sur Google comment appliquer un modèle particulier est trivial par rapport à trouver quelqu'un qui a été dans l'entreprise où vous êtes et qui peut tirer parti de cette connaissance. En d'autres termes, si je recrutais pour une société de documentation hypothécaire, je prendrais quelqu'un qui pourrait parler de la différence entre un prêt fixe de 15 ans et un prêt ARM plutôt que quelqu'un qui pourrait écrire un algorithme de tri à bulles en 2 minutes. La raison en est que les hommes d'affaires “normaux” font toutes sortes de demandes bizarres et que les experts du domaine peuvent plus facilement aller au cœur de ce qui est nécessaire alors que quelqu'un qui ne sait rien ajoutera volontiers des choses inutiles ou rendra l'application vraiment mauvaise.

Pour en revenir aux questions, seulement poser des questions go / no go.

Est-il essentiel que la personne puisse vous dire la différence entre une méthode virtuelle et une méthode abstraite ? C'est possible, mais ce n'est généralement pas le cas. Je parierais qu'une bonne partie des développeurs savent à peine quand utiliser ces mots-clés, mais ce ne sont pas vos superstars, ce sont les simples employés qui ne peuvent pas coder sans les concepteurs visuels.

Est-il essentiel de savoir quand une requête est ouverte pour une injection SQL ? Pour une position Sr - absolument ; pour une position Jr - non. Il s'agit d'un élément qui peut être facilement formé et traité par l'examen du code. D'où la raison pour laquelle vous voulez que le senior le connaisse parfaitement, afin qu'il puisse former les juniors.

Est-il essentiel qu'il connaisse la valeur maximale exacte d'un type de données Int32 ? Pas normalement - ce niveau de connaissance trivial est ce à quoi sert Google ; mais peut-être que votre exigence concerne le codage sur des appareils à mémoire limitée - dans ce cas : absolument.

J'interviewe et j'engage des développeurs. Je n'envoie pas de tests à domicile - c'est trop facile d'avoir l'aide d'un ami. Je n'utilise pas les sites de tests en ligne - étant donné que la notation doit être automatisée, c'est trivial pour le jeu. Je ne demande pas aux candidats d'écrire la réponse à fizzbuzz - presque tout le monde a vu ce test et devrait connaître la réponse par cœur ; tous les autres sont entrés sur le terrain au cours de l'année dernière et sont jr. de toute façon. Je ne pose pas non plus de questions triviales - le fait de pouvoir réciter la réponse signifie généralement que vous avez déjà entendu la question.

Ce que je fais pour interviewer les gens :

• je leur demande de décrire un ou deux projets antérieurs. Tout ce qui m'importe à ce stade, c'est de les mettre à l'aise et de les faire parler. C'est un “go/no go” parce que si je ne peux pas comprendre ce qu'ils disent, je ne peux pas travailler avec eux.

• Je leur pose quelques questions spécifiques sur la technologie qu'ils doivent utiliser. S'il s'agit d'un serveur SQL, je leur demanderai de faire une mise à jour sur une jointure. Si c'est du HTML, je leur donne un fichier html de 10 lignes avec quelques classes css et je leur demande quel est le résultat. Ce sont des questions triviales pour les personnes ayant de l'expérience dans ces domaines et qui éliminent rapidement les prétendants.

• Si je cherche un développeur senior, je poserai des questions sur la connaissance du domaine. Pas des questions de fond, mais plutôt des questions de principe. Si j'ai besoin que vous dirigiez un projet de comptabilité, alors vous feriez mieux d'avoir une bonne connaissance des principes de base de la comptabilité.

• Si je cherche un jeune développeur, alors je lui poserai des questions sur les projets de prédilection. Tout ce que je veux savoir, c'est le type de technologie utilisée. Cela devrait vous donner une idée de ce qu'ils veulent vraiment faire. En d'autres termes, un développeur C# n'est pas susceptible de faire des projets de prédilection en php. Honnêtement, je n'attends pas grand-chose d'un développeur junior, si ce n'est qu'il puisse être formé. S'ils travaillent activement sur un projet de prédilection, je peux les former. S'ils ont besoin qu'on leur dise quoi faire, ils peuvent travailler dans des entreprises beaucoup plus grandes.

Je n'invente pas ces questions à la volée, les réponses potentielles sont étudiées à l'avance et correspondent à un schéma “go/no go”. Si une question ne correspond pas à ce schéma, elle n'est pas pertinente. Je pose également les mêmes questions à tous les candidats, sauf si je suis convaincu à 100 % que je ne les embaucherai pas, auquel cas j'arrête l'entretien.

Si, pour une raison quelconque, vous insistez encore pour renvoyer un test chez vous, assurez-vous que les compétences requises pour réussir ce test dans un délai raisonnable sont en fait des compétences qui vous intéressent.

J'ai demandé à une société de me faire passer un test à domicile qui impliquait de rédiger un fournisseur de services cryptographiques personnalisés. J'ai passé le test parce qu'il était assez intéressant ; ils m'ont engagé. À aucun moment, je n'ai fait quoi que ce soit, même de loin, en rapport avec la sécurité, la cryptographie ou même les mathématiques, à part ajouter quelques chiffres. Je me demande combien de personnes ils ont fait partir avec ce test ?

Je croyais fermement aux tests de codage et au codage de tableau blanc, mais j'ai commencé à réaliser qu'ils sont pratiquement inutiles, parce que

Qu'est-ce que vous testez, de toute façon ?

Un test de tableau blanc, ou un court test de programmation vous donne un aperçu de l'individu, mais pas tant que ça. À moins que vous ne prévoyiez que quelqu'un passe son temps à écrire du code sur un tableau blanc ou du code de style FizzBuzz.

Que voulez-vous vouloir ?

Vous voulez quelqu'un qui soit :

• passionné
• désireux d'apprendre
• capable de résoudre des problèmes _*
• d'une grande technicité
• qui va aider votre équipe à s'améliorer

\NNotez, la plupart des développeurs résolvent leurs problèmes en sachant quels termes rechercher dans Google.

La dernière chose que vous voulez engager est quelqu'un qui ne convient pas à votre équipe parce qu'il la fera glisser vers le bas.

Comment pouvez-vous les tester ?

• Posez-leur des questions sur un projet qu'ils ont apprécié. S'ils semblent réticents à en parler, essayez d'exprimer une douce incrédulité, par exemple : “Vous ne pouvez pas faire X, n'est-ce pas ? Si c'est quelque chose qui les passionne, ils vous corrigeront. Cela vous aidera également à savoir s'ils sont techniques ou non.
• Interrogez-les sur les choses qu'ils ont apprises récemment. Ou sur ce qu'ils ont appris du projet auquel ils ont participé et qu'ils ont apprécié.
• Demandez-leur de vous parler de la dernière fois (ou d'une fois) où il leur manquait certaines connaissances. Comment ont-ils obtenu les informations dont ils avaient besoin ? Sont-ils allés voir un coéquipier ? Ont-ils fait des recherches sur Internet ?
• Demandez-leur s'il y a quelque chose qu'ils souhaiteraient voir amélioré dans leur équipe actuelle/dernière. Ont-ils besoin de meilleurs messages d'engagement ? D'autres révisions de code ? Plus de tests ? Plus d'automatisation ?
• Demandez-leur quelle technologie les passionne et pourquoi.

Si vous avez quelqu'un qui compte techniquement dans cette conversation, ce sera la chose la plus facile au monde de dire si cette personne sera la pire. Un exemple : un enfant est venu nous interviewer - il a dit que sur une échelle de 1 à 10, ses compétences en Java étaient comme un 7-8. Je ne pense pas qu'il savait que Java était compilé en un fichier jar qui a ensuite été compilé en langage machine par la JVM. Je me classerais peut-être sur une échelle de 2 ou 3 et je le saurais.

Notre directeur technique lui a posé la même question lors d'une interview la veille, et il l'a appelée pour lui expliquer qu'il n'était pas possible qu'il soit un 7-8.

Notre directeur technique lui a également demandé quel était son projet préféré, qui concernait les scanners à main. Mais il n'a rien pu nous expliquer sur leur fonctionnement, ni sur le fait qu'ils utilisaient des sondages pour éviter les attentes trop nombreuses. Il n'a pas pu expliquer une seule chose technique.

Ce type n'a pas été embauché.

Trouvez le type d'attributs que vous recherchez, puis trouvez comment tester ceux-là

Mais j'ai vraiment besoin de voir comment elle code !

D'accord, c'est bien - mais à moins qu'elle ne soit en train de coder dans un silo, la meilleure chose à faire sera de l'embaucher comme contractant pour un petit projet bien défini. Peut-être ajoutez-vous la possibilité de télécharger certains fichiers à partir d'un FTP et de les verser ensuite dans votre base de données. Quelque chose de simple, qui ne nécessite pas beaucoup/aucune connaissance du domaine.

Faites travailler vos candidats avec un ou deux employés existants, et payez-les pour leur temps. Vous verrez exactement comment ils travaillent et comment ils collaborent avec l'équipe. Communiquent-ils bien ? Sont-ils facilement frustrés ? Sont-ils persévérants ?

Il y a deux choses que vous pouvez faire pour embaucher de meilleurs employés… mais un concours de programmation n'en fait probablement pas partie.

Du point de vue d'une personne à la recherche d'un emploi, j'évite généralement les lieux qui prennent plus d'une heure à coder. Une fois, je me suis rendu dans un endroit qui a nécessité un projet de codage en Java de près de 3 jours. J'ai tout fait et le gars a même été impressionné par le projet, mais ils m'ont dit qu'ils avaient engagé quelqu'un d'autre après la deuxième étape de l'entretien. Donc, après cela, si je viens dans une entreprise, j'ignore/je passe tout projet qui demande plus de deux heures pour être mené à bien. Mon temps est tout aussi précieux que le leur et je préfère ne pas le gaspiller pour des choses qui ne me mèneront nulle part.

Cela dit, si votre exercice de codage est trop long, peut-être que les gens ne sont pas prêts à y consacrer du temps. J'essaierais de le réduire de telle sorte qu'il prenne une heure au maximum, mais en même temps, cela démontre une compréhension du codage et peut-être en y mettant une date limite comme “Veuillez terminer d'ici la COB demain” ou autre chose. Ils peuvent toujours “copier-coller” quelque chose en ligne, mais ils rendent les choses plus difficiles en étant plus précis que ce que vous lisez en ligne.

Comme d'autres l'ont fait remarquer, certains développeurs peuvent être rebutés par un exercice de programmation d'une à deux heures pour postuler à un emploi. Ce qui peut mieux fonctionner, c'est une séance de tableau blanc, où le candidat résout un problème sur un tableau blanc pendant l'entretien. Cela vous permet d'avoir un entretien en personne tout en vous assurant que le candidat a des connaissances techniques. Ces problèmes ne devraient pas être extrêmement difficiles, ni conçus pour faire trébucher un développeur. Un exemple classique est FizzBuzz . Cela vous permet de voir comment ils pensent, et aussi de savoir qu'ils peuvent au moins programmer et n'ont pas besoin de chercher sur Google comment faire une boucle.

À mon avis, le problème que vous avez ici n'est pas nécessairement le test de programmation. Vous avez d'abord l'entretien technique par téléphone, puis un test de travail à domicile avant un entretien en face à face. On dirait que vous tenez vos candidats à distance et que vous les laissez à la dernière minute avant de les rencontrer. À quel moment pensez-vous que les candidats décideront qu'ils veulent travailler pour vous ?

Je suppose que votre annonce de recrutement est similaire à la plupart des autres et qu'elle se concentre donc sur le lieu de travail, le salaire et une liste de compétences (souhaitées). Les candidats ne savent pas vraiment sur quoi ils travailleraient, ni sur l'environnement ou les personnes avec lesquelles ils auraient à interagir. Vous ne leur avez pas encore vendu le poste et vous leur demandez ici de prouver deux fois leurs capacités techniques avant de pouvoir poser une seule question sur le travail.

Je vous suggère d'essayer de changer le format de l'entretien téléphonique technique pour qu'il soit une conversation de 30 à 45 minutes sur le poste, avec de nombreuses possibilités de questions de la part des candidats, puis 15 minutes de questions techniques comme écran pour que vous puissiez toujours choisir les meilleurs candidats sans que cela soit trop onéreux.

J'envisagerais également de déplacer le défi de programmation pour qu'il soit fait sur place avant les entretiens. Cela semblerait plus réalisable pour les candidats, cela les inciterait à rester sur la bonne voie et vous auriez l'avantage d'observer le temps réellement passé sur le défi (je pense que vous pourriez être surpris).

Voulez-vous engager des programmeurs qui ne savent pas programmer?

Je vais m'aventurer à dire que non.

Engager des programmeurs qui ne peuvent pas réellement résoudre les problèmes et écrire du code est un bon moyen de ruiner une entreprise technologique. Et vous ne serez pas efficace pour éliminer les programmeurs qui ne peuvent pas réellement programmer (et il y en a a beaucoup) si votre processus d'embauche n'inclut pas une sorte de test de programmation.

Etes-vous prêt à abaisser vos normes parce que tout le monde essaie d'embaucher des programmeurs?

Peut-être que vous l'êtes, mais je ne pense pas que vous devriez l'être. Comme il a été noté dans les commentaires et les réponses, il y a des candidats qui ne vont pas se donner la peine de faire des exercices de programmation dans le cadre d'un entretien parce que ils n'en ont pas besoin pour obtenir un emploi.

Mais est-ce que ce sont vraiment les personnes que vous voulez engager de toute façon ? Ceux qui suivent la voie de la moindre résistance, font ce qui leur est le plus profitable à court terme et ne se soucient pas assez de votre entreprise pour faire un simple exercice de programmation ? Ces qualités ne semblent pas être positives et elles ne donnent pas beaucoup d'assurance quant à la capacité de retenir ces candidats à long terme (ce qui est également important pour une entreprise technologique, car les courbes d'apprentissage ont tendance à être raides et le coût de remplacement du personnel existant est très élevé).

Alors laissez ces autres entreprises avoir les programmeurs qui ne peuvent même pas être dérangés. Vous ne voulez pas les engager de toute façon. Contrairement à eux, vous avez un plan. Un qui n'est pas basé sur l'erreur “un programmeur est un programmeur”. Vous devez vous concentrer sur la qualité et la durabilité, et non sur le comptage corporel.

**Est-ce que faire fuir les candidats est un problème ?

Généralement non, tant qu'ils sont effrayés pour une bonne raison. Vous ne voulez pas engager des gens qui ne sont pas à la hauteur. Et certains de ceux qui disent qu'ils “ne peuvent pas être dérangés” en raison de la forte demande pourraient en fait utiliser cette excuse pour dissimuler une situation “pas vraiment très bonne en programmation, il faudrait donc toute la semaine pour faire un exercice d'une heure”.

C'est bon de faire fuir ces candidats. Vous voulez engager les candidats capables et motivés. Tant que vous ne faites pas fuir ces derniers, vous êtes bon.

Chaque candidat que vous ne faites pas fuir est un candidat que vous devez essayer d'évaluer. Et cela peut être difficile à faire si vous ne donnez pas à vos candidats techniques d'exercices techniques à utiliser pour l'évaluation.

**Comment puis-je améliorer notre processus de recrutement ?

Vérifiez le contenu de votre exercice de programmation. Est-il raisonnable et approprié dans un contexte d'entretien ?

Vous ne voulez pas d'un exercice qui va prendre des jours (voire des heures). Ce que vous voulez, c'est quelque chose de simple pour éliminer les personnes qui ne savent pas programmer, idéalement avec suffisamment de place pour les nuances afin que les personnes qui savent très bien programmer puissent se différencier. Gardez à l'esprit ce que vous essayez d'accomplir (éliminer les candidats non qualifiés et non sérieux), et assurez-vous que votre contenu est adapté à cet objectif. Si vous disposez déjà d'un personnel technique, vous pouvez l'utiliser pour vérifier l'équilibre mental (et/ou aider à concevoir) votre exercice. Et réfléchissez également à la manière dont vous administrez l'exercice. Si vous leur donnez juste un peu de documentation et leur dites “ici, faites ceci la semaine prochaine et envoyez-le moi par e-mail”, cela ne sera probablement que d'une efficacité minimale.

Il serait préférable que vous puissiez faire passer l'exercice par un portail web, que les candidats peuvent consulter et démarrer l'exercice, et qu'une fois qu'ils ont démarré, un compte à rebours d'une heure commence. Ensuite, ils peuvent soumettre quelque chose dans cette heure, ou non. Cette méthode est moins ouverte, permet de mieux retenir l'attention du candidat et fournit un délai/un calendrier précis, de sorte que 1) vous n'ayez pas à attendre toute la semaine un résultat qui n'arrivera jamais et 2) les candidats non qualifiés ne perdent pas une semaine de leur temps à essayer de terminer votre exercice de programmation. Ils ont droit à une heure, soit ils résolvent le problème, soit ils ne le font pas, et vous connaissez le résultat immédiatement.

Et le mieux serait encore de les faire venir pour un entretien sur place. Présentez-les à un membre de votre équipe de développement. Enfermez-les dans une pièce avec un poste de travail. Demandez à votre développeur de commencer par quelques questions d'entretien générales/simples, puis il pourra programmer en binôme avec le candidat pour résoudre l'exercice de programmation. Cela vous permettra de savoir non seulement si le candidat sait coder ou non, mais aussi dans quelle mesure il travaille bien avec votre équipe. Votre développeur devrait également être capable de glaner beaucoup d'informations supplémentaires que vous n'obtiendrez pas en regardant un tas de code qu'un candidat a écrit et vous a ensuite envoyé par e-mail.

Résultat final

Non, vous ne voulez pas vous débarrasser de votre exercice de programmation. Mais vous voudrez peut-être le revoir pour vous assurer qu'il a un contenu approprié, qu'il ne prend pas trop de temps à résoudre, et aussi pour voir comment vous l'intégrez dans votre processus global d'entretien.

Un exercice d'auto-apprentissage n'est probablement pas la meilleure approche. Mais la solution n'est pas d'abandonner complètement l'exercice. Mieux vaut effrayer un grand nombre de mauvais candidats et une poignée de bons que d'ouvrir les vannes et d'embaucher quelques mauvais.

Une chose que personne ne semble avoir mentionnée : même si le test n'est pas votre problème, vous devriez chercher d'autres moyens d'attirer des talents.

Si vous recherchez de bonnes personnes sur la base de leurs travaux publiés existants, vous n'avez pas besoin de leur faire passer le test.

Si vous vous contentez d'envoyer des personnes via les recruteurs et le filtrage, vous êtes vulnérable au fait que vos besoins et ceux des recruteurs ne sont pas parfaitement synergiques. Ils veulent placer quelqu'un avec vous. Vous voulez un ingénieur de haut niveau. S'ils peuvent trouver un ingénieur de haut niveau, c'est génial parce que vous reviendrez vers eux, mais s'ils ne le peuvent pas (et les ingénieurs de haut niveau ont tendance à avoir des choses à faire qui laissent peu de temps pour les entretiens), ils se contenteront de placer un ingénieur modéré avec un beau costume. La perte pour eux est un peu la représentation à long terme, mais c'est mineur comparé au fait de manquer leurs cibles. Si cela s'avère faux dans votre cas, gardez ce recruteur et ne le laissez jamais partir (*), les recruteurs qui privilégient une relation à long terme plutôt que des cibles sont des diamants précieux dans un océan de poussière de charbon.

Ce que vous voulez faire, c'est trouver des candidats dont l'intérêt est prouvé. Cherchez des ingénieurs de haut niveau par le biais de StackOverflow et de GitHub (j'ai entendu dire que StackOverflow a un outil pour vous aider dans ce domaine ), vérifiez les entreprises techniquement intéressantes qui ont produit de bons logiciels mais qui ont foiré leurs finances ou leur monétisation, et qui viennent de licencier 10 ingénieurs de haut niveau. Passez du temps à travailler dans les universités pour aider les projets de dernière année. Identifier les bons candidats potentiels et se lier d'amitié avec eux, de préférence en personne, ou à distance ; même s'ils ont des offres, les bons ingénieurs traînent avec les bons ingénieurs. Ils peuvent également vous dire ce qu'ils pensent de votre processus d'embauche.

Cela vous semble beaucoup de travail ? Ça devrait. L'une des raisons pour lesquelles l'embauche semble si “difficile” est que vous essayez de la faire le plus efficacement possible. Plus vous y consacrez de temps, de cerveaux et de ressources, plus c'est facile. L'éternelle question de la gestion est de savoir si ces ressources seraient mieux utilisées pour l'expédition des produits. Mais si vous passez beaucoup de temps à “filtrer les programmateurs de merde”, c'est de l'argent qui brûle. Au moins, les étapes décrites ci-dessus ont une valeur inhérente au-delà du processus d'embauche.

(*) : Diable, les embaucher_.

Je n'aime pas les tests à domicile dans le cadre des entretiens, pour de nombreuses raisons déjà mentionnées : cela prolonge le processus d'embauche, cela dévalorise le temps du candidat, il risque de ne pas être rappelé de toute façon, etc.

Mon principal problème est qu'il est irréaliste par rapport à la façon dont l'équipe travaille réellement et que cela rend le processus d'entretien unilatéral. Un candidat veut savoir si ce lieu lui convient, notamment en ce qui concerne la culture, la façon dont l'équipe aborde et résout les problèmes. Vous recherchez également une adéquation, notamment en ce qui concerne la façon dont ils travaillent et s'ils ont les compétences requises. Un test à domicile ne donne pas au candidat la possibilité d'évaluer les qualités humaines d'un lieu de travail, et les employeurs n'ont pas la possibilité d'apprendre comment le candidat a abordé le problème. Une meilleure solution pourrait être de donner au candidat un problème plus ouvert qui peut être résolu de n'importe quelle manière créative. Vous pourriez même le limiter à la langue X. Plutôt que de l'envoyer par e-mail, invitez-le à le présenter à vous-même et à la direction. Cela leur donne de l'autonomie et les incite à bien faire, car cela promet un autre entretien et montre que vous tenez à savoir ce qu'ils pensent.

Si vous devez utiliser un test pour déterminer quels candidats se présentent à un entretien avec l'encadrement supérieur, j'inclurais le test dans l'entretien afin que vous puissiez discuter ensemble de leur processus de réflexion.

Je pense que vous avez mal formulé votre question, mais la façon dont vous l'avez formulée reflète une idée fausse courante sur l'embauche des programmeurs. Les candidats sont-ils “effrayés” par la tâche de programmation, ou bien filtrent-ils votre entreprise en raison de cette tâche ?

Une anecdote pour démontrer mon point de vue : alors que je cherchais un emploi il n'y a pas longtemps, j'ai vu un poste pour une entreprise qui me semblait moyen. La façon dont ils ont décrit leur processus de programmation semblait assez bonne, mais il y avait très peu de détails, donc j'étais sceptique. Peut-être que c'était un bon endroit pour travailler, peut-être pas. Mais je me suis dit que j'allais voir sur l'écran d'un téléphone pour pouvoir comprendre les détails et voir s'ils étaient aussi bons qu'ils le semblaient.

J'ai cliqué sur l'offre d'emploi et on m'a immédiatement demandé d'écrire une lettre de motivation. Ugh. Je pense que tous les candidats détestent les lettres de motivation. Je ne connaissais pas cette entreprise et je n'utilisais pas leurs produits, alors que pouvais-je dire à leur sujet ? J'ai fait des recherches sur Google, j'ai lu leur site web et leurs offres de produits, j'ai trouvé où je pourrais m'intégrer dans leur organigramme si je suis embauché, et j'ai trouvé quelques paragraphes qui me “vendaient”.

Ensuite, j'ai fourni mon CV et l'accès à mon LinkedIn - mais immédiatement après, on m'a demandé de remplir mon expérience professionnelle pertinente avec des dates et des descriptions. Ces informations se trouvent à la fois sur mon LinkedIn et sur mon CV, il était ridicule de devoir fournir les mêmes informations 3 fois. J'ai fermé l'onglet du navigateur. Cinq minutes plus tard, je posais ma candidature auprès d'une autre entreprise qui offrait des avantages vraiment sympas, ce que la première n'offrait pas. Je pouvais en fait postuler à une autre entreprise offrant de meilleurs avantages plus rapidement que je ne pouvais sauter à travers les cerceaux que la première entreprise voulait me faire passer.

Vous devez vous assurer que vos candidats sont investis dans votre entreprise en particulier avant de leur présenter des cerceaux à sauter, sinon ils ne sautent pas. C'est ce que vous faites ?

Exemples d'avantages de qualité que je vois couramment offerts par les entreprises technologiques :

1. Le travail à distance.
2. Des ordinateurs/moniteurs gratuits comme bonus de signature.
3. L'entreprise contribue à des projets open-source respectés.
4. Remboursement pour la formation professionnelle et/ou les conférences.
5. Déjeuners avec traiteur.
6. Horaires flexibles.
7. Possibilité de travailler avec des technologies nouvelles ou peu familières.
8. “Culture de démarrage” - alias manque de politique/bureaucratie.
9. Capital social de l'entreprise
10. Reconnaissance du nom : votre entreprise ou votre produit est bien connu. Les candidats aiment mentionner leur lieu de travail et entendre les gens répondre par “Oh, génial ! J'aime leurs produits”
11. Objectifs/vision de l'entreprise : caritative ou révolutionnaire. Les candidats aiment écrire des codes qui améliorent la vie des gens.
12. Un salaire supérieur à la moyenne. L'argent couvre une multitude de péchés organisationnels.
13. Cette liste n'est pas exhaustive, mais si votre entreprise n'offre pas un ou plusieurs éléments comme ceux qui figurent sur cette liste, tout obstacle dans votre processus de recrutement pourrait envoyer un candidat à la recherche d'un élément qui le fasse. Disons que, pour une raison quelconque, vous n'offrez pas ou ne pouvez pas offrir des incitations comme celles mentionnées ci-dessus à vos candidats pour les convaincre de passer gratuitement à écrire du code pour vous. Que pouvez-vous faire alors ? J'ai deux alternatives que la plupart des candidats préféreront aux tâches de programmation trop lourdes :

Alternative n°1 - Payez-les à l'heure pour qu'ils effectuent votre tâche de programmation comme s'ils étaient un entrepreneur. Cela les encourage à prendre la chose au sérieux, à la fois pour des raisons professionnelles et parce que… ils sont payés. Cela vous coûte de l'argent, mais il en va de même pour toute forme de recrutement. Si vous êtes vraiment bon, vous pouvez même trouver un moyen pour eux de diagnostiquer et de corriger un bogue réel dans votre code, auquel cas vous obtenez quelque chose d'utile pour votre argent.

Alternative #2 - Ils ont probablement déjà écrit du code gratuitement qu'ils vous montreront si vous le leur demandez. La plupart des programmeurs ont du code sur Github, Bitbucket, des sites de questions-réponses comme Stack Overflow, ou pourraient vous fournir du code qu'ils n'ont pas encore publié.

Pourquoi leur faire écrire du code dont ils ne se soucient pas alors que vous pourriez les laisser partager un projet passionné avec vous à la place ? C'est moins ennuyeux que de lire pour la 100e fois une autre solution au même problème générique. Et comme le code est déjà écrit, cela vous fait gagner du temps, à vous et à votre candidat. De plus, vous pourrez voir quel type de code ils aiment écrire, ce qui vous donnera un aperçu de leur personnalité et de la façon dont ils s'adapteront à la culture de votre entreprise.

En réponse directe à la réponse de Bobo (qui est la réponse acceptée parce que le type l'a écrite et acceptée lui-même, ce qui franchement me paraît un peu pathétique) :

Vous partez d'un postulat totalement faux. Je ne veux pas travailler pour vous. D'où vous vient cette idée que quelqu'un veut travailler pour vous ? Vous n'êtes qu'une des nombreuses entreprises qui proposent un emploi. Je ne veux pas travailler pour vous. Je veux évaluer votre entreprise, et si vous arrivez en tête de toutes les autres, c'est là que je veux travailler pour vous.

Il y a une douzaine d'entreprises où je peux travailler, vous êtes juste quelque part dans la file d'attente. Je regarde d'abord quelles sont les entreprises, je leur envoie mon CV, ils peuvent le lire et être convenablement impressionnés ou non, puis vous avez généralement une conversation téléphonique rapide où ils me montrent qu'ils ont un travail intéressant et je montre que j'ai les compétences, et tout test de codage peut arriver à la toute fin.

Votre test à domicile vous place à la toute fin de la file d'attente. Pour compenser, vous devrez afficher une fourchette de salaire supérieure de 10 000 £ à celle des autres. De toute façon, trouver un emploi prend du temps ; quelqu'un qui en prend dix fois plus est en fin de liste. Si j'ai le choix entre envoyer un CV et avoir un entretien téléphonique avec dix entreprises, et faire des devoirs pour vous, devinez ce que je vais faire.

Donc ce qui se passe, c'est que vous trouvez des candidats qui veulent travailler pour vous parce qu'ils ne trouveront pas de travail ailleurs.

Je pense vraiment que cela peut aider à établir qui connaît vraiment les langues mentionnées sur son CV.

Si c'est vraiment votre objectif, j'envisagerais une approche différente. Comme d'autres réponses l'ont indiqué, OUI, vous devriez toujours avoir une question de codage, mais les questions de codage entrent rarement dans les détails de la langue. Voici quelques questions que j'ai vues et qui sont utiles pour tester ceci :

1. Comparer et mettre en contraste Java et C (ou tout autre langage pertinent, qui figure sur le CV du candidat, etc.)
2. (Ou mieux encore, que pensez-vous de cette proposition ou de ce récent changement de langage)

Les ingénieurs qui ont vu une chose ou deux savent comment répondre à ces questions assez facilement, et en quelques minutes seulement.

Quel est votre problème commercial ?

Si l'on ne tient pas compte de tous les arguments pour ou contre des tests particuliers, tout se résume à un compromis - plus de filtres effraient certains bons candidats, moins de filtres laissent passer les mauvais candidats que vous pourriez avoir à remplacer peu après l'embauche.

Tout se résume à examiner la situation de votre entreprise plutôt que les pratiques générales.

Avez-vous actuellement un problème où vous manquez de candidats qualifiés et êtes incapable d'embaucher aussi rapidement que nécessaire pour atteindre vos objectifs commerciaux ? Vous devez abandonner cette tâche de programmation initiale.

Avez-vous actuellement un problème où vous n'êtes pas satisfait de la qualité de vos récentes embauches ? Vous devez alors mettre en place d'autres filtres comme celui-ci.

Avez-vous les deux problèmes, et les deux sont aussi douloureux l'un que l'autre ? Félicitations, vous avez trouvé le bon équilibre pour ce compromis.

Pour l'IMHO, il n'y a presque aucune chance qu'un jeune diplômé de l'université soit capable de faire un code de programmation difficile à un niveau d'entrée. Si votre test de codage dure une semaine, vous devez clairement mentionner dans votre demande que vous recherchez des programmeurs ayant au moins deux ans d'expérience, car je pense qu'il faut beaucoup d'expérience pour effectuer un travail de codage qui dure une semaine. Et je pense que si vous recherchez de jeunes diplômés, concevez votre test en conséquence et vous pouvez trouver beaucoup d'idées sur Internet ou bien vous pouvez demander à des programmeurs expérimentés travaillant pour vous de concevoir un test adapté aux jeunes diplômés.

J'ai pensé que je répondrais à cette question, cela fait un an qu'elle a été postée, et nous nous y sommes tenus.

Trouvailles

Positifs de l'approche

1) Le test à domicile élimine les candidats démotivés, et les remplace par des candidats qui veulent vraiment travailler pour vous. Rien que pour cela, cela vaut la peine d'être fait, car des personnes motivées = des employés productifs. S'ils ne se donnent pas la peine de faire un travail d'une heure, cela en dit long sur leur attitude à l'égard du travail.

2) Je suis d'accord avec d'autres pour dire que le test à domicile ne devrait pas durer plus d'une heure - le mien est très simple. J'ai obtenu les résultats suivants en l'ajoutant dans le processus de recrutement :

a) Certains candidats ne le passent pas. Il ne vaut pas la peine d'être engagé.

b) Certains candidats tentent de le passer mais le réussissent mal. Ne vaut pas la peine d'être engagé.

c) Certains candidats trichent, et il vaut alors la peine de poser des questions de suivi sur leur affectation. Nous l'avons fait avec un candidat récent qui n'a pas pris la peine de répondre à notre courriel concernant la mission. Cela ne vaut pas la peine d'embaucher. d) Certains candidats, en apprenant qu'il y a une mission technique, retirent soudainement leur candidature, alors qu'auparavant ils montraient beaucoup d'intérêt. Ils ont probablement esquivé une balle.

e) Certains candidats s'en sortent très bien, commentent leur code et, en une ou deux occasions, fournissent des documents. **1) Les candidats qui abandonnent leur candidature parce qu'ils ont été repoussés par la tâche à accomplir à la maison ont plus de temps pour trouver quelqu'un qui leur convienne. MAIS à l'inverse, c'est positif pour l'entreprise car cela réduit la probabilité d'une mauvaise embauche qui est dangereuse.

2) Il n'est pas toujours possible de savoir si quelqu'un a triché, mais c'est pourquoi cela est souvent étayé par un entretien technique téléphonique.

Résultat de cette approche

Un de nos employés que j'ai embauché en utilisant cette approche s'est avéré être un employé vedette. Il travaille toujours pour nous après plus d'un an. Il est fiable et techniquement doué.

Une souris peu familière ou une disposition inattendue du clavier (en particulier Mac contre PC), ou un IDE différent peuvent ralentir considérablement les performances sans différence de compétence. De plus, une application complète nécessite souvent beaucoup de code passe-partout qu'un développeur peut ne pas avoir le temps de taper ou même ne pas se souvenir. Démarrer une nouvelle application complètement à partir de zéro est en fait une tâche très rare ; la plupart du travail se concentre sur l'extension ou l'amélioration du code existant.

Je suggère donc de ne donner que des tâches très courtes et plus soigneusement préparées lors de l'entretien. Le mieux est de demander d'écrire une fonction qui doit prendre des paramètres donnés et retourner le résultat expliqué et je conseillerais de le faire sur papier, en évitant complètement l'ordinateur.

Je les enverrais à un quiz en ligne où l'on peut filtrer les personnes qui n'ont aucune idée. Au début de ma carrière, les chasseurs de têtes m'ont dit : “Vous êtes confronté à des gens qui lisent la boîte et mettent une candidature sur leur CV”. Je suppose que cela peut encore arriver aux jeunes et aux naïfs, mais une fois que vous vous êtes fait avoir lors de quelques entretiens, vous apprenez que c'est un mauvais conseil…

J'ai récemment passé un test à domicile. Il s'agissait d'une application complète qui devait se connecter à un serveur de socket qui devait simuler une alimentation lente. Le client avait une mise à jour dynamique, pouvait annuler le flux, et écrire et lire du XML.

Je veux apprendre les sockets de toute façon car je pense les utiliser pour un serveur de poker que j'écris.

Je voulais apprendre XMLreader et XMLwriter.

Au début, j'ai pensé à l'oublier. Mais ensuite, j'y ai vu une chance de prouver ce dont je suis capable. Je n'ai pas de diplôme de CS, donc je rate des trucs théoriques. Ils m'ont demandé quels étaient les trois piliers de la POO et ont voulu me dire qu'on s'en fichait.

Mon message est que les gens qui veulent ce travail doivent passer le test.