Test de codage de présélection - Combien de temps est raisonnable? [fermé]

MODIFIER

Après beaucoup de réflexion et d'auto-réflexion sur le sujet, j'ai réalisé que la plupart des questions que j'ai soulevées dans cette question ne venaient que d'un point de vue personnel plutôt que professionnel. Par conséquent, les modérateurs ont mis cette question en suspens en raison de la nature très personnelle et subjective du problème dont j'ai essayé de parler. Je pensais reformuler la question, mais je ne pouvais pas vraiment trouver un moyen possible de manifester la question de manière plus objective afin qu'elle puisse faire l'objet d'une discussion où les réponses peuvent être étayées par des preuves ou des références.

Pour ceux qui sont toujours intéressés, j'essaie de résumer la discussion issue de cette question:

• un pré-entretien de 4 heures, un test de programmation hors site n'est pas habituel mais
• beaucoup de gens ont souligné que pour certaines entreprises, vous intervieweriez beaucoup plus longtemps que cela tous ensemble
• c'est notre décision personnelle si nous passons un test ou non, et nous pouvons évaluer cela en fonction de notre situation et des avantages perçus d'être embauché pour l'entreprise
• toutes les entreprises sont différentes, tout comme les gens, et il peut être parfaitement raisonnable pour une entreprise d'utiliser un test hors site plus long avant l'entrevue, si c'est ce qui correspond à ses besoins ou à sa situation

Je voulais que ma question initiale soit de savoir à quel point il est raisonnable d'attendre 4 heures de moi et comment éthique de donner un problème afin que la solution (pas le code, mais la conception) puisse éventuellement être utilisée pour l'entreprise. Comme je peux le voir maintenant, ces deux questions ne peuvent (au mieux) être explorées que dans une discussion de forum, plutôt que d'utiliser un outil communautaire de type question-réponse comme stackexchange.

Cependant, j'ai trouvé toutes vos réponses précieuses et merci du partage.

POSTE ORIGINAL

J'entrevue pour plusieurs postes, et la plupart d'entre eux comprennent une phase de présélection où je dois soumettre un test de codage avant l'entretien téléphonique ou l'entretien sur place. Je me suis à peu près habitué à cette idée, et je trouve tout à fait raisonnable que les entreprises s'attendent à ce que je fasse cela afin qu'elles puissent vérifier quel type de travail je peux produire par moi-même.

Généralement, mon expérience est que ce type d'exercices de codage sont principalement de petites tâches de programmation. Faites de la logique, implémentez peut-être un petit algorithme, ouvrez un fichier et lisez / écrivez des données, des trucs comme ça. Même la tâche la plus simple peut être mise en œuvre avec une belle séparation de la logique, des composants testables, etc., pour voir comment le candidat code, généralement dans quelle mesure il est préparé pour le type de travail qu'une entreprise veut combler.

Récemment, je suis tombé sur une entreprise qui m'a envoyé un test de codage avec une description d'une page entière de leur exercice, me demandant de résoudre un problème réel de leur entreprise (je ne veux pas dire de détails pour protéger l'entreprise, mais le test était à peu près sur ce qu'ils font). Ils ont décrit un système assez complexe à implémenter, comprenaient des données réelles et ont finalement conclu que le test de codage ne devrait pas prendre plus de 4 heures .

Est-il raisonnable de la part d'une entreprise de m'attendre à ce que je passe 4 heures à travailler sur sa mission factice pendant mon temps libre, avant même de me dire bonjour? (le recruteur m'a envoyé le test de codage)

Ne vous méprenez pas, je suis motivé pour trouver un nouvel emploi et de nouveaux défis, mais la plupart des entreprises s'attendent à ce que je passe un maximum de 1 à 2 heures sur une tâche comme celle-ci, et de telles tâches ont toujours été beaucoup moins compliquées.

Ce que je suis venu en conclusion avec cette société, c'est que:

1) Ma motivation n'est pas bonne et ils recherchent probablement quelqu'un d'autre

2) Ils ne respectent pas leurs futurs employés de s'attendre à ce que de si longs tests de codage fassent même sans leur dire bonjour

3) Ils veulent juste donner un des problèmes sur lesquels ils travaillent et voir s'il y a un jeune gars enthousiaste qui le résoudrait gratuitement pour eux (encore une fois, ne vous méprenez pas, je ne suis pas un théoricien du complot mais j'ai entendu de telles histoires ...)

Selon vous, dans quelle mesure une entreprise peut-elle raisonnablement s'attendre à ce que les candidats passent du temps sur leurs tests de codage factices sans leur parler? Quelle est votre expérience en général?

Permettez-moi de prendre le parti de l'entreprise pendant un moment, car les autres réponses ne l'ont pas encore été. Il serait presque impossible de construire une base de code utilisable à partir d'un ensemble de soumissions de tests de codage de 4 heures de personnes dont les qualifications sont complètement inconnues. La création d'une spécification suffisamment détaillée, la vérification des réponses et son intégration au reste de votre code prendraient plus de 4 heures. Sans oublier les projets logiciels les plus utiles au niveau de l'entreprise nécessitent des milliers d'heures de travail. L'idée de bâtir une entreprise en divisant cela en incréments de 4 heures avec des semaines de temps d'exécution chacun est franchement ridicule.

Donner un problème réel de l'entreprise est l'un des meilleurs moyens de déterminer si quelqu'un sera bon, choquant, pour résoudre les problèmes réels de l'entreprise. Je le fais fréquemment dans les entretiens (bien que je demande des principes de conception généraux et non 4 heures de code), et à chaque fois, cela a été un problème que j'ai déjà résolu. Si je ne l'avais pas déjà résolu, le test perdrait presque toute sa valeur probante.

La question de savoir si un test de 4 heures en vaut la peine est une décision personnelle. On m'a toujours appris à considérer la recherche d'un emploi à temps plein comme un emploi à temps plein. Lorsque vous êtes au chômage ou sous-employé et que vous passez 8 heures par jour à chercher du travail, un test de codage de 4 heures n'est rien. J'ai consacré beaucoup plus de temps à des tâches telles que le nettoyage de langues rouillées, l'écriture de programmes de portfolio et la personnalisation de CV pour des postes spécifiques.

D'un autre côté, certains des meilleurs travailleurs ont déjà un emploi rémunéré et ne recherchent que par hasard de meilleures opportunités. Les personnes dans cette situation sont peu susceptibles de passer par le rigamarole d'un test de 4 heures, à moins que l'occasion ne soit excellente. Cependant, c'est le problème de l'entreprise, pas le vôtre.

En ce qui concerne le discernement de ce que signifie l'attitude de l'entreprise envers ses employés, je ne pense pas que vous puissiez vraiment dire quoi que ce soit, à part qu'ils sont probablement fatigués de traiter avec des candidats non qualifiés, à un degré qu'ils sont prêts à jeter sur les bons et les mauvais.

Non, pas typique , pourquoi résolvez-vous leurs problèmes gratuitement? (4 heures)

1 heure est typique pour un test de programmation. Dans le passé, notre test de programmation comportait 4 questions. Les 3 premières questions ont pris 1/2 heure, la dernière 1/2 heure. Nous avons également donné le test aux embauches existantes en interne pour nous assurer que nous étions dans le délai prévu et le test était juste et ajusté en conséquence.

Les premières questions étaient de type "Fizz Buzz" pour éliminer les personnes qui ne pouvaient pas programmer. Ils sont devenus de plus en plus durs. La dernière question était un exercice de résolution de problèmes. Généralement, nous avons essayé de limiter la quantité de code écrit à quelques centaines de lignes (au total) et de ne pas exiger de trucs astucieux. Nous avons également noté des personnes sur la gestion des erreurs, le style, la syntaxe, l'organisation, etc.

En règle générale, les bons candidats ont terminé en moins de temps que prévu. Parfois, les gens ont demandé du temps supplémentaire, ce que nous avons autorisé en raison du stress lié à la participation à un quiz, mais nous avons plafonné tout le monde à une certaine limite. Le quiz était dans l'environnement de développement actuel et les gens avaient accès à Internet pour obtenir des informations de référence. Nous avons également dépassé les attentes du quiz pour chaque candidat.

À un moment donné, nous avons discuté de l'incorporation de notre base de code (monde réel) dans le quiz, mais nous avons finalement rejeté cela en raison de préoccupations concernant le code copié / volé / etc (notre patron était un peu paranoïaque). Finalement, nous sommes juste allés avec un séparé quiz.slndans une machine de développement isolée.

Enfin, nous avons trouvé qu'il était difficile de trouver un test qui soit juste, mais ni trop dur ni trop facile. Nous avons toujours interrogé nos candidats sur le quiz après l'avoir pris et avons recueilli leurs commentaires pour le peaufiner pour les futurs candidats.

Je trouve que les tests de codage en interview sont de toute façon une charge de tosh. Personne ne code autre chose que la routine la plus simple sous pression sans l'environnement et les outils habituels, donc les résultats que vous obtenez sont au mieux douteux.

Ce que j'ai trouvé comme de très bons tests de la capacité d'un programmeur, c'est de lui donner du code de projet et de lui demander de le revoir, cela fonctionne très bien si le code a plusieurs bogues évidents, plusieurs problèmes de code évidents et quelques pratiques douteuses. Un bon codeur vous les expliquera tous et discutera avec vous des raisons pour lesquelles certains codes ne sont pas «incorrects» mais pourraient être améliorés pour faciliter la maintenance. Un mauvais programmeur trouvera un bug et s'arrêtera.

Tout travail qui s'attend à ce que vous fassiez un test qui prend plus d'une demi-heure n'a tout simplement pas passé autant de temps à élaborer un bon test ciblé qui leur donne plus qu'une vague idée de vos compétences. (la plupart des entreprises ont du mal à passer du temps à travailler sur la configuration préalable à l'entretien).

Si on me donnait un test comme vous l'avez fait, j'écrirais la réponse en pseudo-code. Cela devrait être suffisant pour démontrer ma compréhension du codage et de la conception, sans passer par toutes les phases de compilation, de construction et de test que vous feriez pour un projet de travail normal.

Vous n'avez peut-être pas 4 heures, mais quelqu'un plus intéressé par leur entreprise le fera certainement. J'ai été embauché essentiellement sur la base d'une tâche similaire qu'une entreprise m'a demandé de faire au préalable uniquement pour cette tâche. Apparemment, écrire du code propre et compréhensible, des cas de test approfondis et une documentation de conception compréhensible et cohérente est une anomalie. En fait, voir quelqu'un le faire a époustouflé. Quoi qu'il en soit, tous ceux à qui j'ai parlé lors de l'entrevue m'ont félicité pour ce que j'ai fait et j'ai senti que je ne devais impressionner personne dans l'entrevue parce qu'ils avaient déjà pris leur décision. Il s'agissait simplement de ne pas leur donner une raison de dire non en faisant quelque chose de stupide.

Donc, même si je conviens que 4 heures représentent un investissement en temps assez important, cela signifie également que la tâche est de taille suffisante pour que vous ayez l'occasion de vraiment montrer de quoi vous êtes capable. Votre travail peut très bien en dire plus que jamais dans une situation d'entrevue réelle.

En remarque: j'ai essayé une chose similaire récemment mais en utilisant un problème beaucoup plus petit et je ne suis pas satisfait des résultats. Les petits problèmes sont trop triviaux pour démontrer suffisamment les connaissances de la personne. De plus, les problèmes triviaux ont tendance à exiger de la personne qu'elle reconnaisse un truc / détail nécessaire pour résoudre le problème. Ainsi, il y a un certain équilibre entre prendre trop de temps d'une personne et ne pas en retirer de réels avantages car la tâche est trop banale. Je pense qu'une tâche de 4 heures est probablement la bonne quantité de temps pour être suffisamment complexe pour que les candidats démontrent leurs compétences et ne pas être si longue que personne ne s'en soucierait.

J'ai fait un test de codage de 6 heures à un moment donné. Quand j'ai fait ce test, j'avais une confiance assez élevée que je serais embauché - bien que cela se soit réalisé, je n'étais pas du tout satisfait du suivi.

Évidemment, avoir beaucoup d'employeurs qui demandent chacun 4 heures est excessif. Ce que la personne recherchait dans le test que j'ai fait était mon style de codage - j'ai été embauché parce que le mien était «le plus proche» du sien. Dans ce contexte, examinez le problème sous cet angle: premièrement, est-ce un problème intéressant que la résolution vous vaut dans tous les cas? Après tout, vous pourriez apprendre quelque chose de précieux.

Deuxièmement, si vous pouvez «réussir» le test, cela signifie-t-il que vous êtes embauché? Si ce n'est pas assez évident, vous devez décider s'il y a d'autres raisons de le faire de toute façon.

Troisièmement, ils pourraient estimer que cela prend «4 heures», mais vous pourriez découvrir différemment. Savent-ils vraiment combien de temps cela devrait prendre? La réponse est probablement non. Par conséquent, ils vont continuer à tester les gens dans des délais de 4 heures jusqu'à ce qu'ils se rendent compte que cela ne tiendra pas dans quatre heures. Dans ce cas, vous perdez votre temps. La meilleure approche est alors de devenir agressif avec le responsable du recrutement et de déterminer si vous devez vous arrêter à quatre heures et leur donner ce que vous avez, ou continuer jusqu'à ce que ce soit fait et leur dire combien de temps cela a pris. En bref, il peut y avoir un test de caractère enveloppé dans cela, et simplement essayer de l'accepter selon leurs conditions peut révéler l'inexpérience.