Mon travail sur un test de développeur est-il exploité? [fermé]

Je suis à la recherche d'un emploi et j'ai postulé à plusieurs postes. Un employeur a répondu. J'ai eu une entrevue téléphonique assez longue (peut-être une heure ou plus) et ils m'ont ensuite fait passer un test de développeur. On m'a dit que le test devait durer entre 6 et 8 heures et que, si les résultats étaient approuvés, je serais rémunéré pour mon travail.

Cela m'a donné une pause, mais j'ai essayé. Le test du développeur a eu lieu sur une machine virtuelle 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 existe environ 15 états et lors de l’envoi de la recherche au serveur peut rechercher par ces statuts) en plus de la recherche de chaîne / champ. En outre, ils souhaitent que les icônes SVG changent de couleur pour certaines valeurs de données et que certaines données soient représentées différemment de la structure de celles-ci dans la base de données.

Loooong histoire courte, cela a pris beaucoup plus de temps que 6-8 heures. Cela était en grande partie dû à la très mauvaise machine virtuelle sur laquelle je travaillais (le chargement de Visual Studio 2013 était de 10 minutes, et de 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 enregistrer mes modifications dans le 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 courrier électronique. Les SVG n'étaient pas colorés correctement, il y avait un bug dans cette affaire, il y avait un problème occasionnel avec cette autre chose que je n'avais jamais vue, etc. Donc, cela fait 13-14 heures maintenant, et je dois faire des corrections de bugs. Je les fais et l'employeur revient avec plus de demandes de corrections de bugs.

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 sans toucher à autre chose.

Suis-je simplement utilisé pour une main-d'œuvre bon marché? Même s’ils me paient les 50 dollars de l’heure promis pendant 6 heures, je me suis engagé à peu près 18 heures à ce projet. Si je répare tous les problèmes qu'ils rencontrent, j'aurai travaillé au moins 16 heures gratuitement.

J'ai pris un certain nombre de tests de développeur, mais je n'en ai jamais pris au cours de laquelle j'ai travaillé sur du code destiné à la production. Je n'ai jamais fait de test dans le cadre duquel j'ai implémenté une fonctionnalité en cours de développement et je n'en ai jamais eu une qui a pris 4 tours et un total de plus de 20 heures. J'ai l'impression qu'ils utilisent leur test de développeur pour proposer certaines fonctionnalités au meilleur prix.

Ai-je la 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 voudrais certainement pas vérifier 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 une correction de bogue mineur lors d'une session de programmation en paire, ils ne le sauront jamais.

Pour commencer un test, vous devez savoir et préciser quelques points à l’avance:

1. Il convient de convenir et de savoir que tout travail réalisé pendant le test ne peut être utilisé à des fins autres que la détermination de vos compétences dans les tâches requises.
2. Un test de code ne devrait pas durer plus de 4 heures.
3. Vous n'êtes pas un employé de la société. Toute suggestion de vous payer pour le code produit est donc absurde. Exigez un contrat de paiement écrit s’il ya un soupçon.
4. Fixez des limites spécifiques sur le temps que vous passerez sur une partie donnée du test, puis respectez-les. Si vous vous rendez compte que vous dépassez 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 commis des erreurs? Est-ce parce que vous avez mal estimé combien de temps il faudrait quelque chose?
5. Restez sur vos positions si vous estimez avoir couvert un sujet particulier. Si vous avez déjà corrigé un bogue et qu'on vous demande de corriger un bogue presque identique, dites: "Nous avons déjà couvert ce sujet avec le bogue x, nous pourrions peut-être passer à autre chose qui démontre quelque chose de nouveau."
6. En aucun cas, vous ne devez vérifier quoi que ce soit dans un pipeline de production. Cela inclut toute branche de développement susceptible de déboucher sur 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 une utilisation inappropriée de mon travail.
7. Jugez-les pour leur comportement autant qu'ils vous jugent. Si vous sentez qu'ils ne sont pas à l'avant avec vous, appelez-les. Si vous sentez que vous êtes maltraité, parlez.

La société avec laquelle vous interviewez est également interrogée par vous. Si c'est ainsi qu'ils traitent quelqu'un qu'ils interviewent, s'agit-il d'une entreprise pour laquelle vous souhaitez travailler? Je comprends que souvent les gens ont besoin d’un emploi et que ce besoin l’emporte sur certains concepts de bon sens, mais cela doit toujours être à l’avant-plan de votre esprit. N'ayez pas peur de sortir. Si cela ne vous convient pas, 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 idée de certaines choses difficiles à tester pendant l'entretien lui-même (par exemple, appliquez-vous 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 puissiez voir après huit heures de codage et que vous ne pouvez pas voir après trente minutes. Plus important encore, le code écrit pendant le test devrait ensuite être examiné, ligne par ligne, ce qui prend beaucoup de temps . Il n'est pas inhabituel de passer plus de deux heures à réviser le code de test écrit pendant une demi-heure.

• Cela ne devrait pas traiter avec une base de code existante. Comprendre la base de codes d'un produit de taille moyenne peut prendre des jours, voire des semaines (ou des mois, voire des années, en fonction de la qualité du code et de la dette technique). La propriété intellectuelle peut également être un problème (sauf si le code est à source ouverte).

  Lorsque l'objectif est de vérifier dans quelle mesure le candidat est capable de conserver la base de code existante, le test peut être effectué sur une petite base de code fictive (500 à 600 LDC) écrite spécifiquement pour les tests.

• Il n'est pas nécessaire de demander à développer une application ou une fonctionnalité réelle. Ce peut être un morceau de code complètement inutile, écrit dans le seul but de montrer que vous avez compris le problème et trouvé une façon élégante de le résoudre.

• Il n'est pas nécessaire que ce soit parfait. Il y a des bugs? C'est très bien. Prenez-en note pour un autre entretien avec le candidat; Ce peut être une excellente occasion de voir comment le candidat réagit dans cette situation.

• Cela ne doit pas nécessairement être effectué via RDC sur une machine virtuelle, à moins que vous n'ayez vous-même Visual Studio. Si le but est de voir vos compétences en matière de codage et de résolution de problèmes, peu importe où vous faites l'exercice.

• Il est hors de question que le code écrit lors de ce test se retrouve dans le contrôle de version de la société. Pourquoi pollueraient-ils leur contrôle de version avec quelque chose écrit par un candidat?

En conclusion, lorsqu'on vous demande de passer des dizaines d'heures à écrire du code de production, à résoudre des bugs et à valider votre travail pour le contrôle de version de l'entreprise:

• Soit ils vous utilisent simplement pour implémenter des fonctionnalités gratuitement,

• Ou alors, ils ne comprennent pas vraiment comment faire une interview.

Dans les deux cas, cherchez un meilleur lieu de travail.

Je ne vais pas écrire une longue réponse, mais je suis sérieusement confus. Pourquoi personne ne soulève la question du droit d'auteur?

En ce qui concerne mon expérience, je n'ai jamais entendu parler d'un accord en vue de transférer à un tiers les droits d'auteur du code écrit lors d'un test de développeur. Si tel est le cas, vous pouvez les poursuivre en justice pour violation du droit d'auteur et les dommages-intérêts accordés peuvent être très intéressants, notamment aux États-Unis d'après les récits que j'ai entendus. Et s’ils veulent régler (vous proposez cela), 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 pourrez toujours leur vendre votre travail s’ils seraient toujours intéressés. ).

Les personnes plus expérimentées peuvent mieux 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. On dirait qu'ils utilisent l'entrevue pour mener à bien leurs 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 nient. Ensuite, s’ils l’acceptaient, je demanderais à être payé plus de 20 heures à plein temps. Je ne suis pas sûr de prendre le paiement pour seulement les six heures proposées à l'origine. Si cela doit entrer en production, ils devront redresser 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.

Lorsque j'étais en mesure d'interviewer les développeurs, ces tests étaient brefs et ne contenaient que "succès ou échec", sans correction de bugs, même s'il y avait quelques bugs mineurs dans le code. C'est parce que je voulais évaluer les compétences du candidat et non pas obtenir un logiciel prêt à la production.

La situation décrite dans la question ressemble beaucoup à une personne qui cherche à obtenir quelque chose d’utile gratuitement (ou à bon marché).

Je n'ai jamais fait de test de développement plus d'une heure, et ce sont tous des «casse-tête», un travail qui vise à déterminer si je peux résoudre les problèmes et atteindre un objectif déclaré dans un délai imparti.

50 $ (ou pour moi, 25-30 £) est un taux assez médiocre, c'est comme si vous demandiez à un plombier de réparer vos toilettes en échange d'un verre.

Mon conseil, en termes clairs, 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 complète avec cette technique ça arrive encore. La prochaine fois qu'ils demanderont une correction de bogue, vous nommerez un tarif journalier (au moins 5 fois ce qu'ils proposent) et signalez que les développeurs ne fonctionneront pas gratuitement.

Malheureusement, être dupe fait partie de la vie, mais vous n'avez pas à vous contenter de l'accepter.

À titre de comparaison, l’entretien pour mon poste actuel durait environ une heure et parlait de ce que j’avais fait jusqu’à présent, de ce que la société envisageait de faire et de la place que je prendrais. Après cela, nous avons travaillé ensemble une semaine sur un petit projet qu’ils mentaient. tout autour, je suppose juste pour voir comment on s'entend bien. Ils m'ont payé pour cela en tant que pigiste le même montant que celui que je reçois maintenant en tant qu'employé. Il n'y a donc 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 votre faute si leurs estimations sont fausses. En supposant qu'ils ne vous aient pas laissé estimer le temps que cela prendra.

Bien que vous soyez censé être payé pour (certains) de votre travail, cela ne sonne pas comme un projet d'essai , cela ressemble à une arnaque pour obtenir du travail bon marché / gratuit de vous. Il peut être qu'il était destiné à être un projet d'essai, mais pas structuré ou très bien géré.

Mais une gestion tellement mauvaise que cela ressemble à une arnaque est certainement quelque chose que vous devriez prendre en considération lorsque vous décidez de prendre le poste ou non.

Un projet d’essai approprié devrait préciser que

• Ils ont un travail qu'ils souhaitent avoir fait.
• Sur la base de votre entretien, ils pensent que vous devriez être capable de faire le travail.
• La réussite du projet ne garantit pas une position.
• Termes du projet (combien ils paieront, à qui appartient le code, qu’il s’agisse de temps et de matériaux ou d’un taux forfaitaire, le temps nécessaire à l’achèvement, etc.).
• Le projet sera examiné et les commentaires fournis - pas seulement un oui / non pour savoir si vous obtenez ou non le poste.

Les conditions devraient vous être acceptables, que vous soyez ou non embauchés - si les conditions ne sont acceptables que si elles occupent un emploi à temps plein, elles ne sont pas vraiment acceptables.

Je ne pense pas qu'ils utiliseraient cela pour obtenir une main-d'œuvre bon marché.

La raison est simple. Une fois que vous avez écrit ces tests, ils ont besoin que les gens révisent ce que vous écrivez. Oui, réviser le code est beaucoup plus facile que d'écrire le code lui-même, mais cela prend encore beaucoup de temps.

Et après cela, ils ont probablement besoin de personnes pour entretenir ces tests, les expliquer, etc.

Et je ne peux tout simplement pas imaginer une entreprise informatique qui se soucierait d'économiser moins de 100 dollars, en particulier des entreprises américaines. Ce n'est jamais comme ça que les affaires fonctionnent.

Je suis un fervent partisan des tests de code pour les développeurs qui interrogent un emploi. Cependant, cela ressemble au test de code de l'enfer ... Les tests de code ne doivent jamais impliquer du code de production. Ils doivent être simples et indiquer qu'aucun travail effectué ne sera utilisé par l'entreprise.

Clairement, le travail que vous avez fait était sur 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 serait utile de le poursuivre en justice. De nombreux avocats offrent des consultations initiales gratuites. Si une fraude était en cause, et dans ce cas-ci, il semblerait que vous auriez le droit de quadrupler les dommages-intérêts en argent et que vous pourriez également obtenir de bons dommages-intérêts punitifs en plus de cela.

En les poursuivant en justice et en remportant la victoire, vous ferez la une des journaux et découragerez d'autres à l'avenir, ce qui profitera à tous les développeurs de logiciels à la recherche d'un nouveau poste.

Les tests de codage font malheureusement partie de la vie. Cela dit, cela me dérange de me demander de passer quatre heures à un test de codage pour pouvoir passer mon premier test de téléphone. Il est injuste de demander à un candidat d'investir autant alors que l'entreprise a si peu investi dans sa relation.

Je suis un développeur senior et je peux réussir son test de codage. Mais je ne perdrai pas beaucoup de temps là-dessus, à moins que la société ne montre un intérêt personnel pour moi. En général, je ne remplis pas de candidature pour une entreprise avec un gros formulaire mal rédigé en ligne qui me demande de ressaisir mon CV afin que son robot mal écrit puisse effectuer un botch à la recherche de mots clés. Je ne suis généralement pas d'accord pour passer un test de codage à moins que ce soit bref ou qu'ils le regardent en direct et me parlent.

Même s’ils ne mettent pas votre code en production, une entreprise qui souhaite que vous passiez un temps fou à taper avant de savoir si vous êtes un bon candidat est une entreprise qui est à l'aise de prendre avantage de vous. Ils signalent ce qu'ils veulent que leur relation soit; vous êtes le singe 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. Éloigne toi.