Devo me preocupar com as tarefas de programação de superengenharia fornecidas durante o processo de entrevista? [fechadas]

Recentemente, tive uma entrevista por telefone com uma empresa. Após a entrevista por telefone, fui orientado a concluir uma breve tarefa de programação (um pequeno programa; não deve demorar mais de três horas). Só sou instruído diretamente a concluir a tarefa e entregar o código. Tive total liberdade para usar qualquer idioma que desejasse e não me disseram exatamente como entregar o código.

Imediatamente planejei lançá-lo no Github, escrevendo um conjunto de testes para ele, usando o Travis-CI (integração contínua gratuita para repositórios públicos do Github) para executar os conjuntos de testes e o CMake para criar os makefiles do Linux para o Travis-CI. Dessa forma, não só posso demonstrar que entendo como usar Git, CMake, Travis-CI e como escrever testes, mas também posso simplesmente vincular a página Travis-CI para que eles possam ver a saída dos testes. Achei que isso seria um pouco mais conveniente para o entrevistador.

Como conheço bem essas tecnologias, isso essencialmente não acrescentaria tempo à tarefa.

No entanto, estou um pouco preocupado que fazer tudo isso para uma tarefa relativamente simples pareceria ruim. Embora isso não traga muito mais tempo para mim, não quero que pensem que passo muito tempo em coisas que deveriam ser simples.

Como entrevistador, ficaria feliz em ver o conhecimento do processo de desenvolvimento de software demonstrado por essa abordagem; em vez de apenas escrever o código.

Em particular, ter um conjunto de testes para problemas muito simples seria um bom sinal (mesmo no nível do FizzBuzz). Eu já vi candidatos enviarem soluções que nem resolveram o problema e um simples conjunto de testes os mostraria isso. Além disso, ter o histórico de consolidação permite ter uma idéia do processo de pensamento que o candidato usou para chegar à solução.

Por outro lado, eu conheci pessoas que foram rejeitadas por algumas empresas em um estágio inicial do processo de excesso de engenharia. No entanto, na maioria dos casos, isso ocorreu devido ao excesso de engenharia da solução, não necessariamente aos processos utilizados.

Ter como entrevistado alguém que entendesse coisas como controle de versão, IC, testes de unidade e similares seria um passo em frente ao que eu costumo ver.

Embora, para mim, o mais importante seja que o problema seja resolvido e resolvido bem, sabendo que o candidato entendeu maneiras de melhorar a qualidade de sua entrega, definitivamente chamaria minha atenção.

O que geralmente vejo são pessoas que não apenas não entenderam o problema, mas também não entenderam como resolvê-lo - e seriam ignoradas, não importando quantas ferramentas extras usassem no processo.

Lembre-se de que há um limite de tempo. O entrevistador sabe disso, então isso significa (se eu fosse o entrevistador) que ele não só resolveria o problema dentro do prazo estipulado, mas fez isso tão rapidamente que sobrou tempo para o revestimento de ouro, o que é um bom sinal de sua habilidades de resolução de problemas, bem como sua apreciação pelo rigor e diligência.

Excesso de engenharia é uma palavra ruim quando você cria os AbstractFactoryManagerAdaptors que são conectados para distribuir o BuzzManager e o FizzManager apenas para resolver o FizzBuzz.

O que você está fazendo é excesso de diligência, o que nem é uma coisa (embora a sub diligência definitivamente seja).

Dito isto, se você acabar com o tempo ou com alguma solução semi-hackeada porque usou seu tempo com os extras que afirma "não acrescentar tempo", isso parecerá como se você tivesse uma compreensão muito baixa de quão grande é aparentemente pequeno tarefas podem ser. Esse pode ser um atributo perigoso para um engenheiro e muito comum entre os juniores. Priorize adequadamente e faça o extra-crédito somente após concluir a solução necessária .

Outra visão a considerar é que sua abordagem não é boa nem ruim. Posso imaginar entrevistadores que considerariam demais e posso imaginar entrevistadores que adorariam ainda mais engenharia.

Não se preocupe tanto. Em vez disso, resolva o problema da maneira que você considera melhor e provavelmente receberá ofertas de emprego de pessoas que concordam com você. Esse é um ótimo primeiro passo em direção a um ambiente de trabalho produtivo. Lembre-se, as entrevistas são de duas maneiras. A resposta do entrevistador à sua solução também informará muito sobre eles. Deseja realmente trabalhar com pessoas que acreditam que seus instintos e filosofia de desenvolvimento estão errados?

Na realidade, ninguém se importa se o candidato pode criar um repositório Git ou criar makefiles às pressas, porque isso é apenas uma lembrança do que ele aprendeu de maneira rotineira. Essas são habilidades secundárias ao aspecto real da solução de problemas e do design da pergunta da entrevista.

Portanto, sim, sua intuição é clara de que potencialmente parece ruim, porque pode parecer que o candidato acredita que alguém que pode regurgitar alguns comandos e padrões memorizados para criar um esqueleto de projeto possui habilidades de software impressionantes.

O aspecto do conjunto de testes da solução é bom. Entregar uma resposta com um conjunto de testes de regressão provavelmente ganhará seus pontos. Ainda mais se o seu conjunto de testes exercitar os casos destacados no código. O conjunto de testes não precisa ter muitos ajustes formais e confiar em ferramentas; apenas o fato de você ter uma de alguma forma é bom o suficiente para uma entrevista. É mais ou menos óbvio que, se você puder reunir alguns testes de unidade ad hoc em um questionário de entrevista, poderá fazê-lo com ferramentas em um projeto real.

Recentemente, tive uma entrevista por telefone com uma empresa. Após a entrevista por telefone, fui orientado a concluir uma breve tarefa de programação (um pequeno programa; não deve demorar mais de três horas).

Eu continuaria com cautela. Avalie a relevância do desafio para o trabalho e garanta que o reembolso futuro do empregador valha a pena 3 horas do seu tempo.

Questiono o valor desses tipos de testes e prefiro julgar alguém por suas realizações passadas. Uma tarefa curta predefinida não pode dizer nada ao empregador sobre o que você pode fazer. Apenas o que você não pode fazer, e isso pode ser rapidamente determinado com algumas perguntas por telefone.

O teste tem seu lugar. Faça a si mesmo as seguintes perguntas sobre o teste e responda em conformidade.

1. O teste é justo, considerando seu nível de carreira atual?
2. O teste tem uma resposta correta claramente definida?
3. O entrevistador tem interesse em seu potencial como pessoa ou está demonstrando mais interesse nos resultados dos testes (ou seja, contratar agências é péssimo para isso).
4. O teste representa o tipo de trabalho que você gostaria de fazer ou é uma verificação de habilidades ambígua (por exemplo, teste se você conhece a sintaxe Java).

Só sou instruído diretamente a concluir a tarefa e entregar o código.

Você acabou de responder sua própria pergunta.

Imediatamente planejei lançá-lo no Github, escrevendo um conjunto de testes para ele, usando o Travis-CI (integração contínua gratuita para repositórios públicos do Github) para executar os conjuntos de testes e o CMake para criar os makefiles do Linux para o Travis-CI.

Não, não foi isso que eles pediram para você fazer.

Dessa forma, não só posso demonstrar que entendo como usar Git, CMake, Travis-CI e como escrever testes, mas também posso simplesmente vincular a página Travis-CI para que eles possam ver a saída dos testes. Achei que isso seria um pouco mais conveniente para o entrevistador.

Seria cuidadoso ao demonstrar habilidades muito cedo ou muito tarde no processo de entrevista. Se você sente que não se saiu bem na entrevista e agora está tentando compensar, isso não vai funcionar. Por outro lado, fazer muito quando não solicitado também demonstra excesso de ansiedade. Isso poderia resultar na contração do empregador com uma oferta de salário mais baixo do que você esperava.

No entanto, estou um pouco preocupado que fazer tudo isso para uma tarefa relativamente simples pareceria ruim.

Sim, parece ruim. Resolver seu desafio com uma linha de código será muito mais impressionante do que um projeto completo.

Pela minha experiência, não é assim que você ganha a entrevista de emprego, mas é uma maneira de perder o emprego. O teste de código é um problema de controle de qualidade. Toda empresa que usa testes de código ao contratar pessoas o faz, porque anteriormente não estava usando testes de código. Eles tiveram uma péssima experiência com alguém que escapou das rachaduras do processo de entrevista que não deveria ter.

Eles pegam seu código-fonte e o passam pelo escritório. As pessoas comentam sobre isso, e o que você não quer que elas digam é "Ele cometeu esse erro? Mas estava gastando tempo usando Git, CMake e Travis-CI. Que idiota por perder esse erro".

É isso aí. Você perdeu.

Eles querem saber que você pode codificar, porque não podem ensinar isso a você. Git, CMake e Travis-CI podem ser facilmente ensinados.

Eu acho que sua abordagem não é boa nem ruim em si . Gostaria de perguntar ao entrevistador se está certo usar o Github e as outras ferramentas. Como o @Izkata apontou nos comentários, você está tornando sua solução pública.

Como entrevistador, eu sabia que geralmente não há mal nenhum em o candidato tentar esclarecer algumas coisas. Além disso, fazer uma ou duas perguntas pode ser um bom sinal, pois você não se apressa em fazer coisas que não entendeu.

Lembre-se, porém, que o mais importante é que o problema seja resolvido e resolvido bem. Nesse sentido, todos concordam que um conjunto de testes ajuda. Mas, para isso, talvez você só precise enviar algumas classes de teste junto com seu projeto / solução.