Testes de engenharia levam para casa feito direito

AngelList Blocked Unblock Seguir Seguindo 2 de janeiro Ilustração de Qieer Wang

Testes de engenharia em casa são uma coisa controversa. Enquanto alguns empregadores juram por eles, assim como muitos engenheiros acreditam que eles são desrespeitosos, preguiçosos, e se recusam a prosseguir com as entrevistas que os incluem.

A verdade é: as entrevistas para levar para casa são incríveis, mas são realmente fáceis para as startups se sentirem desastrosamente erradas.

Um bom take-home oferece várias vantagens sobre outros métodos de teste:

  • Ele fornece uma amostra de trabalho mais precisa do que entrevistas no quadro branco ou desafios cronometrados.
  • Isso elimina o estresse que os testes irrealisticamente de alta pressão – como desafios cronometrados – induzem.
  • Ele cria referências fáceis, porque todo engenheiro deve receber o mesmo teste.

Infelizmente, os gerentes de contratação geralmente distribuem projetos para levar para casa que levam dias para serem concluídos, não têm relação com o trabalho que um engenheiro fará na empresa e enfatizam um engenheiro em potencial mais do que uma entrevista algorítmica faria.

Para criar um take-home que os engenheiros realmente concluam, enquanto ainda lhe dão uma boa medida de suas habilidades, siga estes três princípios de perto:

1. Respeite o tempo dos engenheiros

Quanto mais tempo você levar para casa, menos provável será que os engenheiros o completem.

A maioria dos engenheiros interessados em seu papel também estará conversando com outras empresas, muitas das quais exigirão projetos para levar para casa. Os projetos para levar para casa se acumulam e, supondo que os engenheiros ainda estejam trabalhando em tempo integral, eles simplesmente não terão tempo para concluir um projeto de quatro horas de graça. Além disso, os bons engenheiros sabem quanto vale o seu tempo – pedir quatro horas de código livre levará os engenheiros experientes a dispensar o seu teste.

Se você realmente precisar atribuir um projeto que leve mais de quatro horas, deverá pagar os candidatos pelo código . Se você não tiver recursos para isso, atribua um prazo menor para levar para casa.

Para garantir que seus take-homes não consumam dias de tempo de engenharia, inclua o projeto em alguns recursos e, a menos que você esteja contratando especificamente para uma especialização em uma tecnologia de nicho, faça o possível para garantir que o projeto não seja necessário. • Requer familiaridade com um framework obscuro que custará horas de pesquisa para engenheiros.

Por fim, defina expectativas claras sobre quanto tempo o trabalho deve levar. Se levar apenas duas horas, deixe claro nas suas instruções.

Serviço de streaming de áudio O TuneIn é um exemplo de uma startup que claramente coloca em xeque o desafio de levar para casa, que você pode ver neste repositório do GitHub . As instruções sendo com:

Oi desenvolvedor do Front End. Bem vinda. Sua missão, se você optar por aceitá-la, é esculpir 2 horas e criar um aplicativo de página única (SPA) usando a API de estação mini TuneIn definida abaixo.

Ei isso é importante! Esperamos que você possa gastar cerca de duas horas neste projeto. Se você conseguir terminar mais rápido – ótimo! Se não, limite-se e não gaste mais do que 2 horas no MAX.

A equipe da TuneIn também fez de tudo para limitar o tempo de configuração. Código Boilerplate é fornecido (embora os candidatos estejam livres para descartá-lo, se preferirem) e compartilham uma API simples da qual os candidatos podem chamar dados.

Como resultado, os candidatos podem começar a trabalhar rapidamente e concentrar-se em resolver o desafio real proposto pelo levar para casa. Eles também têm uma clara expectativa de tempo. Se o projeto levar mais de duas horas para ser concluído, é hora de parar.

Como as empresas entendem isso errado:

  • Atribuindo projetos em uma escala que levaria até mesmo engenheiros seniores dias para concluir
  • Atribuir projetos que exigem conhecimento profundo de algo tão específico que a maioria dos engenheiros precisaria passar horas pesquisando
  • Atribuindo projetos que exigem um tempo significativo de configuração antes que um candidato possa começar a trabalhar

2. Faça seu teste perto de um produto de trabalho

A principal vantagem de um projeto para levar para casa, a partir de uma perspectiva de contratação, é que você consegue ver como seria se os candidatos trabalhassem em seu código de produção. Quanto mais próximo o seu projeto estiver do trabalho real que você faz, melhor será o sinal de como eles contribuirão para a sua equipe.

Para fazer isso bem, construa um projeto que simule os principais recursos do seu produto sem replicar toda a sua complexidade. A Workyard , uma empresa que conecta empresas de construção com trabalhadores, faz isso em seu front-end para levar para casa . A equipe explica sua missão assim:

A missão, se você escolher aceitar, é construir um modal “Post a Project” no React. Postaremos seus novos projetos na API de preparação do Workyard. Depois que o projeto for publicado com sucesso, mostraremos todos os seus novos projetos em uma lista de cartões muito simples.

Eles incluem arquivos do Sketch que zombam do modal para os candidatos, então os engenheiros não são deixados tentando projetar um front-end por conta própria:

Junto com essas imagens, a Workyard também fornece uma documentação detalhada das convenções de codificação de sua equipe. (Abaixo está apenas um instantâneo. A lista atual é muito maior):

– Componentes magros, ajudantes gordos. Coloque o máximo de complexidade possível nos arquivos auxiliares.

– Faça mapStateToProps cheio de chamadas de ajuda, deixe o render () o mais magro possível.

Seu projeto de front-end pede aos engenheiros que criem uma parte funcional do código que imite uma característica real do Workyard – postar projetos – e, da mesma forma, solicita aos candidatos que o façam seguindo as convenções da Workyard. Os candidatos recebem especificações técnicas em detalhes, da mesma forma que fariam em um produto real. Eles também recebem um número de telefone e outras informações de contato para fazer perguntas à equipe de engenharia.

Ao definir o projeto desta maneira, a Workyard tem uma noção de como um engenheiro realmente se encaixaria em sua organização de engenharia e, por outro lado, os candidatos têm uma noção real de como seria trabalhar como engenheiro na Workyard.

Como as empresas entendem isso errado:

  • Projetos que são realmente brinquedos, completamente desconectados dos produtos de trabalho.
  • Projetos que são excessivamente planejados para testar algo específico – como os candidatos se comprometem, por exemplo.

3. Não deixe nenhum espaço para Creep Scope

Quando um engenheiro está em sua equipe, ele está tentando enviar um produto de sucesso. Quando um engenheiro está trabalhando em seu teste, eles estão tentando impressioná-lo. Não importa o quão realistas sejam seus projetos para levar para casa, essa diferença mudará a maneira como os engenheiros os abordam.

Um dos maiores riscos é o escopo do escopo. Se você der a um engenheiro um projeto sem limites como "construa um frontend que consome nossa API e tenha recursos-chave X", o escopo é teoricamente infinito. Enquanto em um projeto real, o mesmo engenheiro (esperançosamente) estará focado em recursos de envio que atendem seus objetivos de negócios, neste projeto, o engenheiro estará preocupado em impressioná-lo. Adicionando recursos extras, usando novas estruturas desnecessárias, reescrevendo seu clichê no TypeScript – ele pode ficar fora de controle rapidamente.

Mesmo que um engenheiro não acrescente horas de trabalho ao projeto para tentar ir além, ele estará lidando com o estresse de adivinhar se você secretamente quer. Você estava sendo propositadamente vago para ver se eles superforneceram?

Evite isso, declarando claramente as expectativas em torno do seu projeto. O Frame.io , a popular plataforma de pós-produção de vídeo baseada em nuvem, é um forte exemplo disso com seu frontend take-home, que você pode ver neste repositório do GitHub .

O projeto em si é bastante simples. Eles fornecem um componente de pesquisa de autocompletar em funcionamento (pense na pesquisa do Google) e pedem aos engenheiros que implementem dois novos recursos. Eles fornecem uma demonstração de trabalho do aplicativo básico em seu clichê – que você pode instalar em menos de um minuto:

Junto com essa demonstração, eles também fornecem expectativas específicas sobre o trabalho dos engenheiros no projeto:

– O componente deve ser reutilizável. Deve ser possível ter várias instâncias do componente na mesma página.

– O exemplo "States" que usa uma matriz de dados deve continuar funcionando.

– O componente deve aceitar qualquer endpoint HTTP, não apenas o exemplo https://api.github.com/users acima.

– Seu componente deve funcionar corretamente no Chrome, não se preocupe com a compatibilidade entre navegadores.

– Você pode usar pequenos ajudantes DOM como o jQuery ou utilitários do Lodash, mas não grandes bibliotecas / frameworks como React, Angular ou Vue.js

– Você pode modificar todas as partes do código existente, mas não precisa fazer isso para fornecer uma ótima solução.

– Documente seu componente em SOLUTION.md.

Finalmente, eles instruem os engenheiros a parar de trabalhar na marca de quatro horas e explicar qualquer trabalho extra que eles fariam se este fosse um produto de trabalho real. Dessa forma, a equipe do Frame.io deixa espaço para os engenheiros irem além da meta sem realmente dedicar tempo para criar código extra.

Como as empresas entendem isso errado:

  • Projetos com resultados vagos, deixando a porta aberta para a fluência maciça do escopo
  • Projetos julgados por critérios pouco claros – se comentários extensos são uma prioridade para você, diga
  • Projetos que são incrivelmente grandes. Se você espera que seus engenheiros em tempo integral precisem de um dia inteiro para enviá-lo, é muito grande

Dê aos candidatos de engenharia uma revisão real do código

O outro erro que as startups cometem com projetos para levar para casa não tem nada a ver com a composição do projeto em si. Em vez disso, o problema está no processo de revisão. Para os candidatos, uma das experiências mais desmoralizantes é passar horas em um take-home que reflete seus melhores esforços, apenas para ser chamado para uma entrevista no local onde o gerente claramente nunca olhou para o seu código.

Se você der um engenheiro para levar para casa e trazê-los para um local, respeite o tempo que eles dedicam ao projeto. Converse com o código deles, questione o processo de tomada de decisões e tenha uma ideia de como eles pensam sobre o software.

Seu levar para casa não deve ser um substituto para uma tela técnica. Não deveria ser apenas mais um aro para os engenheiros passarem. Sua escolha de casa deve poupar seu tempo no processo de entrevista, ajudá-lo a avaliar melhor seus candidatos e eliminar parte do estresse dos engenheiros – mas só pode fazer tudo isso se você for tão investido quanto seu candidato.

Texto original em inglês.