Eu entrevistei centenas de candidatos para vagas de engenharia de software
As práticas de contratação para engenheiros de software estão sob críticas, com muitos argumentando que quebra-cabeças de whiteboard e desafios no estilo LeetCode são estressantes, de baixo sinal e frequentemente falham em prever o desempenho no mundo real. Os comentaristas debatem alternativas como entrevistas conversacionais, tarefas simples de programação, exercícios para fazer em casa, revisão de portfólio e perguntas comportamentais estruturadas, ao mesmo tempo em que destacam a falta de competência mínima na área e o risco de viés ao confiar em “encaixe cultural” ou entusiasmo por notícias de tecnologia. Várias vozes enfatizam que a habilidade do entrevistador, a clareza sobre o que está sendo avaliado e o respeito pelo tempo e pela dignidade dos candidatos são tão importantes quanto o formato específico usado.
Limites dos Desafios de Programação e dos Whiteboards
- Muitos relatam que testes para fazer em casa, programação ao vivo e quebra-cabeças são desagradáveis para ambos os lados e raramente revelam problemas que não apareceriam em conversa.
- Outros argumentam fortemente que, sem programação ao vivo, muitos contratados não conseguiriam escrever nem loops básicos ou algoritmos simples, apesar de currículos e comunicação fortes.
- Os quebra-cabeças algorítmicos padrão do “LeetCode” são criticados por selecionar preparação para testes e tolerância à pressão, e não habilidades relevantes para o trabalho.
Necessidade de Verificação de Habilidades Básicas
- Vários entrevistadores insistem em verificações de programação muito simples (por exemplo, loops, operações com listas, transformações básicas de dados) para identificar candidatos que “falam bonito”, mas não conseguem programar.
- Há desacordo sobre quanta pressão é justa: alguns querem tarefas triviais e de baixo estresse; outros aceitam pressão moderada como algo inevitável.
Objetivos da Entrevista: Resolução de Problemas, Comunicação, Encaixe
- Muitos preferem entrevistas conversacionais: revisar projetos anteriores, designs de sistemas, amostras de código ou código fornecido pelo candidato, investigando a profundidade do entendimento.
- Sinais desejáveis: abordagem sistemática, capacidade de explicar trade-offs, disposição para dizer “não sei” e colaboração construtiva.
- Alguns esperam que seniores articulem a abordagem e o design antes de codificar; outros observam que o design real normalmente acontece ao longo de horas, não de cinco minutos em um whiteboard.
Cultura, Personalidade e Viés
- “Aderência à cultura” é vista como ao mesmo tempo necessária e arriscada: pode garantir colaboração tranquila, mas também pode incorporar viés e reduzir a diversidade.
- Perguntas sobre “notícias de tecnologia”, “novas tecnologias” ou atividades sociais (por exemplo, festas, bebidas) podem filtrar implicitamente por bolha social, estilo de vida ou personalidade.
- Vários observam que muitos bons desenvolvedores não gostam de testes sob alta pressão ou de socialização forçada, e que eliminá-los por isso pode ser contraproducente.
Falta de Padrões e Competência Básica
- Uma reclamação recorrente: os níveis de habilidade dos candidatos variam muito, e currículos são maus preditores.
- Alguns sugerem um “exame de ordem” do programador, leve e para toda a indústria, para garantir proficiência mínima (loops, condicionais, raciocínio básico); outros temem que isso recrie barreiras caras de credencialização.
Projeto do Processo e Evidências de Pesquisa
- Melhorias sugeridas: menos rodadas, planos claros sobre o que avaliar e entrevistas comportamentais estruturadas (“me conte sobre uma vez em que…”) com rubricas consistentes.
- Um comentário cita psicologia industrial/organizacional: testes de amostra de trabalho e entrevistas estruturadas estão entre os mais preditivos; conversas não estruturadas são mais enviesadas e geram menos sinal.
- Também há preocupação de que muitos entrevistadores não são bons em avaliar habilidades ou em definir expectativas precisas.