Mon travail sur un test de développeur est-il exploité?
Je suis à la recherche d'un emploi et j'ai postulé à plusieurs postes. Un employeur a répondu. J'ai eu un entretien téléphonique assez long (peut-être une heure +) et ils m'ont ensuite mis en place avec un test de développeur. On m'a dit que le test devait durer entre 6 et 8 heures et que, à condition que les résultats soient approuvés, je serais payé pour mon travail.
Cela m'a donné une pause, mais j'ai essayé. Le test du développeur a eu lieu sur un VM accessible via RDP . La tâche consistait à implémenter une page de recherche dans un projet Web qui demande des données au serveur, les affiche à l'écran dans un tableau, a un schéma de filtrage de recherche assez compliqué (il y a environ 15 statuts et lors de l'envoi de la recherche au serveur, vous peut rechercher par ces statuts) en plus de la recherche de chaîne/champ. De plus, ils souhaitent que les icônes SVG changent de couleur sur certaines valeurs de données et que certaines données soient représentées différemment de la façon dont elles sont structurées dans la base de données.
Loooong histoire courte, cela a pris beaucoup plus de 6 à 8 heures. Cela était dû en grande partie au très mauvais VM sur lequel je tournais (Visual Studio 2013 a pris 10 minutes à charger et 15 minutes supplémentaires pour ouvrir la solution ginormous de 3 Go).
On m'a dit qu'après avoir terminé le test, je devrais apporter mes modifications au contrôle de source ... Hmm, OK. J'ai suivi les instructions. Et après avoir validé les modifications, j'ai reçu une réponse par e-mail. Les SVG n'étaient pas bien colorés, il y avait un bug dans cette affaire Edge, il y avait un problème occasionnel avec cette autre chose que je n'avais jamais expérimenté, etc. Donc, je suis 13-14 heures dans cette chose maintenant, et je dois faire des corrections de bugs. Je les fais, et l'employeur revient avec plus de demandes de correction de bogues.
Tout mon travail va apparemment dans une application de production. J'ai remarqué quelques anomalies dans le code où il semblait que d'autres avaient codé toutes les fonctionnalités mais n'avaient rien touché d'autre.
Suis-je simplement utilisé pour une main-d'œuvre bon marché? Même s'ils me paient les 50 dollars promis de l'heure pendant 6 heures, je me suis engagé à peu près 18 heures dans cette affaire maintenant. Si je corrige tous les trucs qu'ils continuent de proposer, j'aurai travaillé au moins 16 heures gratuitement.
J'ai fait un certain nombre de tests de développement, mais je n'en ai jamais pris un au cours duquel j'ai travaillé sur du code destiné à la production. Je n'ai jamais pris de test où j'ai implémenté une fonctionnalité qui était en cours de développement, et je n'en ai jamais pris un qui a pris 4 tours et un total de 20+ heures. J'ai l'impression qu'ils utilisent leur test de développeur pour mettre en place certaines fonctionnalités à bon marché.
Ai-je une mauvaise impression? Et ce protocole de test est-il approprié?
Je ne participerais jamais à un test de code de cette nature. J'ai pris de nombreux tests de code et réalisé de nombreux projets de code. Je ne vérifierais certainement pas le code dans le référentiel de quelqu'un d'autre en aucune circonstance. S'ils ne savent pas ce qu'ils doivent savoir après un échantillon de 4 heures avec quelques corrections de bugs mineurs dans une session de programmation par paire, ils ne le sauront jamais.
En entrant dans un test, vous devez savoir et clarifier certaines choses à l'avance:
- Il convient de convenir et de savoir que tout travail produit pendant le test ne peut être utilisé à d'autres fins que de déterminer vos compétences dans les tâches requises.
- Un test de code ne devrait pas durer plus de 4 heures.
- Vous n'êtes pas un employé de l'entreprise, donc toute suggestion que vous pourriez être payé pour le code produit est absurde. Insistez sur un contrat de paiement écrit s'il y en a même un indice.
- Fixez des limites spécifiques sur le temps que vous passerez sur une partie donnée du test, puis respectez ces limites. Si vous vous trouvez en train de dépasser les limites pour une raison quelconque, demandez-vous pourquoi vous dépassez cette limite. Est-ce à cause de la pression de leur part? Est-ce parce que vous avez fait des erreurs? Est-ce parce que vous avez mal estimé le temps que quelque chose devrait prendre?
- Restez ferme si vous sentez que vous avez couvert un sujet particulier. Si vous avez déjà corrigé un bogue et qu'ils vous demandent de corriger un bogue presque identique, dites "Nous avons déjà couvert ce sujet avec le bogue x, peut-être pourrions-nous passer à autre chose qui démontre quelque chose de nouveau."
- Vous ne devez en aucun cas enregistrer quoi que ce soit dans un pipeline de production. Cela inclut tout type de branche de développement qui peut finalement conduire à un pipeline de production. En cas de doute, n'enregistrez rien. Pour les tests de code qui ne sont pas nécessairement en personne, j'insiste pour que le code soit d'abord enregistré dans mon référentiel public personnel. Cela me donne au moins une sorte de protection contre l'utilisation inappropriée de mon travail.
- Jugez-les autant pour leur comportement qu'ils vous jugent. Si vous sentez qu'ils ne sont pas à vos côtés, appelez-les. Si vous sentez que vous êtes maltraité, parlez.
L'entreprise que vous interviewez est également interviewée par vous. Si c'est ainsi qu'ils traitent une personne qu'ils interviewent, s'agit-il d'une entreprise pour laquelle vous voulez travailler? Je comprends que souvent, les gens ont besoin d'un emploi et souvent ce besoin l'emporte sur certains concepts de bon sens, mais cela devrait toujours être au premier plan de votre esprit. N'ayez pas peur de sortir. Si cela ne vous semble pas correct, suivez votre instinct et votez avec vos pieds.
De nombreux entretiens sont suivis de tests. Ces tests sont nécessaires pour vous assurer que vous avez réellement les compétences requises et pour donner une meilleure vue de certaines choses qui sont difficiles à tester pendant l'entretien lui-même (comme par exemple appliquer des règles de style à votre code).
Cela étant dit, un test est un test.
Ça n'a pas besoin d'être long. Il n'y a pas grand-chose que vous pouvez voir après huit heures de codage que vous ne pouvez pas voir après trente minutes. Plus important encore, le code écrit pendant le test doit ensuite être revu, ligne par ligne, ce qui prend beaucoup de temps. Il n'est pas rare de passer plus de deux heures pour revoir le code de test écrit pendant une demi-heure.
Il ne devrait pas traiter d'une base de code existante. Comprendre la base de code d'un produit de taille moyenne peut prendre des jours ou des semaines (ou des mois ou des années selon la qualité du code et la dette technique). La propriété intellectuelle peut également être un problème (sauf si le code est open source).
Lorsque l'objectif est de tester comment le candidat est capable de maintenir la base de code existante, le test peut être effectué sur une petite base de code fictif (500-600 LOC) écrite spécifiquement pour les tests.
Il n'est pas nécessaire que ce soit une demande pour développer une application ou une fonctionnalité réelle. Il peut s'agir d'un morceau de code complètement inutile, écrit dans le seul but de montrer que vous avez compris le problème et trouvé un moyen élégant de le résoudre.
Cela ne doit pas être parfait. Il y a des bugs? C'est très bien. Prenez-en note pour un nouvel entretien avec le candidat; cela peut être une excellente occasion de voir comment le candidat réagit dans cette situation.
Il n'est pas nécessaire de le faire via RDC sur une machine virtuelle, sauf si vous n'avez pas Visual Studio vous-même. Si le but est de voir vos compétences en codage et en résolution de problèmes, peu importe où faites-vous l'exercice.
Il est hors de question que le code écrit lors de ce test se retrouve dans le contrôle de version de l'entreprise. Pourquoi pollueraient-ils leur contrôle de version avec quelque chose écrit par un candidat?
Pour conclure, lorsque l'on vous demande de passer des dizaines d'heures à écrire du code de production, à résoudre des bugs et à confier votre travail au contrôle de version de l'entreprise:
Soit ils vous utilisent simplement pour implémenter des fonctionnalités gratuitement,
Ou ils ne comprennent vraiment pas comment faire une interview.
Dans les deux cas, cherchez un meilleur endroit pour travailler.
Je ne vais pas écrire une longue réponse, mais je suis sérieusement confus, pourquoi personne ne soulève-t-il la question du droit d'auteur?
En ce qui concerne mon expérience, je n'ai jamais entendu parler d'un accord sur le transfert de la propriété du code d'auteur écrit lors d'un test de développeur à l'autre partie. Si tel est le cas, vous pouvez en fait les poursuivre pour violation du droit d'auteur et les dommages-intérêts accordés peuvent être assez agréables, en particulier aux États-Unis d'après les histoires que j'ai entendues. Et s'ils veulent régler (proposez-le), vous pouvez demander des frais exorbitants pour l'infraction (après quoi ils ne seraient en principe toujours pas autorisés à utiliser votre travail et vous pourriez toujours leur vendre votre travail s'ils étaient toujours intéressés). ).
Les personnes ayant plus d'expérience professionnelle peuvent être mieux en mesure de répondre à cette question, mais personnellement, je ne serais pas très à l'aise avec un test de développement de plus de 20 heures. Il semble qu'ils utilisent l'entretien pour terminer les tâches.
Je suppose que vous n'avez signé aucun document juridique concernant la propriété du code. J'attendrais donc jusqu'à ce qu'ils examinent le code et l'acceptent ou le refusent. Ensuite, s'ils l'acceptaient, je demanderais à être payé à temps plein, plus de 20 heures. Je ne suis pas sûr que je prendrais le paiement uniquement pour les six heures qui ont été initialement suggérées. Si cela va entrer en production, ils devront redéfinir la propriété du code.
À tout le moins, discuter du paiement du code devrait vous aider à décider si vous souhaitez accepter une offre. Je ne voudrais pas accepter une offre s'ils pensaient que vous payer seulement six heures était juste.
Quand j'étais en mesure d'interviewer les développeurs, ces tests étaient courts et simplement "réussissaient ou échouaient", aucun correctif de bogue inclus, même quand il y avait quelques bogues mineurs dans le code. C'est parce que je voulais évaluer les compétences du candidat, pas obtenir un logiciel prêt pour la production.
La situation décrite dans la question ressemble beaucoup à quelqu'un qui essaie d'obtenir quelque chose d'utile gratuitement (ou bon marché).
Je n'ai jamais fait de test de développement depuis plus d'une heure, et ce sont tous des `` énigmes '', un travail pour voir si je peux résoudre des problèmes et atteindre un objectif déclaré dans un délai donné.
50 $ (ou pour moi, 25-30 £) est un tarif de jour assez médiocre, c'est comme demander à un plombier de réparer vos toilettes en échange d'un verre.
Mon conseil, en termes non équivoques, est de bloguer sur votre expérience, en faisant référence à la société par son nom au cas où ils essaient de créer une application entière avec cette technique (les gens recherchent souvent des sociétés sur Google avant de se rendre à l'entretien) et ne laissent pas ça arrive encore. La prochaine fois qu'ils demandent une correction de bogue, vous nommez un taux journalier de conseil (au moins 5 fois ce qu'ils proposent) et faites savoir que les développeurs ne travailleront pas gratuitement.
Être dupe fait malheureusement partie de la vie, mais vous n'avez pas à vous asseoir et à l'accepter.
Alors que vous êtes censé être payé pour (une partie de) votre travail, cela ne ressemble pas à un projet d'essai , cela ressemble à une arnaque pour obtenir du travail bon marché/gratuit. Il se peut qu'il soit destiné à être un projet d'essai, tout simplement pas structuré ou géré très bien.
Mais une gestion si mauvaise qu'elle ressemble à une arnaque est certainement quelque chose que vous devez prendre en considération lorsque vous décidez de prendre le travail ou non.
Un projet d'essai approprié devrait indiquer clairement que
- Ils ont du travail qu'ils désirent avoir fait.
- D'après votre entrevue, ils croient que vous devriez être en mesure de faire le travail.
- L'achèvement réussi du projet ne garantit pas une position.
- Conditions du projet (combien ils paieront, à qui appartient le code, qu'il s'agisse du temps et des matériaux ou du tarif forfaitaire, du temps estimé pour l'achèvement, etc.).
- Le projet sera examiné et des commentaires seront fournis - pas seulement un oui/non pour savoir si vous obtenez ou non le poste.
Les conditions devraient être acceptables pour vous, que vous soyez embauché ou non - si les conditions ne sont acceptables que si elles viennent avec un emploi à temps plein, elles ne sont pas vraiment acceptables.
Juste à titre de comparaison: l'interview pour mon emploi actuel était d'environ 1 heure pour parler de ce que j'ai fait jusqu'à présent et de ce que l'entreprise prévoit de faire et de la façon dont je m'intégrerais. autour, je suppose juste pour voir comment nous nous entendons les uns avec les autres. Ils m'ont payé pour cela en tant que pigiste le même montant que je reçois maintenant en tant qu'employé, donc il n'y a jamais eu une journée complète de travail non rémunéré, encore moins 3 jours.
Si le code est vraiment utilisé en production, je leur enverrais la facture pour les 24 heures que vous avez passées, pas de votre faute si leurs estimations sont fausses. En supposant qu'ils ne vous aient pas permis d'estimer combien de temps cela prendra.
Je ne pense pas qu'ils utiliseraient cela pour obtenir une main-d'œuvre bon marché.
La raison est simple. Après avoir écrit ces tests, ils ont besoin de personnes pour revoir ce que vous écrivez, oui, l'examen du code est beaucoup plus facile que d'écrire le code lui-même, mais cela prend encore beaucoup de temps.
Et puis après cela, ils ont probablement besoin de personnes pour maintenir ces tests, l'expliquer, etc.
Et je ne peux tout simplement pas imaginer une entreprise informatique qui se soucierait d'économiser moins de 100 $, en particulier des entreprises américaines. Ce n'est jamais ainsi que les affaires fonctionnent.
Je suis un grand partisan des tests de code pour les développeurs qui interviewent pour un emploi. Cependant, cela ressemble au test de code de l'enfer ... Les tests de code ne devraient jamais impliquer de code de production. Ils doivent être simples et indiquer qu'aucun des travaux effectués ne sera utilisé par l'entreprise.
De toute évidence, le travail que vous avez fait concernait le code de production. Vous devriez être payé pour tout votre temps - au minimum. Essayez de parler à un avocat et voyez s'il pense qu'il vaudrait la peine de les poursuivre. De nombreux avocats proposent des consultations initiales gratuites. Si une fraude était impliquée, et dans ce cas, cela semble ainsi, vous auriez droit à des dommages-intérêts quadruples, et vous pourriez également obtenir des dommages-intérêts punitifs Nice en plus de cela.
En les poursuivant et en gagnant, vous ferez des gros titres et découragerez cette pratique par d'autres à l'avenir - ce qui sera bénéfique pour tous les développeurs de logiciels à la recherche d'un nouveau poste.
Les tests de codage sont malheureusement une réalité. Cela dit, cela me dérange d'être invité à passer quatre heures sur un test de codage comme condition pour obtenir mon premier dépistage téléphonique. Il est injuste de demander à un candidat d'investir autant alors que l'entreprise a investi si peu dans la relation.
Je suis développeur principal et je peux réussir leur test de codage. Mais je n'y perdrai pas beaucoup de temps à moins que la société ne m'ait manifesté un intérêt personnel. Je ne remplis généralement pas de candidature auprès d'une entreprise avec un grand formulaire de candidature en ligne mal rédigé qui me demande de saisir à nouveau mon CV afin que leur robot mal rédigé puisse bâcler la recherche par mot clé. Je n'accepte généralement pas de terminer un test de codage à moins qu'il ne soit bref ou qu'ils le regardent en direct et me parlent.
Même si elles ne mettent pas votre code en production, une entreprise qui veut que vous passiez beaucoup de temps à taper avant de savoir si vous êtes même une bonne personne est une entreprise qui est à l'aise de profiter de vous. Ils indiquent ce qu'ils veulent que leur relation soit; vous êtes le singe de code. Ils appellent les coups de feu. Et leur processus d'entrevue est conçu pour trouver des personnes qui sont à l'aise avec cette relation.
Ne soyez pas un singe de code. Éloignez-vous.