Como lidar com testes técnicos de entrevista que são absurdos (por exemplo, uma tarefa excessivamente grande com um prazo curto)?

Ao afastar-se deles.

GS (Goldman Sachs) quis uma vez uma pequena amostra de código de mim, que desceu para um simulador de livro de encomendas de troca. Nada de muito particular, EXCEPTO que especificaram a cobertura total do teste e a QUALIDADE DO CÓDIGO DE PRODUÇÃO. Para algo tão crítico, o código de qualidade desce para uma semana de trabalho testando cada caso, porque este tipo de código é extremamente crítico.

Eu enviei ao recrutador uma oferta e disse-lhe que se eles não pagassem - sem brincadeira.

Algumas empresas têm ideias estúpidas e fizeram testes ridículos. O vosso exemplo é semelhante - não há maneira de o fazer em 2 horas fora de ter já preparado. Atrevo-me a dizer que se trata de uma fraude de limite. Provavelmente é apenas um sinal de incompetência cómica.

Lembre-se que isto é TI - e TI é um mercado de vendedores. Toneladas de empregos - sem especialistas. Comporte-se assim. Não lide com idiotas. Recuso qualquer trabalho de codificação sem entrevistas PRIOR, porque há outro lado: Todos esses projectos “interessantes e desafiantes” são sempre os mesmos estúpidos. Quero saber primeiro se quero perder o meu tempo, porque adoro fazer projectos de que gosto, e os recrutadores não fazem ideia do que são projectos hoje em dia.

Lembre-se, quando uma empresa o está a entrevistar, também os está a entrevistar.

Use testes inane como uma ferramenta de rastreio.

Se o TEST lhe der objectivos e prazos pouco razoáveis, ** adivinhe o que pode esperar no trabalho.**

Não o leve a peito, um mau teste não é um indicador útil das suas competências. Se eles dizem que o teu trabalho não foi suficientemente bom e tu sabes que foi, então é óbvio que eles também não te vão apreciar no trabalho.

Novamente, não és tu, são eles.

Em retrospectiva, sendo 20/20. Isto é o que deve dizer da próxima vez:

“Como regra geral, eu não faço nenhum trabalho de casa para levar para casa a menos que fale primeiro com o cliente”

“Você é o cliente? Não, então ligue-me ao gerente de contratação do cliente. E não, se trabalhar para o RH (não é o cliente a não ser que queira que eu construa uma aplicação relacionada com RH)”

“Ok, o que é que esta pessoa faz pela sua empresa? Será a pessoa a quem vou reportar se a sua empresa me contratar? Ok, sim. Quero falar com essa pessoa”

“Ok, já leu o meu currículo? Achas que podemos saltar todo este projecto take-home?”

Assumindo que o gerente de contratação ainda não o quer saltar, então podes dizer:

“O problema é que já fui queimado antes.

Para começar, não sei se devo apenas construir o projecto a partir do zero, ou apenas reutilizar algum do código que tenho à minha volta? Uma vez, construí o projecto do zero em algumas horas, mas fui criticado por não ter uma aplicação pronta para produção.

E outra vez, houve um pequeno descasamento de versões, e as suas TI não sabiam como ajustar o ficheiro de configuração para fazer o meu projecto funcionar”

Mas faça o que fizer, não dê esta explicação ao recrutador. Não explique e não se justifique perante o recrutador. É inútil tentar explicar-se a um porteiro. Quanto mais informação der a um porteiro, mais provável é que ele use essa informação contra si, uma vez que, por concepção, um porteiro raramente tem o poder de fazer concessões, mas por outro lado, o seu papel é mais o de procurar razões para seleccionar os candidatos.

“Ok, estou disposto a fazer o projecto take-home, mas prefiro estar presente quando o meu projecto for instalado e avaliado.

Acha que poderíamos marcar uma altura em que eu pudesse entrar com o meu código e o pudéssemos montar em conjunto numa das suas máquinas de desenvolvimento? ”

“Que tal esta próxima quarta-feira? […] Vai lá estar? Será que um dos programadores também vai lá estar? ”

Mas mais uma vez, só faça isto se estiver a receber boas vibrações desta pessoa. Confie nos seus próprios sentimentos. Se, por qualquer razão, sentires que estão a usar este projecto para levar para casa como uma forma preguiçosa de seleccionar muitas dezenas de candidatos. Ou se, por qualquer razão, sentires que estão a tentar extrair algum trabalho gratuito de ti, para que o possam colocar em produção, não concordes com o trabalho de casa.

O mesmo acontece se apareceres e eles não quiserem instalar/rever o teu projecto quando lá estiveres. Se eles querem que você faça os seus trabalhos de casa, eles têm que investir algum tempo em você também. É uma demonstração de respeito mútuo.

E se por qualquer razão, não estás a receber esse respeito. Por exemplo, se eles trocarem o engenheiro que você deveria encontrar com uma pessoa de RH no último minuto. Seja educado, mas seja firme. Não lhes dê o seu projecto de levar para casa. Diga-lhes que terá todo o prazer em remarcar a entrevista e partir.

Não gosto de me referir a outras respostas nas minhas respostas, pois as respostas devem poder ser compreendidas por si mesmas. No entanto, a resposta mais votada resume-se basicamente a “A empresa é um bando de idiotas”. Foge deles". Isto não dá à OP nada para melhorar sobre si mesma, nem nada para mudar no futuro. Vejo áreas que o PO poderia melhorar, independentemente de a empresa ter feito algo de errado ou não, o que nós, como respondentes, não sabemos, uma vez que só ouvimos um lado da história.

Tanto quanto posso ver, não comunicou _ antes_ de iniciar a tarefa que acreditava firmemente que não poderia ser feita em duas horas.

Aqui está a sequência de eventos como eu a vejo:

1. Foi-lhe pedido para completar um desafio de codificação
2. Quando recebeu o desafio, em vez de comunicar as suas preocupações, começou a codificar
3. Apressou o desafio, cortando os cantos
4. Apresentou um projecto de baixa qualidade que não funcionava sem muito
5. Depois de receber o feedback, começou a justificar o seu trabalho

Aqui está como imagino que a empresa o viu:

1. O candidato aceitou todas as condições do desafio
2. O candidato submeteu o projecto dentro do prazo
3. O projecto não funcionou
4. O candidato começou a arranjar desculpas para o seu trabalho

Imagine que está numa situação de trabalho e que o seu gestor/líder de equipa lhe pede para completar uma tarefa num período de tempo não razoável. Se não comunicar imediatamente que não consegue fazer tanto trabalho nesse pouco tempo, então qualquer falha é culpa sua por aceitar as condições iniciais. Você_ é o especialista, não eles, e eles confiam em si para comunicar com eles.

Não posso sublinhar a importância de ambas as partes terem um entendimento comum da situação. Tiveste uma falha insuperável de compreensão porque perdeste a tua oportunidade de a resolver. Da próxima vez que tiver um problema, comunique imediatamente ou a outra parte vai pensar que está tudo bem! Não comunicar informações importantes é mentir por omissão, e qualquer forma de mentira é pouco profissional. Como eles reagem à informação é responsabilidade deles, não vossa.

Recomendo que leiam The Clean Coder: Um Código de Conduta para Programadores Profissionais por Robert C. Martin (Tio Bob), em particular:

• Capítulo 2: Dizer Não
• Capítulo 3: Dizer Sim
• Capítulo 10: Estimativa
• Capítulo 11: Pressão

Se a empresa rejeita a sua candidatura porque pediu feedback e esclarecimentos antes de iniciar a tarefa, eles não o filtraram, você filtraram eles como uma empresa para a qual não quer trabalhar.

Encontrei alguns testes inteligentes e estúpidos (SQL/BI) e saí activamente de um que era estúpido, explicando que o que eles queriam era a abordagem errada.

Também vi testes que eram na verdade tentativas de um projecto livre, com “trabalho de amostra” que era essencialmente uma solução nova. Mais uma vez, recusei-me a completá-los.

Acontece, eu gizo-o para experimentar e seguir em frente. Marquei sempre entrevistas para depois do horário de expediente, por isso não há nenhuma perda real da minha parte.

Bem, diga-lhes exactamente o que diria ao seu chefe se fosse confrontado com essa tarefa.

Ou eles não sabem o que estão a fazer, então vai aprender muito sobre a empresa, ou eles querem ver que não perde tempo (dinheiro da empresa) a fazer as coisas mal, em vez de falar com a pessoa sem os conhecimentos técnicos para julgar isto.

Há dois resultados, você passa com distinção por fazer a coisa certa, ou esquivou-se à bala e não tem de voltar dentro de dois meses para nos dizer como o seu chefe exige coisas impossíveis ;)

Eis a minha abordagem:

1. Comunique com o seu contacto na empresa que acha que não é possível no tempo, e o que planeia realmente fazer.

2. Se houver tempo para esperar por uma resposta, espere; se não, faça o que pretende e documente detalhadamente as suas escolhas

3. O ideal seria esboçar onde levaria o resto.

Note que muito poucos entrevistadores realmente calibram e testam que uma tarefa leva 2 horas. Se realmente quer o trabalho, leve-o a algum nível de completude num determinado período de tempo.

Como descobriu, a qualidade geralmente é superior à adequação ao tempo, a menos que tenham mecanismos rigorosos para garantir que todos os candidatos se encaixem dentro do tempo.

Isto cheira a teste falso para mapear a sua personalidade, especialmente a forma como lida com eventos absurdos e stressantes. Você é do tipo que

1. se irrita e sai ou
2. aquele que silenciosamente tenta resolver ou faz
3. realmente tenta discutir e explicar com a gerência o que não é razoável ou
4. fica tão stressado que não sabe o que fazer ou
5. é você que finge tentar resolver mas devolve resultados igualmente absurdos porque é exactamente isso que alguém que venha com uma tarefa destas mereceria?

É da minha opinião de especialista que ninguém jamais apontaria isto como sendo algo como duas horas de trabalho, se feito correctamente. Eu colocaria alguns dias de trabalho, pelo menos, para acertar a arquitectura, etc.

Desculpe, mas não está a perceber.

Pense nisso do ponto de vista da equipa. Eles querem alguém que esteja familiarizado com todo o ASP.NET, MVC, REST, a falar com uma base de dados e com a funcionalidade moderadamente avançada de uma caixa de texto autocompleta.

Poderia I fazer estas coisas? Sim, eventualmente. Afinal de contas, eu já ouvi todas estas coisas, por isso posso ir em frente e listá-las no meu currículo. Um especialista como você será capaz de ligar um sistema de trabalho sob o limite de tempo porque você lida com esta pilha o tempo todo, mas eu teria de passar horas a vasculhar os manuais.

Um currículo é um pedaço de papel onde listar pontos de bala é trivial. Um mau aluguer é pior do que nenhum aluguer. Presumo que não tenha tido uma recomendação pessoal de alguém da equipa, por isso o gerente de contratação procura uma demonstração de competência. É verdade que um verdadeiro sistema pronto para a produção demoraria muito mais tempo, mas o teste não pediu pronto para a produção porque perguntou o que se teria feito com mais tempo. O sucesso no teste mostra que você é fluente com todas as camadas e, mais importante, que você sabe como priorizar. Faça-o funcionar e _então faça-o bonito!

Um teste de duas horas não é o tempo para a arquitectura astronáutica.

Além disso, quase de certeza que não é o primeiro candidato a ver este teste. A equipa já usou e talvez tenha afinado o seu filtro várias vezes, e pelo menos um programador conseguiu passar. Virar o nariz para cima - como se tornou altamente na moda nos últimos anos - em justa indignação ou “educá-los” sobre o porquê de ser um mau teste irá, na sua opinião, colocá-lo na categoria de bozo. Phew! eles vão pensar, outro procrastinador ou primadonna nós não temos que lidar com.

Como lidar com isso? Veja isto da perspectiva do seu potencial cliente. Em vez de considerar um absurdo, dê o benefício da dúvida. Para um teste de duas horas anote brevemente as suas suposições, faça o caso do dia ensolarado para a simples demonstração funcionar, e no tempo restante documente como tornaria um verdadeiro sistema robusto.

Como as outras respostas têm pelo menos insinuado, a motivação por detrás do teste c poderia ser razoável, particularmente se o teste:

1. for bem adaptado aos _requisitos do emprego;
2. Minimiza os elementos menos importantes;
3. Não é claramente uma tentativa de obter “trabalho gratuito”; e possivelmente
4. Vem com pelo menos algumas dicas sobre o que os revisores estão “procurando”.

Em um trabalho anterior, eu projetei e administrei um teste de programação discutivelmente “absurdo”. O trabalho foi sempre um trabalho de nível sénior de desenvolvimento de ASP.NET/SQL Server, e a tarefa envolvia criar uma aplicação web muito básica envolvendo uma página e dois ou três procedimentos simples de armazenamento. O candidato realizou o teste no local utilizando ferramentas padrão:

1. Visual Studio (versão de escolha do candidato nas duas ou três últimas versões);
2. SQL Server Management Studio; e
3. Um web browser, não só para testes mas também para pesquisa de documentação, recursos, etc., o que eu disse especificamente aos candidatos que lhes era permitido fazer.

Eu forneci ao candidato uma solução básica “shell” (em cada uma das versões permitidas do Visual Studio), e criei a base de dados e as tabelas com antecedência.

Eu dei ao candidato uma descrição de uma página e disse ao candidato que voltaria em dez minutos para responder a qualquer pergunta sobre o assunto, após o que ele teria uma hora para completar a tarefa.

Quando voltei após dez minutos, depois de responder a qualquer pergunta, disse à candidata que se ela não tivesse a certeza de que poderia terminar cada parte da tarefa dentro de uma hora, poderia considerar concentrar-se numa parte da tarefa que pudesse completar e começar a correr dentro do tempo atribuído. Também mencionei que se ela tivesse mais perguntas durante a hora, podia encontrar-me a dois cubículos de distância e perguntar.

Porque escrevi o teste, podia completá-lo do princípio ao fim em cerca de quarenta e cinco minutos. Não esperava absolutamente que os candidatos completassem todo o teste em uma hora. O limite de tempo “absurdo” foi estabelecido por três razões:

1. Queríamos ver se o candidato tinha sequer uma compreensão meio razoável dos requisitos do trabalho. Lembre-se, isto era para um cargo de nível superior. (Bem mais de metade do tempo, a resposta foi “não”)
2. O candidato deve ser capaz de analisar os requisitos básicos e dividi-los em tarefas manejáveis e discretas.
3. A prorrogação do teste para além de uma hora levaria mais tempo do candidato sem nos dar muita ou nenhuma informação adicional.

No final da hora, pedi ao candidato para me mostrar o que tinha, se tinha alguma parte de uma solução de candidatura para demonstrar, etc. Geralmente, levávamos cerca de cinco minutos a rever o trabalho nesta altura, depois o candidato teria uma entrevista individual com o gestor. Durante essa entrevista, a equipa de desenvolvimento analisava o que a candidata tinha apresentado. Nós realmente aguardávamos com expectativa este dever porque nunca era aborrecido.

Se o candidato tivesse uma solução de candidatura que tratasse da sua parte pretendida da tarefa global, o candidato passou quase de certeza esta fase da entrevista. Mesmo que a solução ainda não tivesse corrido, se pudéssemos ver progressos substanciais e provas da competência do candidato, normalmente continuaríamos a considerar o candidato. Verificámos sempre o histórico do browser do candidato para ver que recursos acedeu.

As razões pelas quais os candidatos efectivos não tiveram sucesso incluíram:

1. Literalmente não produziram nada depois da hora completa. Lamento dizer que esta situação aconteceu várias vezes.
2. Plagiar o código do trabalho actual do candidato e tentar (e não conseguir) modificá-lo para cumprir os requisitos do teste. Quando suspeitávamos disto, o histórico do navegador daria o código.
3. Incapacidade de formar uma cadeia de ligação para ligar a candidatura à base de dados. Esta pode parecer um pouco injusta, mas lembre-se que estávamos à procura de candidatos de nível superior, incluindo experiência de desenvolvimento de SQL Server de nível superior. Nós certamente didn’t esperamos que o candidato se lembre como construir uma string de conexão, mas nós did esperamos que o candidato seja capaz de procurar rapidamente. ConnectionStringBuilder também teria sido absolutamente bom, mas nunca ninguém a utilizou. O primeiro exemplo do https://www.connectionstrings.com/sql-server/ teria funcionado muito bem.

Houve outra parte da entrevista com o gestor e a equipa de desenvolvimento juntos, e nós fazíamos perguntas sobre a solução do candidato, como ela teria abordado o resto do projecto, etc.

Em resumo, aconselho a considerar as motivações do empregador para um teste “absurdo” antes de o despedirmos de improviso.

Esta resposta não faz qualquer afirmação sobre se este tipo de testes é uma coisa boa ou não (ou se eu os tolero), mas concentra-se na questão específica._

Como posso decidir se devo fazer testes técnicos que considero absurdos (e. g. uma tarefa exageradamente grande com um prazo curto) no futuro?

Como você faria no mundo real:

• Comunique quanto tempo a tarefa levaria razoavelmente.
• Explique o seu plano do que fazer no tempo determinado (ou seja faça menos, ou pior, ou ambos).

• Faça o máximo que puder, com o menor nível de qualidade que puder suportar. Concentre-se em obter uma solução de trabalho antes de uma solução completa.

• Documente claramente onde quer que corte os cantos, quais são as implicações, e os TODO’s resultantes.

Tudo isto me ajudaria muito, como empregador ou cliente, a julgar se quero trabalhar consigo.

Dependendo da estrutura de gestão do empregador/cliente, o tipo que o emprega (ou seja, o seu patrão/cliente directo) pode muito bem estar numa posição em que não pode influenciar o tipo de trabalho que obtém. A gestão matricial existe… neste caso prefiro ter alguém que consiga lidar com tais situações com graça do que um herói que entrega o maior código de todos os tempos, mas não é capaz de comunicar sobre limites de tempo/qualidade.

A medida exacta de se optar por mais qualidade, ou por mais conteúdo, depende. Por exemplo, no seu caso, provavelmente estará mais interessado em ver que pode fornecer um trabalho de qualidade. Assim, poderá cortar algumas características (utilizando algum espaço reservado, etc.), mas mantenha a qualidade do seu código elevada. Da mesma forma, se o trabalho estivesse, digamos, relacionado com a segurança, você faria o mesmo. Mas se for uma prova completamente acrítica do conceito de alguma coisa, então pode ser que um se desvie mais na outra direcção. Documente tudo isto (sucintamente), e está bem encaminhado.

PS: Gosto de evitar julgamentos “loucos ou maus”. Isto é, não se deve preocupar se o cliente está apenas louco, ou se está fora para o conseguir (isto é, se o trabalho é gratuito), apenas a julgar pela dimensão da tarefa. A quantidade real que importa para si é o seu tempo, e isso foi fixado. Desde que você esteja bem em investir as duas horas em um potencial novo cliente, não deve importar se a tarefa é facilmente feita, ou um trabalho de alta pressão, ou apenas duas horas de conversa fiada em seu escritório.

Não há absolutamente nada de errado com o teste técnico louco de 2 horas. **Todos os outros candidatos teriam de fazer o mesmo teste, por isso a sua probabilidade de lhe ser oferecido o trabalho não é diferente de um exercício de programação fácil para principiantes. Não houve nenhum preconceito; foi-lhe pedido que o fizesse simplesmente porque se tinha candidatado ao lugar.

É o vendedor no mercado de trabalho e é da sua responsabilidade acomodar os compradores tanto quanto possível. Tem pouco poder de negociação para além de ir para outra posição. Certamente, um teste de programação que todos os candidatos teriam de fazer não é irrazoável, independentemente de poder competir ou não. Se for altamente qualificado para o cargo, mas não conseguir completar o teste, os outros candidatos também não o conseguirão fazer. Então qual é o problema?

Faça o seu melhor. Irritado por não ser oferecido para o cargo? A empresa tem de contratar alguém, por isso outra pessoa poderia ter feito um trabalho melhor. O objectivo de um teste de programação impossível é encontrar o melhor candidato com melhor desempenho. Se o melhor candidato completar o exercício é irrelevante.

como posso decidir se devo fazer testes técnicos que considero absurdos

Deve sentir-se confortável para qualquer teste técnico se pensa que tem as competências para o cargo e todos os outros candidatos teriam de o fazer. Nunca faça um teste insano se achar que se trata de uma tentativa de trabalho de programação gratuita ou/e dada a si devido a preconceitos (por exemplo, racismo).

PS: Nunca mencionei que o PO não é “bom o suficiente”. @TessellatingHeckler