Meu trabalho em um teste de desenvolvedor está sendo aproveitado? [fechadas]

Estou procurando um emprego e me inscrevi em várias posições. Um empregador respondeu. Eu tive uma entrevista telefônica bastante longa (talvez uma hora +) e eles me prepararam para um teste de desenvolvedor. Foi-me dito que o teste foi estimado em 6 a 8 horas e que, desde que os resultados fossem aprovados, eu seria pago pelo meu trabalho.

Isso me deu uma pausa, mas me esforcei. O teste do desenvolvedor ocorreu em uma VM acessada via RDP . A tarefa era implementar uma página de pesquisa em um projeto da web que solicita dados do servidor, exibe-os na tela em uma tabela, possui um esquema de filtragem de pesquisas bastante complicado (há cerca de 15 status e ao enviar a pesquisa ao servidor que você pode pesquisar por esses status), além da pesquisa de sequência / campo. Além disso, eles querem que os ícones SVG mudem de cor em determinados valores de dados, e alguns dados são representados de maneira diferente da forma como estão estruturados no banco de dados.

Para encurtar a história, demorou muito mais do que 6-8 horas. Muito disso ocorreu devido à máquina virtual muito ruim em que eu estava executando (o Visual Studio 2013 levou 10 minutos para carregar e outros 15 minutos para abrir a solução ginormous de 3 GB).

Disseram-me que, após a conclusão do teste, eu deveria confirmar minhas alterações no controle de origem ... Hmm, OK. Eu segui as instruções. E depois de confirmar as alterações, recebi uma resposta por e-mail. Os SVGs não estavam com a cor certa, houve um bug nesse caso extremo, houve um problema ocasional com outra coisa que eu nunca experimentei etc. Então, eu tenho 13 a 14 horas nisso agora, e tenho que faça correções de bugs. Eu as faço, e o empregador volta com mais solicitações de correção de erros.

Aparentemente, todo o meu trabalho está entrando em um aplicativo de produção. Notei algumas anomalias no código em que parecia que outros haviam codificado todas as funcionalidades, mas não tocaram em mais nada.

Estou apenas sendo usado para mão de obra barata? Mesmo que me paguem os 50 dólares prometidos por hora, durante 6 horas, comprometi-me agora com cerca de 18 horas. Se eu corrigir todas as coisas que eles continuam inventando, terei trabalhado pelo menos 16 horas de graça.

Fiz vários testes de desenvolvedor, mas nunca fiz um durante o qual trabalhei no código destinado à produção. Nunca fiz um teste em que implementei um recurso que estava no pipeline de desenvolvimento e nunca fiz um que levou quatro rodadas e um total de mais de 20 horas. Tenho a impressão de que eles estão usando o teste de desenvolvedor para fornecer algumas das funcionalidades baratas.

Tenho a impressão errada? E esse protocolo de teste é apropriado?

Eu nunca participaria de um teste de código dessa natureza. Fiz muitos testes de código e fiz muitos projetos de código. Eu certamente não verificaria o código no repositório de outra pessoa sob nenhuma circunstância. Se eles não souberem o que precisam saber após uma amostra de 4 horas com uma pequena correção de bug em uma sessão de programação em pares, eles nunca saberão.

Ao fazer um teste, você deve saber e esclarecer algumas coisas com antecedência:

1. Deve-se concordar e saber que qualquer trabalho produzido durante o teste não pode ser utilizado para nenhum outro propósito que não seja determinar sua habilidade nas tarefas necessárias.
2. Um teste de código não deve durar mais de 4 horas.
3. Você não é funcionário da empresa; portanto, qualquer sugestão de pagamento pelo código produzido é absurda. Insista em um contrato de pagamento por escrito, se houver uma dica disso.
4. Defina limites específicos para o tempo que você gastará em qualquer parte do teste e siga esses limites. Se você ultrapassar os limites por qualquer motivo, considere por que está ultrapassando esse limite. É por causa da pressão deles? É porque você cometeu erros? É porque você mal calculou quanto tempo algo deve levar para ser concluído?
5. Defenda sua posição se achar que cobriu um tópico específico. Se você já corrigiu um bug, e eles estão pedindo para você corrigir um bug quase idêntico, diga "Já cobrimos esse tópico com o bug x, talvez possamos mudar para outra coisa que demonstre algo novo".
6. Sob nenhuma circunstância você deve verificar algo em um pipeline de produção. Isso inclui qualquer tipo de ramo de desenvolvimento que possa levar a um pipeline de produção. Em caso de dúvida, não verifique nada. Para testes de código que não são necessariamente pessoais, insisto que o código seja verificado primeiro no meu repositório público pessoal. Isso me dá pelo menos algum tipo de proteção contra o uso inadequado do meu trabalho.
7. Julgue-os por seu comportamento tanto quanto eles estão julgando você. Se você acha que eles não estão sendo sinceros com você, ligue para eles. Se você sente que está sendo maltratado, fale.

A empresa com a qual você está entrevistando também está sendo entrevistada por você. Se é assim que eles tratam alguém que eles estão entrevistando, é para essa empresa que você deseja trabalhar? Entendo que muitas vezes as pessoas precisam de um emprego e, muitas vezes, essa necessidade substitui alguns conceitos de senso comum, mas isso sempre deve estar na vanguarda de sua mente. Não tenha medo de sair. Se não parecer certo, siga seus instintos e vote com os pés.

Muitas entrevistas são seguidas de testes. Esses testes são necessários para garantir que você realmente tenha as habilidades necessárias e para ter uma melhor visão de algumas coisas difíceis de testar durante a própria entrevista (como aplicar regras de estilo ao seu código).

Dito isto, um teste é um teste.

• Não precisa demorar muito. Não há muito que você possa ver após oito horas de codificação que não poderá ver após trinta minutos. Mais importante, o código escrito durante o teste deve ser revisto, linha por linha, o que leva uma quantidade importante de tempo . Não é incomum gastar mais de duas horas para revisar o código de teste escrito durante meia hora.

• Não deve lidar com uma base de código existente. A compreensão da base de código de um produto de média escala pode levar dias ou semanas (ou meses ou anos, dependendo da qualidade do código e da dívida técnica). A propriedade intelectual também pode ser um problema (a menos que o código seja de código aberto).

  Quando o objetivo é testar como o candidato é capaz de manter a base de códigos existente, o teste pode ser realizado em uma pequena base de códigos fictícia (500-600 LOC) criada especificamente para os testes.

• Não precisa ser uma solicitação para desenvolver um aplicativo ou recurso da vida real. Pode ser um pedaço de código completamente inútil, escrito com a única intenção de mostrar que você entendeu o problema e encontrou uma maneira elegante de resolvê-lo.

• Não precisa ser perfeito. Existem bugs? Isso é bom. Tome nota deles para uma nova entrevista com o candidato; pode ser uma excelente oportunidade para ver como o candidato reage nessa situação.

• Não precisa ser feito pelo RDC em uma VM, a menos que você não tenha o Visual Studio. Se o objetivo é ver suas habilidades de codificação e resolução de problemas, não importa onde você faz o exercício.

• Não há dúvida de que o código escrito durante esse teste acabe no controle de versão da empresa. Por que eles poluiriam seu controle de versão com algo escrito por um candidato?

Para concluir, quando você é solicitado a gastar dezenas de horas escrevendo código de produção, resolvendo bugs e comprometendo seu trabalho com o controle de versão da empresa:

• Ou eles estão apenas usando você para implementar recursos de graça,

• Ou eles realmente não entendem como fazer uma entrevista.

Nos dois casos, procure um lugar melhor para trabalhar.

Não vou escrever uma resposta longa, mas estou seriamente confuso, por que ninguém está levantando a questão dos direitos autorais?

Quanto à minha experiência, nunca ouvi falar de um acordo para transferir a propriedade dos direitos autorais do código gravado durante um teste de desenvolvedor para a outra parte. Se for esse o caso, você poderá processá-los por violação de direitos autorais e os danos concedidos por isso podem ser bastante agradáveis, especialmente nos EUA pelas histórias que ouvi. E se eles quiserem resolver (proponha isso), você pode solicitar qualquer taxa exorbitante pela infração (após a qual, em princípio, eles ainda não teriam permissão para usar seu trabalho e você ainda poderia vender seu trabalho a eles, se eles ainda estivessem interessados )

Pessoas com mais experiência profissional podem responder melhor a essa pergunta, mas eu pessoalmente não me sentiria muito à vontade com um teste de desenvolvimento de mais de 20 horas. Parece que eles estão usando a entrevista para concluir as tarefas de trabalho.

Estou assumindo que você não assinou nenhum documento legal referente à propriedade do código. Então, eu esperaria até que eles revisassem o código e o aceitassem ou negassem. Então, se eles aceitassem, eu pediria para receber o pagamento em período integral, mais de 20 horas. Não sei se aceitaria o pagamento apenas pelas seis horas sugeridas originalmente. Se isso entrar em produção, eles precisarão endireitar a propriedade do código.

No mínimo, discutir o pagamento do código deve ajudá-lo a decidir se você deseja aceitar uma oferta. Eu não gostaria de aceitar uma oferta se eles pensassem que pagar apenas seis horas era justo.

Quando eu estava em posição de entrevistar os desenvolvedores, esses testes foram curtos e simplesmente "passaram ou falharam", sem correção de erros, mesmo quando havia alguns bugs menores no código. Isso porque eu queria avaliar as habilidades do candidato, não obter um software pronto para produção.

A situação descrita na pergunta parece muito com alguém tentando obter algo útil de graça (ou barato).

Eu nunca fiz um teste de desenvolvedor há mais de uma hora, e todos esses foram 'quebra-cabeças', um trabalho para ver se consigo resolver problemas e atingir um objetivo declarado dentro de um determinado prazo.

US $ 50 (ou, para mim, 25 a 30 libras) é uma taxa diária muito baixa, é como pedir a um encanador para consertar seu banheiro em troca de uma bebida.

Meu conselho, em termos inequívocos, é publicar um blog sobre sua experiência, referindo-se à empresa pelo nome, caso eles tentem criar um aplicativo inteiro com essa técnica (as pessoas geralmente pesquisam no Google antes de ir para a entrevista) e não deixam isso acontece novamente. Na próxima vez em que solicitarem uma correção de bug, você nomeará uma taxa diária de consultoria (pelo menos 5 vezes o que eles estão oferecendo) e informará que os desenvolvedores não funcionarão de graça.

Infelizmente, ser enganado faz parte da vida, mas você não precisa sentar e aceitar.

Apenas para comparação: a entrevista para o meu trabalho atual foi de cerca de 1 hora falando sobre o que eu fiz até agora e o que a empresa planeja fazer e como eu me encaixaria. Depois disso, trabalhamos juntos por uma semana em um pequeno projeto que eles estavam mentindo. acho que só para ver como nos damos bem. Eles me pagaram por isso como freelancer, o mesmo valor que recebo agora como funcionário, portanto nunca houve um dia inteiro de trabalho não remunerado, muito menos três dias.

Se o código for realmente usado na produção, eu enviaria a fatura pelas 24 horas que você passou, não por sua culpa se as estimativas estiverem erradas. Supondo que eles não permitiram estimar quanto tempo levará.

Enquanto você supostamente está sendo pago por (parte de) seu trabalho, isso não soa como um projeto de avaliação , parece uma farsa para obter trabalho barato / gratuito de você. Pode ser que ele tenha sido planejado para ser um projeto de teste, mas não estruturado ou gerenciado muito bem.

Mas o gerenciamento que é tão ruim que soa como uma farsa é definitivamente algo que você deve levar em consideração ao decidir se aceita o trabalho ou não.

Um projeto de teste adequado deve deixar claro que

• Eles têm um trabalho que desejam ter feito.
• Com base na sua entrevista, eles acreditam que você deve ser capaz de fazer o trabalho.
• A conclusão bem-sucedida do projeto não garante uma posição.
• Termos para o projeto (quanto eles pagarão, quem possui o código, se é tempo e materiais ou taxa fixa, tempo estimado para conclusão, etc.).
• O projeto será analisado e o feedback será fornecido - não apenas um sim / não para você obter ou não a posição.

Os termos devem ser aceitáveis ​​para você, independentemente de você ser contratado - se os termos forem aceitáveis ​​apenas se vierem com um emprego de período integral, eles não serão realmente aceitáveis.

Eu não acho que eles realmente usariam isso para obter mão de obra barata.

O motivo é simples. Depois que você escreve esses testes, eles precisam que as pessoas revisem o que você escreve; sim, revisar o código é muito mais fácil do que escrever o próprio código, mas ainda leva muito tempo.

Depois disso, eles provavelmente precisam de pessoas para manter esses testes, explicá-los etc.

E simplesmente não consigo imaginar nenhuma empresa de TI que se preocupasse em economizar menos de US $ 100, especialmente as empresas nos EUA. Nunca é assim que os negócios funcionam.

Eu acredito muito em testes de código para desenvolvedores entrevistando para um emprego. No entanto, isso soa como o teste de código do inferno ... Os testes de código nunca devem envolver código de produção. Eles devem ser simples e devem declarar que nenhum dos trabalhos realizados será usado pela empresa.

Claramente, o trabalho que você fez foi no código de produção. Você deve ser pago por todo o seu tempo - no mínimo. Tente conversar com um advogado e veja se ele acha que valeria a pena processá-los. Muitos advogados oferecem consultas iniciais gratuitas. Se houver fraude, e, nesse caso, dessa maneira, você poderá quadruplicar os danos financeiros e também poderá obter bons danos punitivos.

Ao processá-los e vencer, você ganhará algumas manchetes e desencorajará essa prática de outras pessoas no futuro - o que será benéfico para todos os desenvolvedores de software que procuram uma nova posição.

Infelizmente, os testes de codificação são um fato da vida. Dito isto, me incomoda ser solicitado a fazer quatro horas em um teste de codificação como condição para conseguir minha primeira triagem por telefone. É injusto pedir a um candidato que invista tanto quando a empresa investiu tão pouco no relacionamento.

Sou desenvolvedor sênior e posso passar no teste de codificação. Mas não vou perder muito tempo com isso, a menos que a empresa demonstre algum interesse pessoal por mim. Geralmente, não concluo um aplicativo para nenhuma empresa com um formulário de inscrição on-line grande e mal escrito que me pede para redigitar meu currículo para que o robô mal escrito possa prejudicar a pesquisa de palavras-chave. Geralmente, não concordo em concluir um teste de codificação, a menos que seja breve ou eles estejam assistindo ao vivo e conversando comigo.

Mesmo que eles não estejam colocando seu código em produção, uma empresa que deseja que você gaste muito tempo digitando antes de descobrir se é uma boa opção é uma empresa que se sinta confortável em tirar vantagem de você. Eles estão sinalizando o que eles querem que seu relacionamento seja; você é o macaco do código. Eles chamam os tiros. E o processo de entrevista é projetado para encontrar pessoas que se sintam confortáveis ​​com esse relacionamento.

Não seja um macaco de código. Ir embora.