Comment traiter les tests techniques d'entretien qui sont absurdes (par exemple, une tâche déraisonnablement importante avec un délai court) ?

En s'éloignant d'eux.

GS (Goldman Sachs) voulait un jour que je lui fournisse un petit échantillon de code, qui s'est retrouvé dans un simulateur de carnet d'ordres d'échange. Rien de trop particulier, SAUF qu'ils ont spécifié une couverture de test complète et la QUALITÉ DU CODE DE PRODUCTION. Pour quelque chose d'aussi critique, cela se résume à une semaine de travail pour tester chaque cas de bord, car ce type de code est extrêmement critique.

J'ai envoyé une offre au recruteur et lui ai dit que s'ils ne payaient pas - pas de jeu.

Certaines entreprises ont des idées stupides et mettent en place des tests ridicules. Votre exemple est similaire - il n'y a aucun moyen de le faire en deux heures, si ce n'est en le préparant déjà. J'ose dire qu'il s'agit d'une fraude limite. C'est probablement juste un signe d'incompétence comique.

Rappelez-vous que c'est l'informatique - et que l'informatique est un marché de vendeurs. Des tonnes d'emplois - pas de spécialistes. Comportez-vous ainsi. Ne traitez pas avec des idiots. Je refuse tout travail de codage sans entretiens préalables, car il y a un autre côté : Tous ces projets “intéressants, stimulants” sont toujours les mêmes idiots, encore et encore. Je veux d'abord savoir si je veux perdre MON temps, parce que j'aime bien faire des projets que j'aime, et les recruteurs n'ont aucune idée de ce que sont les projets de nos jours.

N'oubliez pas que lorsqu'une entreprise vous convoque à un entretien, vous l'interviewez également.

Utilisez des tests ineptes comme outil de sélection.

Si le TEST vous donne des objectifs et des délais déraisonnables, sauvegardez ce que vous pouvez attendre du poste.

Ne le prenez pas personnellement, un mauvais test n'est pas un bon indicateur de vos compétences. S'ils disent que votre travail n'était pas assez bon, et que vous savez qu'il l'était, alors il est évident qu'ils ne vous apprécieront pas non plus au travail.

Encore une fois, ce n'est pas vous, c'est eux.

Rétrospectivement, c'est 20/20. Voici ce que vous devriez dire la prochaine fois :

“En règle générale, je ne fais pas de devoirs à emporter à la maison, sauf si je parle d'abord avec le client”

“Êtes-vous le client ? Non, alors mettez-moi en contact avec le responsable de l'embauche du client. Et non, si vous travaillez pour les RH (vous n'êtes pas le client, sauf si vous voulez que je crée une application liée aux RH)”

“Ok, que fait cette personne pour votre entreprise ? Sera-t-elle la personne à qui je rendrai compte si votre entreprise m'engage ? Oui, bien sûr. Je veux parler à cette personne”

Une fois que vous avez enfin parlé à cette personne, vous dites quelque chose comme :

“Ok, avez-vous lu mon CV ? En supposant que le responsable de l'embauche ne veuille toujours pas s'en passer, vous pourriez alors dire :

"Le problème, c'est que je me suis déjà fait avoir.

D'une part, je ne sais pas si je dois simplement construire le projet à partir de zéro, ou si je dois simplement réutiliser une partie du code que j'ai en réserve ? Une fois, j'ai construit le projet à partir de zéro en quelques heures, mais on m'a reproché de ne pas avoir une application prête pour la production.

Et une autre fois, il y a eu un petit décalage entre les versions, et leur informatique n'a pas su comment modifier le fichier de configuration pour faire fonctionner mon projet”

Mais quoi que vous fassiez, ne donnez pas cette explication au recruteur. N'expliquez pas et ne vous justifiez pas auprès du recruteur. Il est inutile d'essayer de vous expliquer à un gardien. Plus vous donnez d'informations à un “gatekeeper”, plus il est probable qu'il les utilisera contre vous, car, de par sa conception, un “gatekeeper” a très rarement le pouvoir de faire des concessions, mais d'un autre côté, son rôle consiste davantage à chercher des raisons de filtrer les candidats.

Donc, en supposant que vous ayez parlé au véritable décideur, le responsable de l'embauche dont vous dépendez, et en supposant que cette personne vous donne de bonnes vibrations, vous pourriez dire :

“Ok, je suis prêt à faire le projet à domicile, mais je préfère être là quand mon projet est installé et évalué.

Pensez-vous que nous pourrions fixer un moment où je pourrais venir avec mon code et nous pourrions le mettre en place ensemble sur une des machines de votre développeur ? ”

“Pourquoi pas mercredi prochain ? […] Vous y serez ? L'un des développeurs sera-t-il également présent ? ”

Mais encore une fois, ne faites cela que si vous obtenez de bonnes vibrations de cette personne. Faites confiance à votre intuition. Si pour une raison quelconque, vous avez l'impression qu'ils utilisent ce projet comme un moyen paresseux de filtrer des dizaines de candidats. Ou si, pour une raison quelconque, vous avez l'impression qu'ils essaient de vous soutirer du travail gratuit pour le mettre en production, s'ils n'acceptent pas les devoirs.

Il en va de même si vous vous présentez et qu'ils ne veulent pas installer/réviser votre projet quand vous êtes là. S'ils veulent que vous fassiez leurs devoirs, ils doivent aussi investir du temps en vous. C'est une preuve de respect mutuel.

Et si pour une raison quelconque, vous n'obtenez pas ce respect. Par exemple, s'ils ont échangé l'ingénieur que vous étiez censé rencontrer avec un responsable des ressources humaines à la toute dernière minute. Soyez poli, mais soyez ferme. Ne leur donnez pas votre projet à emporter. Dites-leur que vous serez heureux de reprogrammer l'entretien et de partir.

Je n'aime pas faire référence à d'autres réponses dans mes réponses, car les réponses doivent pouvoir être comprises par elles-mêmes. Cependant, la réponse la plus votée se résume essentiellement à “L'entreprise est une bande d'idiots”. Fuyez-les". Cela ne donne au PO rien à améliorer sur lui-même, et rien à changer à l'avenir. Je vois des domaines que le PO pourrait améliorer, que l'entreprise ait fait quelque chose de mal ou non, ce que nous ne savons pas vraiment, en tant que répondants, puisque nous n'avons entendu qu'une seule version de l'histoire.

D'après ce que je vois, vous n'avez pas communiqué avant de commencer la tâche que vous croyiez fermement qu'elle ne pouvait pas être faite en deux heures.

Voici la séquence des événements telle que je la vois :

1. On vous a demandé d'effectuer un défi de codage
2. Lorsque vous avez reçu le défi, au lieu de communiquer vos préoccupations, vous avez commencé à coder
3. Vous vous êtes empressé de relever le défi, en prenant des raccourcis
4. Vous avez soumis un projet de mauvaise qualité qui n'a pas fonctionné sans beaucoup de bricolage
5. Après avoir reçu un retour d'information, vous avez commencé à justifier votre travail

Voici comment j'imagine que la société l'a vu :

1. Le candidat a accepté toutes les conditions du défi
2. Le candidat a soumis le projet à temps
3. Le projet n'a pas fonctionné
4. Notre développeur principal a déclaré que le code était de très mauvaise qualité
5. Le candidat a commencé à trouver des excuses pour son travail

Imaginez que vous soyez dans une situation de travail et que votre manager/le chef d'équipe vous demande d'accomplir une tâche dans un délai déraisonnable. Si vous ne communiquez pas immédiatement que vous ne pouvez pas faire autant de travail en si peu de temps, alors tout échec est de votre faute si vous acceptez les conditions initiales. C'est vous qui êtes l'expert, pas eux, et ils comptent sur vous pour communiquer avec eux.

Je ne peux pas souligner combien il est important que les deux parties aient une compréhension commune de la situation. Vous avez eu un écart de compréhension insurmontable parce que vous avez manqué l'occasion de vous en occuper. La prochaine fois que vous avez un problème, communiquez-le immédiatement ou l'autre partie pensera que tout va bien ! Ne pas communiquer des informations importantes, c'est mentir par omission, et toute forme de mensonge est non professionnelle. La façon dont ils réagissent à l'information est de leur responsabilité, pas de la vôtre.

Je vous recommande de lire The Clean Coder : A Code of Conduct for Professional Programmers de Robert C. Martin (Uncle Bob), en particulier :

• Chapter 2 : Saying No
• Chapter 3 : Saying Yes
• Chapter 10 : Estimation
• Chapter 11 : Pressure

Si l'entreprise rejette votre candidature parce que vous avez demandé un retour d'information et des éclaircissements avant de commencer la tâche, elle ne vous a pas écarté, _vous les avez écarté en tant qu'entreprise pour laquelle vous ne voulez pas travailler.

J'ai rencontré des tests intelligents et des tests stupides (SQL/BI) et j'ai activement quitté un test qui était stupide, en expliquant que ce qu'ils voulaient était la mauvaise approche.

J'ai également vu des tests qui étaient en fait des tentatives de projet libre, avec un “travail d'échantillon” qui était essentiellement une nouvelle solution. Encore une fois, j'ai refusé de les réaliser.

Il arrive que je m'en remette à l'expérience et que je passe à autre chose. Je programme toujours les entretiens en dehors des heures de travail, donc il n'y a pas de perte réelle de ma part.

Soit ils ne savent pas ce qu'ils font, alors vous en apprendrez beaucoup sur l'entreprise, soit ils veulent s'assurer que vous ne perdez pas de temps (l'argent de l'entreprise) à mal faire les choses au lieu de parler à la personne qui n'a pas les connaissances techniques pour juger de cela.

Il y a deux résultats : vous passez haut la main pour avoir fait ce qu'il fallait faire, ou vous avez évité la balle et vous n'avez pas à revenir dans deux mois pour nous dire comment votre patron exige des choses impossibles ;)

Voici mon approche :

1. Communiquez à votre contact dans l'entreprise que vous pensez que ce n'est pas possible dans le temps, et ce que vous comptez faire réellement.

2. Si vous avez le temps d'attendre une réponse, attendez ; sinon, faites ce que vous aviez l'intention de faire et documentez vos choix en détail

3. Idéalement, faites un croquis de l'endroit où vous emmèneriez le reste

Notez que très peu d'enquêteurs calibrent et testent réellement qu'une tâche prend 2 heures. Si vous voulez vraiment l'emploi, amenez-le à un certain niveau de complétude dans un laps de temps donné.

Comme vous l'avez découvert, la qualité l'emporte généralement sur l'adaptation dans le temps, à moins qu'ils ne disposent de mécanismes stricts pour garantir que tous les candidats s'adaptent dans le temps.

Ce test sent le faux pour cartographier votre personnalité, en particulier la façon dont vous gérez les événements absurdes et stressants. Êtes-vous le genre de personne qui

1. s'énerve et s'en va ou
2. qui essaie en silence d'arranger les choses ou
3. qui essaie en fait de discuter et d'expliquer à la direction ce qui n'est pas raisonnable ou
4. qui est si stressée que vous ne savez pas quoi faire ou
5. qui prétend essayer d'arranger les choses mais qui donne des résultats tout aussi absurdes parce que c'est exactement ce que mériterait toute personne qui s'attellerait à une telle tâche ?

Je suis d'avis que personne n'oserait jamais prétendre que cela représente deux heures de travail, si c'est fait correctement. Je mettrais au moins quelques jours pour que l'architecture soit correcte, etc.

Je vous demande pardon, mais vous passez à côté de l'essentiel.

Pensez-y du point de vue de l'équipe. Ils veulent quelqu'un qui connaisse bien ASP.NET, MVC, REST, qui parle à une base de données et la fonction modérément avancée d'une boîte de texte à saisie automatique.

Est-ce que je pourrais I faire ces choses ? Oui, éventuellement. Après tout, j'ai entendu toutes ces choses, alors je pourrais les énumérer sur mon CV. Un expert comme vous sera capable de mettre en place un système de travail dans les délais impartis parce que vous vous occupez de cette pile tout le temps, mais je devrais passer des heures à fouiller dans les manuels.

Un CV est un morceau de papier où il est trivial d'énumérer des points. Une mauvaise embauche est pire que pas d'embauche du tout. Je suppose que vous n'avez pas eu de recommandation personnelle de quelqu'un de l'équipe, donc le responsable de l'embauche cherche une démonstration de compétence. Il est vrai qu'un vrai système prêt pour la production prendrait beaucoup plus de temps, mais le test ne demandait pas d'être prêt pour la production car il demandait ce que vous auriez fait avec plus de temps. La réussite du test montre que vous maîtrisez toutes les couches et surtout que vous savez comment établir des priorités. Faites en sorte que ça marche et alors que ce soit joli !

Un test de deux heures n'est pas le moment de faire de l'architecture astronautique.

De plus, vous n'êtes presque certainement pas le premier candidat à voir ce test. L'équipe a utilisé et peut-être modifié son filtre à plusieurs reprises, et au moins un développeur a réussi. Le fait de lever le nez - comme c'est devenu très à la mode ces dernières années - dans une juste indignation ou de leur “apprendre” pourquoi c'est un mauvais test vous placera, selon eux, dans la catégorie des bozos. Ouf ! ils penseront, un autre procrastinateur ou primadonna avec qui nous n'avons pas à traiter.

Comment gérer cela ? Regardez les choses du point de vue de votre client potentiel. Plutôt que d'écarter l'idée comme absurde, donnez le bénéfice du doute. Pour un test de deux heures, notez brièvement vos hypothèses, présentez les arguments en faveur d'une simple démonstration et, dans le temps qui reste, expliquez comment vous pourriez rendre un vrai système robuste.

Comme d'autres réponses l'ont au moins laissé entendre, la motivation derrière le test pourrait être raisonnable, en particulier si le test :

1. est bien adapté aux exigences réelles du poste ;
2. Minimise les éléments moins importants ;
3. N'est clairement pas une tentative d'obtenir un “travail gratuit” ; et éventuellement

4. A un emploi précédent, j'ai conçu et administré un test de programmation dont on peut dire qu'il est “absurde”. Il s'agissait toujours d'un poste de développeur ASP.NET/SQL Server de haut niveau, et la tâche consistait à créer une application web très basique comprenant une page et deux ou trois procédures stockées simples. Le candidat a effectué le test sur place en utilisant des outils standard :

5. Visual Studio (version du choix du candidat parmi les deux ou trois versions précédentes) ;

6. SQL Server Management Studio ; et

7. Un navigateur web, non seulement pour le test mais aussi pour la recherche de documentation, de ressources, etc, que j'ai spécifiquement indiqué aux candidats qu'ils étaient autorisés à faire.

J'ai fourni au candidat une solution “shell” de base (dans chacune des versions autorisées de Visual Studio), et j'ai créé la base de données et les tableaux à l'avance.

J'ai donné au candidat une description d'une page et lui ai dit que je reviendrais dans dix minutes pour répondre à toute question à ce sujet, après quoi elle aurait une heure pour terminer la tâche.

Lorsque je suis revenu au bout de dix minutes, après avoir répondu à toutes les questions, j'ai dit au candidat que s'il n'était pas sûr de pouvoir terminer chaque partie de la tâche dans l'heure, il pourrait envisager de se concentrer sur une partie de la tâche qu'il pourrait terminer et se mettre à courir dans le temps imparti. J'ai également mentionné que si elle avait d'autres questions à poser pendant l'heure, elle pourrait me trouver à deux cabines de là et me les poser.

Comme j'ai passé le test, je pourrais le terminer du début à la fin en quarante-cinq minutes environ. Je ne m'attendais absolument pas à ce que les candidats terminent l'ensemble du test en une heure. Cette limite de temps “absurde” était en place pour trois raisons :

1. Nous voulions voir si le candidat avait ne serait-ce qu'une demi-définition raisonnable des exigences du poste. N'oubliez pas qu'il s'agissait d'un poste de haut niveau. (Bien plus de la moitié du temps, la réponse était “non”)
2. Le candidat devait être capable d'analyser les exigences de base et de les répartir en tâches distinctes et gérables.
3. La prolongation du test au-delà d'une heure prendrait plus de temps au candidat sans nous donner beaucoup, voire aucune information supplémentaire.

A la fin de l'heure, j'ai demandé au candidat de me montrer ce qu'il avait, s'il avait une partie d'une solution en cours d'exécution à démontrer, etc. À ce stade, nous prenions généralement environ cinq minutes pour passer en revue le travail, puis le candidat avait un entretien individuel avec le responsable. Au cours de cet entretien, l'équipe de développement examinait tous les éléments présentés par le candidat. Nous nous réjouissions de cette tâche, car elle n'était jamais ennuyeuse.

Si le candidat disposait d'une solution en cours d'exécution qui permettait de gérer la partie de la tâche globale à laquelle il était destiné, il était presque certain qu'il réussissait cette phase de l'entretien. Même si la solution ne fonctionnait pas encore, si nous pouvions constater des progrès substantiels et des preuves de la compétence du candidat, nous prenions généralement en considération le candidat. Nous avons toujours vérifié l'historique du navigateur du candidat pour voir quelles ressources il avait consultées.

Parmi les raisons pour lesquelles les candidats réels n'ont pas réussi, on peut citer :

1. Ne rien produire littéralement après une heure complète. Je suis triste de dire que cette situation s'est produite à plusieurs reprises.
2. Plagier le code du poste actuel du candidat et essayer (et échouer) de le modifier pour répondre aux exigences du test. Lorsque nous nous en doutions, l'historique du navigateur nous le donnait.
3. Incapacité de former une chaîne de connexion pour relier l'application à la base de données. Cela peut sembler un peu injuste, mais souvenez-vous que nous recherchions des candidats de haut niveau, y compris une expérience de haut niveau dans le développement de SQL Server. Nous ne nous attendions certainement pas à ce que le candidat se souvienne de la façon de construire une chaîne de connexion, mais nous nous attendions à ce qu'il soit capable de la consulter rapidement. ConnectionStringBuilder aurait également été parfait, mais personne ne l'a jamais utilisé. Le tout premier exemple de https://www.connectionstrings.com/sql-server/ aurait très bien fonctionné.

Il y avait une autre partie de l'entretien avec le responsable et l'équipe de développement ensemble, et nous posions des questions sur la solution du candidat, comment il aurait abordé le reste du projet, etc.

En résumé, je conseille de considérer les motivations de l'employeur pour un test “absurde” avant de le rejeter d'emblée.

Cette réponse ne dit pas si ce genre de tests est une bonne chose ou non (ou si je les tolère), mais se concentre sur la question spécifique suivante : comment puis-je décider si je dois passer des tests techniques que je considère comme absurdes (e. Comment puis-je décider si je dois me soumettre à des tests techniques que je considère absurdes (par exemple, une tâche déraisonnablement grande avec un délai court) à l'avenir ?

Comme vous le feriez dans le monde réel :

• Communiquez combien de temps la tâche prendrait raisonnablement.
• Établissez votre plan de ce que vous devez faire dans le temps imparti (c'est-à-dire en faire moins, ou le faire pire, ou les deux).
• Faire le plus possible, au niveau de qualité le plus bas que vous pouvez supporter. Concentrez-vous sur l'obtention d'une solution de travail avant une solution complète.
• Documentez clairement les domaines dans lesquels vous prenez des raccourcis, les implications et les TODOs qui en résultent.

Tout cela m'aiderait grandement, en tant qu'employeur ou client, à juger si je veux travailler avec vous.

Selon la structure de gestion de l'employeur/client, le type qui vous emploie (c'est-à-dire votre patron/client direct) pourrait très bien être dans une position où il ne peut pas influencer le type de travail que vous obtenez. La gestion matricielle existe… dans ce cas, je préférerais avoir quelqu'un qui peut gérer de telles situations avec grâce plutôt qu'un héros qui délivre le plus grand code de tous les temps, mais qui n'est pas capable de communiquer sur les limites de temps/qualité.

La mesure exacte de la nécessité d'aller vers plus de qualité, ou vers plus de contenu, dépend. Par exemple, dans votre cas, vous serez probablement plus intéressé par le fait qu'ils voient que vous pouvez fournir un travail de qualité. Vous pouvez donc supprimer quelques fonctionnalités (en utilisant des caractères de remplacement, etc.), mais maintenir la qualité de votre code à un niveau élevé. De même, si le travail était, par exemple, lié à la sécurité, vous feriez de même. Mais s'il s'agit d'une preuve de concept totalement dénuée de toute critique, alors on pourrait aller dans l'autre sens. Documentez tout cela (de manière succincte), et vous êtes sur la bonne voie.

PS : J'aime éviter les jugements “fous ou mauvais”. C'est-à-dire que vous ne devez pas vous soucier de savoir si le client est simplement fou, ou s'il cherche à vous avoir (c'est-à-dire à vous faire exécuter un travail gratuitement), en jugeant uniquement sur l'ampleur de la tâche. La quantité réelle qui compte pour vous est votre temps, et cela a été fixé. Tant que vous êtes d'accord pour consacrer ces deux heures à un nouveau client potentiel, peu importe que la tâche soit facile à accomplir, qu'il s'agisse d'un travail sous haute pression ou de deux heures de bavardage au bureau.

Il n'y a absolument rien qui cloche avec le test technique de 2 heures de folie. Tous les autres candidats devraient faire le même test, donc votre probabilité de vous voir proposer le poste n'est pas différente d'un exercice de programmation facile pour débutants. Il n'y a pas eu de biais ; on vous a demandé de le faire simplement parce que vous aviez postulé pour le poste.

Vous êtes le vendeur sur le marché de l'emploi, et il vous incombe de satisfaire au mieux les acheteurs. Vous avez peu de pouvoir de négociation, si ce n'est que vous avez postulé à un autre poste. Il est certain qu'un test de programmation que **tous les candidats devraient passer n'est pas déraisonnable, que vous puissiez ou non le concurrencer. Si vous êtes hautement qualifié pour le poste, mais que vous ne pouvez pas passer le test, les autres candidats ne pourront pas non plus le passer. Quel est donc le problème ?

Vous faites de votre mieux. Vous êtes en colère de ne pas avoir été proposé pour le poste ? L'entreprise doit embaucher quelqu'un, donc quelqu'un d'autre aurait pu faire un meilleur travail. Le but d'un test de programmation impossible est de trouver le meilleur candidat. Que le meilleur candidat fasse l'exercice n'a aucune importance.

comment puis-je décider si je dois passer des tests techniques que je considère absurdes

Vous devriez vous sentir à l'aise pour n'importe quel test technique si vous pensez que vous avez les compétences pour le poste et que tous les autres candidats devraient le faire. Ne faites jamais un test absurde si vous pensez qu'il s'agit d'une tentative d'emploi de programmation libre et/ou qu'il vous a été donné en raison d'un préjugé (par exemple, le racisme)

PS : je n'ai jamais mentionné qu'OP n'est pas “assez bon”. @TessellatingHeckler