Entrevistas de live coding medem apenas estresse, não habilidade de programação

• Entrevistas de live coding na prática medem melhor a resposta ao estresse do engenheiro do que sua capacidade de programar
• Segundo pesquisas científicas, em um ambiente observado em tempo real surgem queda da capacidade cognitiva e grande variação de desempenho
• Especialmente no caso de candidatas mulheres, foi observado que todas foram reprovadas em ambiente público, mas todas passaram em ambiente privado
• Em grande parte das empresas, não se exige adaptação ao estresse, mas isso acaba sendo avaliado de forma equivocada por meio de testes de programação
• Testes simulados, exposição gradual e alguns nutrientes auxiliares podem ajudar a reduzir o estresse

---

Experiência pessoal com entrevistas de live coding

• Algumas pessoas gostam de entrevistas de live coding, mas o autor não
• Durante o processo seletivo da Toptal, o autor falhou no teste de live coding, mas quando refez sozinho conseguiu resolver rapidamente
• Essa experiência o levou a perceber que sob vigilância em tempo real, o estresse impede que ele demonstre sua capacidade real

O cérebro reage ao estresse

• Em situações de alto risco e pressão de tempo, a amígdala do cérebro é ativada e os níveis de cortisol aumentam
• Como resultado, a função do córtex pré-frontal, responsável por raciocínio complexo e memória, é prejudicada
• A memória de trabalho é o indicador mais importante para avaliar a capacidade de resolver problemas novos, e ela diminui bastante em situações de codificação em tempo real
• Mesmo em casos de ansiedade de desempenho leve, torna-se quase impossível pensar com clareza
• Fica difícil se concentrar, lembrar de várias etapas ao mesmo tempo e a pessoa passa a sentir como se fosse “muito pior do que normalmente é”

Resultados decisivos de pesquisa

• Em um artigo conduzido por pesquisadores da Microsoft, o mesmo problema de programação foi resolvido em ambiente privado e ambiente público para comparação
• No ambiente privado, a pessoa trabalhava sozinha em uma sala; no ambiente público, precisava resolver diante de um supervisor explicando seu raciocínio em voz alta
• Como resultado, em ambiente observado o desempenho caiu pela metade, e especialmente a variação nos resultados aumentou bastante
• Diferentemente dos candidatos homens, todas as candidatas mulheres no ambiente público foram reprovadas, enquanto no ambiente privado todas passaram
• O ambiente de live coding funciona como um filtro de exclusão cientificamente comprovado que elimina engenheiros competentes

A realidade do desempenho sob estresse

• No fim das contas, live coding é apenas uma medida indireta de desempenho em situação de estresse
• Algumas empresas realmente procuram pessoas que rendam bem sob pressão, mas a maioria não deixa isso claro na vaga
• Considerando que a maior parte do trabalho tem pouco estresse em tempo real, eliminar excelentes engenheiros por cometer erros em live coding é inadequado
• Faz mais sentido dizer que live coding mede níveis de hormônios do estresse mais do que habilidade de programação

Como reduzir o estresse

• Como live coding é comum no setor, é necessário treinamento de adaptação ao estresse
• É possível acostumar o cérebro ao estresse com prática repetida em ambientes parecidos com o real (Pramp, Interviewing.io, testes simulados do LeetCode etc.)
• Praticar com timer, gravando a si mesmo ou pedindo para um amigo observar, aumentando a pressão aos poucos, pode ser eficaz
• Além disso, também é possível testar nutrientes como L-tyrosine (reposição de neurotransmissores sob estresse) e L-theanine (relaxamento e melhora do foco)
• Antes da entrevista real, é essencial confirmar em testes simulados qual método funciona melhor para você

Conclusão

• Ter dificuldade com live coding não significa falta de aptidão como engenheiro, mas uma característica humana comum

[GN⁺]

Comentários no Hacker News

• Não pretendo generalizar meu caso, mas quero compartilhar minha experiência pessoal. Hoje sou um indie developer autônomo bem-sucedido. Um dos principais motivos pelos quais nunca abandonei o desenvolvimento indie, mesmo nos tempos difíceis, é que eu havia me tornado, na prática, impossível de contratar. Sou um homem de meia-idade em um setor de tecnologia fortemente etarista, não tenho diploma em Ciência da Computação e, em entrevistas de live coding, minha mente simplesmente trava. Quero apontar que nem todo estresse é igual. Bombeiros entram correndo em prédios em chamas, mas podem sentir pavor de falar em público diante de desconhecidos. Eu também aguento bem o estresse normal do trabalho, mas a ideia de alguém me observando por cima do ombro enquanto decide meu futuro financeiro é tão pesada que chega a me embrulhar o estômago. Depois que a entrevista termina, muitas vezes consigo resolver o problema de programação sem dificuldade. Os entrevistadores podem achar que sou uma fraude, mas quase 20 anos de carreira provam o contrário. Muita gente parece tratar false negative como algo aleatório, mas há pessoas como eu que são sempre eliminadas. Eu sempre fracasso em entrevistas estilo audição; não sou alguém que performa bem no palco.

  • Me identifico demais com essa situação de ser avaliado enquanto outras pessoas observam. Tenho pouco mais de 60 anos. Entre meus 20 e 30 anos eu até me saía razoavelmente bem em entrevistas, mas com o tempo senti que o processo ficou cada vez mais adversarial. Antes parecia haver um clima de “vamos tentar te contratar”; agora parece mais “vamos encontrar um motivo para não te contratar”. Isso pode ter a ver com etarismo, mas também vejo uma mudança no clima do setor. Nos últimos 15 anos, minhas experiências de entrevista ficaram progressivamente mais desagradáveis, e cheguei a ter pânico durante entrevistas. Ainda assim, de algum jeito fui contratado, e também fiz contratos sem entrevista graças ao meu histórico. A última startup em que trabalhei ficou sem dinheiro no fim de 2022, e decidi me aposentar. Eu realmente adorava o trabalho e ainda mexia com tecnologia de ponta, mas o principal é que eu simplesmente não conseguia mais suportar entrevistas.

  • Acho que o próprio formato é o problema. As entrevistas de programação de hoje parecem feitas para verificar se gente jovem fez dever de casa de estruturas de dados em CS. Talvez isso fizesse sentido em lugares como a FAANG na década de 2010, onde havia contratação em massa, mas em empresas pequenas e médias seria muito melhor focar em situações reais de trabalho, como ler código de verdade ou discutir edge cases. Trabalhei mais de 20 anos em startups e ainda assim não passo nesse tipo de teste. Também me recuso a decorar coisas à força. Se isso significa que não sirvo para essas empresas, tudo bem. Já fui CTO, lancei várias empresas e gerenciei times com competência, mas ainda assim agora sou tratado como um recém-formado. Uma vez fui rejeitado porque não consegui implementar uma cache LRU de forma rápida e elegante, e sinceramente questiono o quanto isso é necessário numa startup hoje. Nem lembro a última vez que precisei disso. O fato de eu não conseguir resolver isso na hora pode me fazer parecer incompetente, mas não vejo sentido em cobrar algo que não se usa na prática. É como contratar um arquiteto pela habilidade com uma régua de cálculo. Esse tipo de contratação acaba produzindo bases de código complexas demais, quando o que realmente importa é atingir objetivos de negócio, não a complexidade em si. Quero trabalhar com colegas que saibam quebrar problemas e manter lógica e estrutura simples. Selecionar pessoas inteligentes via leetcode tem seu valor, mas é melhor alguém que resolva problemas reais com consistência e eficácia.

  • Já vivi isso do lado de quem contrata. Fiz uma entrevista por telefone com um estudante que vinha participando de um projeto havia bastante tempo, e parecia claro que ele não estava conseguindo mostrar sua capacidade por causa de vários estresses e da barreira do idioma. Eu estava disposto a mudar o formato, mas o próprio candidato disse que não queria mais tentar. Por outro lado, se você mudar para uma entrevista de programação assíncrona, talvez acabe apenas testando se a pessoa usa LLM. No fim, se eu tiver de escolher entre filtrar quem trava na entrevista ou filtrar um impostor completamente incapaz, prefiro filtrar o primeiro caso.

  • Vejo muito esse desalinhamento de perfil nas empresas. Muitos programadores são introvertidos, enquanto muita gente que contrata é extrovertida. Se essa diferença não for bem administrada, talentos introvertidos acabam excluídos ou incompreendidos. Ambientes de open seating têm um problema parecido. Gestores podem gostar da colaboração, mas para pessoas introvertidas é um ambiente muito duro.

  • Fiquei curioso para saber em que momento você começou a ter sucesso como desenvolvedor indie. Também estou chegando aos 40, programo como hobby há muito tempo e no ano passado decidi levar isso a sério profissionalmente. Tenho muitos projetos públicos no GitHub, várias experiências de sucesso em outras áreas e não sou ruim de comunicação. Mas tenho dificuldades em live coding. Queria ouvir sua visão sobre caminhos de contribuição independente, onde seja possível mostrar capacidade real. Se eu realmente tenho essa habilidade, quero ser pago por isso.

• Esta semana entrevistei um candidato para Data Engineering. Dei quatro consultas SQL bem básicas, e ele leu os problemas em voz alta e logo em seguida produziu a resposta com sintaxe correta. A última era só um pouco mais difícil, e aí ele travou. Quando eu disse “verifique o resultado”, ele não entendeu e ficou na defensiva. Quando falei “faça um dump da tabela”, ele simplesmente não entendeu e só ficou dando desculpas. No fim, o SQL que ele colou continha saída de [redacted].ai. Provavelmente ele resolveu os primeiros problemas com IA e foi desmascarado no último. Sem esse tipo de problema técnico, não teríamos detectado a fraude.

  • Ferramentas de fraude com IA em entrevistas estão extremamente disseminadas entre os mais jovens. Em alguns casos é óbvio, mas candidatos experientes conseguem esconder o uso de IA preenchendo as pausas com coisas como “não estou ouvindo” e afins. No grupo de gestores do qual faço parte, esse é o tema de contratação mais discutido recentemente. Empresas que têm recursos estão fazendo a última entrevista presencialmente. Tem gente que parece aceitável numa tela remota, mas ao vivo não consegue responder nem perguntas básicas, então acaba reprovada. É perda de tempo e dinheiro, mas ainda melhor do que o custo de uma contratação errada. O uso de IA está se espalhando não só nas entrevistas técnicas, mas também em currículos, perguntas comportamentais e até respostas no formato S.T.A.R. geradas pelo ChatGPT. Verificação de referências confiáveis se tornou mais importante do que nunca. Já vivi várias vezes a situação em que um ex-chefe descreve um trabalho totalmente diferente do que está no currículo. Se a pessoa tivesse sido honesta desde o início ao dizer que não tinha experiência direta no nosso domínio, talvez eu até a contratasse. Mas quando a mentira é tão forte assim, a confiança desaparece completamente.

  • Nas entrevistas de candidatos hoje em dia, cerca de 50% usaram GenAI ao vivo em tempo real. Até agora tem sido muito fácil perceber quem está usando IA. Em uma conversa natural isso aparece rápido. Ironicamente, o último candidato também sempre repetia o problema em voz alta e depois esperava de 10 a 15 segundos. Isso mostra que esse tipo de teste em si não resolve o problema de fundo. Pelo contrário, cria novos problemas e derruba candidatos excelentes.

  • “E se usar IA não fosse fraude, mas apenas uma prévia do que a pessoa vai fazer no trabalho real?” Se você olhar por esse ângulo, a entrevista foi na verdade um exemplo muito eficaz, em pequena escala, de <i>interpretação de requisitos</i>. No fim, acho mais positivo caminhar para um formato em que a pessoa possa usar livremente as ferramentas que usará no trabalho e, dentro disso, você teste o entendimento real da função e da linguagem. Só precisamos sair do LeetCode e encontrar uma forma melhor.

• No fim das contas, tudo depende do contexto. Com entrevistas de live coding é a mesma coisa. Não é a melhor experiência do ponto de vista do candidato, mas em empresas grandes como Meta e Google elas reduzem melhor a taxa de false positive do que outras abordagens. Dito isso, os entrevistadores muitas vezes não são bem treinados e os problemas frequentemente parecem enigmas demais, o que torna tudo muito difícil para quem não passou muito tempo treinando LeetCode ou não veio da academia ou recém-formado. Trabalhei seis anos com avaliação (assessment) e vi de perto muitos processos seletivos, de Fortune 10 a startups. Sempre recomendo avaliações parecidas com o trabalho real do candidato, e hoje já não gosto da expressão “trabalho real” quando ela beira trabalho não remunerado. A avaliação deveria ser um meio para a empresa se sentir segura ao oferecer um salário alto. Com a chegada da IA, até tarefas curtas de take-home ficaram difíceis de manter justas. Por isso, algumas empresas estão voltando a depender de extremos como entrevistas on-site e monitoramento em tempo real. Minha solução ideal seria dar a todos os candidatos o mesmo tempo, ambiente e ferramentas para que possam mostrar sua melhor capacidade. Penso nisso o tempo todo, mas ainda não encontrei a resposta.

  • Dizem que “funciona em empresas como Meta e Google”, mas na verdade não há dados. Já trabalhei com desenvolvedores de nível F vindos de Facebook e Google. Na prática, essas grandes empresas ainda demitem 3% a 5% da força de trabalho, o que é evidência de que entrevistas por si só não conseguem filtrar bem false positives. Considerando o tempo que os entrevistadores investem, acho uma taxa de erro de 3% alta demais. No fim, isso não é tão diferente do velho teste de Fizzbuzz.

  • É como se você não pedisse para o pedreiro construir uma parede, mas o contratasse imediatamente só por ter mostrado um certificado. Muitas profissões funcionam assim. Se a pessoa não tiver o nível esperado, você a desliga depois da contratação. Não há necessidade de passar por um processo humilhante de entrevista corporativa.

  • Os melhores engenheiros que conheci muitas vezes acabavam classificados como false negative. Ficam nervosos em entrevistas de live coding e não conseguem mostrar o que sabem. Não dá para afirmar com tanta segurança que esse tipo de entrevista “funciona”.

  • Dizer “depende do contexto” e logo depois afirmar que “entrevistas de live coding funcionam” não faz sentido. Eu poderia inverter e dizer: “depende do contexto, e entrevistas de live coding não funcionam”. Não há diferença lógica.

  • Passar em leet-code realmente serve para filtrar pessoas sem capacidade real de resolver problemas. A melhor solução seria criar um ambiente em que o candidato consiga performar no máximo, com suas próprias ferramentas e no seu próprio ambiente. Mas, na prática, às vezes penso que o mais justo talvez fosse resolver problemas de leetcode presencialmente, num quadro branco, fazendo pair programming com o entrevistador. Isso sim seria um ambiente realmente confortável.

• Acho que as duas explicações podem ser verdade ao mesmo tempo. Existem desenvolvedores “sêniores” que de fato não conseguem fazer o trabalho, e live coding ajuda a filtrar essas pessoas. Mas também há muitos outros motivos pelos quais alguém pode falhar numa entrevista.

  • Há também muitos desenvolvedores que se saem bem em live coding, mas não têm experiência de design de sistemas em grande escala. Essas pessoas muitas vezes introduzem dívida técnica, anti-patterns, inconsistências e outras coisas que pioram ainda mais a base de código. Na prática, esse é o tipo que realmente deveria ser evitado. As empresas acreditam que sêniores existentes vão controlar os novatos, mas toda empresa diz “nossa base de código é lixo”, então essa defesa também não parece funcionar muito.

  • Se você simplesmente deixar a pessoa sentada sozinha num quarto codando, não perderá ótimos talentos que só falham em ambientes artificiais.

  • Hoje o live coding já passou de um simples teste de programação. Muitas vezes exige memorizar um monte de algoritmos e combinar dois ou três deles em 30 minutos para resolver um problema. A pessoa gasta todo o tempo tentando chegar à solução e nem sobra espaço para mostrar habilidade real de escrever código.

  • Em 20 anos de carreira, nunca trabalhei de fato com um desses “sêniors incompetentes”. Bastava olhar o currículo e conversar 15 minutos para filtrá-los. Em compensação, já vi muito mais gente passar em entrevista de quadro branco e depois prejudicar a produtividade do time.

  • Não entendo por que um ambiente com prazo curto e exigência de pensar e explicar ao mesmo tempo, em frente a um quadro branco, seria algo essencial. Se o objetivo é filtrar quem não consegue trabalhar de verdade, não precisa ir tão longe.

• Na minha visão, a única forma de verificar de verdade a capacidade de alguém para uma função é colocá-lo para fazer a própria função. Mesmo que existam métodos alternativos de avaliação, se você pode fazer a pessoa executar o trabalho real, não há motivo para usar outra coisa. Se o trabalho da empresa é tão complexo que não dá para recortar uma parte e usar na entrevista, talvez a própria empresa esteja fazendo coisas desnecessariamente complexas. Por exemplo, se você precisa saber se alguém consegue levantar 10 quilos, basta pedir que levante 10 quilos de verdade. Em vez disso, o que fazem é algo como: “vamos avaliar sua força, então tire as calças e levante um balde de 1 kg com as nádegas”. No fim, basta testar as habilidades realmente necessárias para o trabalho. Se for um chef, coloque a pessoa para cozinhar numa cozinha de verdade; se for atendimento, observe a comunicação em uma situação simulada. Até para triagem por telefone, dá para mostrar uma tela ao vivo.

  • Há o contra-argumento de que, se você colocar a pessoa para fazer trabalho real na entrevista, surgem questões de fraude ou exploração de trabalho não remunerado. Se a empresa aproveitar o resultado do teste, isso pode até virar problema jurídico.

  • Também existe a proposta de contratar a pessoa por um dia, uma semana ou um mês para testar na prática e, se houver encaixe, efetivar. Mas esse modelo não combina com o sistema americano de employer healthcare.

  • Do ponto de vista da empresa, isso toma tempo demais. Por isso usam um proxy enviesado para false negatives, em vez de false positives.

  • Também queria saber o que você pensa sobre a preocupação de que pedir trabalho real em entrevista possa ser visto como exigência de “trabalho grátis”.

  • Como leva muito tempo para alguém se adaptar a uma nova organização, testar com trabalho real pode até ser menos eficiente. Uma avaliação de live coding talvez seja melhor para medir comunicação, resolução de problemas e habilidade pura de programar.

• Depois que tive filhos, minha capacidade de programar em entrevistas despencou. Antes isso nunca acontecia, mas hoje parece que coisa demais está em jogo. Quando penso em plano de saúde, financiamento, aposentadoria e tudo mais, a pressão fica muito forte. Eu simplesmente travo durante a entrevista, e é angustiante perceber a solução só depois que termina. Quanto mais tempo invisto em prática, pior parece ficar. E, com dependentes, ainda vem a culpa por gastar tempo treinando. O retorno no aprendizado é pequeno e eu acabo ainda mais inseguro. Trabalhando em big tech, percebi que esse tipo de entrevista foi adotado com a ideia extremamente “vamos testar todo mundo de forma igual”, mas na prática ignora completamente mudanças e desequilíbrios nas circunstâncias de vida de cada um. Um colega resistente ao estresse hoje pode estar muito diferente alguns anos depois. Começa com o discurso de eliminar viés, mas acho que o formato precisa mudar.

  • Você não está sozinho nesse sentimento. Com a idade, a velocidade de aprendizado diminui, o tempo livre encolhe e a eficiência de treino de leetcode cai. É irritante ver que, no fim, quem tem mais tempo disponível é recompensado.

  • Como forma de aliviar o estresse, recomendo tentar meditação, respiração, L-Theanine e beta-bloqueadores. Também sugiro monitorar frequência cardíaca e pressão arterial com um smartwatch. Na prática, esses métodos ajudam a quebrar o ciclo do estresse.

• É um ambiente de estresse muito intenso e qualitativamente diferente do estresse do trabalho real. Compartilhando minha experiência em entrevista com o Google: fui a pessoa que criou o primeiro mecanismo regional de busca da Holanda, e no Google um entrevistador de chapéu de caubói me mandou escrever busca binária no quadro branco com canetão. Eu quase nunca escrevo à mão, só uso teclado, e além disso ninguém quis olhar minha experiência projetando índices de busca. Talvez o Google só quisesse gente com mentalidade de “caubói”.

  • Eu também, anos atrás, fui convencido por um recrutador do Google a fazer entrevista, mas os entrevistadores eram tão ruins que, mesmo tendo pulado a entrevista técnica, desde então rejeito qualquer proposta do Google. A maioria das perguntas era em estilo “pegadinha” ou tratava de estruturas antigas de UNIX sem qualquer relação com a realidade, como inode. Não tinha nada a ver com a função em questão. As empresas precisam obrigatoriamente rastrear perguntas de entrevista, coletar feedback e treinar entrevistadores. Ainda há muitas empresas em que as perguntas são definidas de acordo com o gosto pessoal do entrevistador.

  • Na verdade, esse formato funcionou exatamente como foi projetado para funcionar. Essas empresas querem pessoas dispostas a suportar qualquer humilhação para trabalhar lá. Como vocês não tinham fit, no fim os dois lados saíram ganhando.

  • Se você se sentiu humilhado por pedirem busca binária, talvez seu ego seja grande demais.

  • Se estivessem em jogo US$ 250 mil por ano e mais stock options do Google, eu toparia tranquilamente sofrer uma “humilhação” por um dia.

• Eu trato live coding screening como uma “conversa sobre código”. Deixo claro para o candidato que o objetivo da entrevista é verificar se conseguimos nos comunicar bem. Só ter habilidade técnica não basta; a pessoa precisa conseguir colaborar. Por exemplo, se durante a conversa ela implementa algo errado por mal-entendido, ou se escreve código muito bem mas é incapaz de sustentar uma conversa técnica, isso é um problema. Por isso perguntas do tipo Fizzbuzz são importantes: não apenas para testar competência, mas para avaliar a capacidade de discussão técnica.

  • Exato. A essência da entrevista de live coding não é “a pessoa consegue resolver o problema?”, e sim “ela consegue explicar como resolveria?”. Um mínimo de fundamentos técnicos e habilidade de comunicação é o ponto central. Uma parte significativa do trabalho real é explicar coisas para gestores não técnicos, então dá para pensar nisso como uma forma de testar isso.

  • Gosto desse formato. Eu consigo resolver FizzBuzz em pelo menos 3 linguagens, de 4 maneiras diferentes, e tenho confiança para explicar todas as 12.

• Eu também reconheço esse problema e concordo que não existe uma alternativa perfeita. Ao longo da carreira, vi muitas vezes pessoas que “falam e agem como engenheiros”, mas na prática não sabem programar. Também já me arrependi várias vezes de ter deixado passar capacidade de programação em entrevistas. Gostaria que desenvolvedores mais jovens entendessem que várias etapas do processo seletivo acabam favorecendo candidatos mais velhos. Sei muito bem que há muitos engenheiros no setor com embalagem de “especialista” mas sem habilidade real de codar. Contratar alguém sem nunca observar o processo de programação é como contratar um guitarrista para a banda olhando apenas currículo, conversa e referências. Pode acabar entrando um “especialista em guitarra” que nunca tocou guitarra de verdade. Pessoas assim de fato existem e passam por processos desse tipo. Quando, na entrevista, você só pode inferir sem evidência direta, viés e preconceito inevitavelmente entram em cena.

  • Em resposta à ideia de que “há problemas, mas não há alternativa”, existem sistemas baseados em licenças e certificações, como para médicos e advogados. Ninguém exige que um médico faça uma cirurgia de demonstração antes de operar. E o risco é muito maior. Na verdade, os processos de verificação mais duros ficam para cargos inferiores, enquanto gestores e cargos mais altos, cujo impacto é maior, passam com mais facilidade.

  • Acho melhor pedir para a pessoa escrever pseudocode no quadro branco. Isso reduz o estresse com sintaxe e permite enxergar melhor a lógica de resolução. Ao mesmo tempo, combina bem com meu estilo de colaboração, que é trocar ideias juntos no quadro.

• Esse fenômeno de “estresse é diferente de habilidade” continua aparecendo o tempo todo. Até aquele artigo da Microsoft foi desastroso. A maior parte dos conselhos é só “faça mais LeetCode”, ignorando completamente o estresse (cortisol). Eu pratico tentando me acostumar com o próprio ambiente de estresse. Amigos não conseguem simular uma pressão forte o bastante, e coach sai caro demais por hora. Por isso estou desenvolvendo agora um projeto paralelo chamado Tough Tongue AI. É um editor de código ao vivo com resposta por voz, que faz perguntas em tempo real, interrompe e dá feedback imediato. Esse treino vai tornando cada vez mais familiar a sensação de “tem alguém me observando”. Se entrevistas de live coding continuarem existindo, então precisamos de um jeito de treinar não só algoritmos, mas a própria resposta fisiológica ao estresse.

  • É uma das melhores ferramentas de aprendizado.