Pessoas cansadas de entrevistas no estilo LeetCode

• Depois de sair da Robinhood no fim de novembro de 2023 por questões de saúde, passou por vários processos seletivos e sentiu que as avaliações no estilo LeetCode não combinam com o trabalho real de engenharia de software
• Acredita que muitas empresas repetem entrevistas parecidas ao seguir o modelo de grandes empresas de tecnologia como Google, Facebook/Meta e Amazon
• Critica o fato de que engenheiros dizem não precisar decorar conhecimento pesquisável, mas nas entrevistas fazem perguntas em formato de quiz sobre coisas difíceis de lembrar na hora
• Já passou tanto por sucesso quanto por fracasso nesse tipo de entrevista, e a base dessa insatisfação tem mais relação com a experiência prática anterior do que com experiências de reprovação
• Acrescenta que podem entrar em contato caso sejam uma empresa que procura um engenheiro com experiência em AWS, Kubernetes e Ruby on Rails e que não faça quizzes inúteis

---

Onde entrevistas no estilo LeetCode divergem do trabalho real

• Depois de sair da Robinhood no fim de novembro de 2023 por motivos de saúde, participou de entrevistas com várias empresas
• Os processos não avançaram por diversos motivos, mas sentiu cansaço com a repetição das entrevistas no estilo LeetCode em si
• Considera que esse tipo de entrevista não reflete adequadamente as responsabilidades reais de engenharia de software
• Parece que muitas empresas adotam o mesmo modelo de avaliação porque grandes empresas como Google, Facebook/Meta e Amazon usam esse método

O choque entre avaliações em formato de quiz e experiência prática

• Há engenheiros que dizem no dia a dia que não é necessário decorar conhecimentos que podem ser facilmente encontrados no Google
• Mas, nas entrevistas, às vezes perguntam sobre conteúdos que poderiam ser pesquisados, mas que são difíceis de lembrar de imediato, o que parece contraditório
• Não há uma solução clara para esse problema, mas considera que o problema em si é evidente
• Já vivenciou tanto sucesso quanto fracasso nesse tipo de entrevista, e essa visão foi mais influenciada pela experiência profissional anterior do que pela taxa de reprovação
• Diz que podem entrar em contato se precisarem de um engenheiro de software com experiência em AWS, Kubernetes e Ruby on Rails e que não façam entrevistas em formato de quiz
• Sugere também a leitura de Re-imagining Technical Interviews: Valuing Experience Over Exam Skills

[GN⁺]

Opiniões no Hacker News

• Entendo a frustração, mas no fim acho que esse tipo de entrevista também tem um propósito. Mesmo que não seja perfeito, é suficientemente utilizável e, em geral, faz sentido para a empresa porque tende a produzir mais falsos negativos do que falsos positivos
  O custo de deixar uma pessoa inteligente de fora é baixo, mas contratar a pessoa errada custa caro, porque é preciso passar meses avaliando, demitindo e contratando de novo. Dito isso, para o candidato é um processo extremamente doloroso, e mesmo um excelente engenheiro de software pode ficar nervoso, deixar algo passar ou ter um dia de azar e acabar reprovando algumas vezes. A entrevista não é uma avaliação final do seu valor na vida, é só uma ferramenta grosseira, então o melhor é seguir em frente

  • Nas empresas que eu toquei, por isso usávamos um exemplo simples no quadro branco. Não nos importávamos com erros de digitação; queríamos ver como a pessoa pensava
    Perguntas “pegadinha” são idiotas, mas é preciso ver se o candidato conhece o básico e, ao mesmo tempo, mostrar que tipo de empresa somos. Por exemplo, perguntar “posso modificar os argumentos?” ou dizer “não lembro se strlen inclui o byte 0, então vou somar 1; normalmente eu procuraria isso” é um bom sinal. O problema era algo como atoi ou “embaralhar um baralho”, básico, mas não tão trivial quanto FizzBuzz. Uma das melhores pessoas que contratamos cometeu um erro fundamental, mas, quando perguntamos se aquilo funcionaria como pretendido, disse “sou um idiota do caralho” e corrigiu na hora. Esse tom talvez não seja adequado numa entrevista, mas vimos como um forte sinal positivo. Por outro lado, também houve um candidato que insistiu até o fim que uma pergunta sobre fazer o parsing de uma string e retornar um inteiro era injusta porque já existia uma função de biblioteca; na prática, parte do nosso sistema rodava em um ambiente embarcado sem biblioteca
  • Mesmo que você faça um quiz, deveria deixar as pessoas pesquisarem. Engenheiros de software trabalham assim na prática; não se deve transformar isso em uma prova
    Eu gostaria que não imitassem aquele formato horrível de provas de escolas e universidades, que primeiro testam memória. Eu sofro muito porque não consigo lembrar das coisas na hora quando preciso, e certamente não sou o único. Quando eu entrevistava desenvolvedores Android, fazia perguntas e observava a forma de pensar, sem esperar que todas as respostas fossem exatas. Depois de verificar se havia uma compreensão básica de Android, pedia que a pessoa fizesse um pequeno app em casa
  • Já vi o argumento de que “pessoas inteligentes são reprovadas e raramente se contratam idiotas”, mas fico em dúvida se isso é realmente verdade. Ainda mais se você também acredita em outra crença comum do recrutamento, a de que “a maioria dos candidatos não é qualificada”
    No fim, em uma contratação em que a vaga precisa ser preenchida, quanto mais falsos negativos houver, maior também será a probabilidade de contratar um falso positivo. No extremo, se só existe uma pessoa no planeta adequada para aquele trabalho e você a reprova como falso negativo, a única opção restante é contratar a pessoa errada
  • Esse tipo de entrevista também cria muitos falsos positivos. Só que não no sentido de “contratar idiotas”, e sim de contratar pessoas que são boas em LeetCode, mas não têm nada a ver com o trabalho real
    O problema não é falta de inteligência; é que a pessoa pode resolver bem problemas de algoritmo, mas não ser engenheira de software, ou não ter as capacidades exigidas por aquela posição. Trabalho em uma equipe contratada em grande parte por entrevistas com puzzles, e todos são inteligentes, mas não são engenheiros de software, e essa diferença aparece muito
  • Problemas difíceis de LeetCode selecionam pessoas que treinaram repetidamente, não pessoas que pensam. Muitos desses problemas, quando foram resolvidos pela primeira vez décadas atrás, dariam artigo acadêmico, e é difícil até para pessoas muito inteligentes derivar do zero um resultado parecido em dezenas de minutos
    Se alguém resolveu, é muito mais provável que tenha visto um problema igual ou parecido fazendo exercícios do que realmente derivado uma solução ótima nova

• Uma vez fiz uma entrevista de que gostei bastante; era em um banco. Eles me deram um código sujo, escrito às pressas, mas não ofuscado de propósito, e pediram para eu refatorar da melhor forma possível
  O entrevistador ficou sentado ao lado e conversou comigo durante todo o processo; na prática, foi quase uma sessão de programação em par conduzida pelo candidato. Depois de entrevistas de LeetCode, foi uma experiência refrescante. Claro, aquele banco sabia exatamente quais tecnologias usava e tinha menos necessidade de medir a capacidade de aprender tecnologias novas, então esse formato era possível. Para eles, era mais importante saber se a pessoa conseguia produzir código manutenível, escolher bons nomes e se comunicar com colegas

  • Entrevistas de LeetCode também não medem a capacidade de aprender tecnologias novas do candidato, medem?
  • Eu também uso bastante esse formato de entrevista. O começo é bem básico e, como meu trabalho é principalmente com bancos de dados, depois passo para uma etapa de revisão de código
    O interessante é que já houve pessoas que quase fracassaram nas perguntas básicas, mas se saíram tão bem na revisão de código que revelaram profunda especialização. Entrevistas são uma ferramenta bastante ruim para mostrar a capacidade de trabalho de alguém, mas, se a pessoa consegue enxergar o problema tanto de forma ampla quanto específica e também programar suficientemente bem, em geral considero um sucesso

• Entrevistas no estilo LeetCode provavelmente cumprem duas funções. Primeiro, são um meio de conter os salários e a mobilidade de engenheiros de software. Para trocar de emprego, a pessoa precisa estudar por um ou dois meses; quem mudaria com facilidade assim?
  Se você der azar e pegar um entrevistador que se preparou demais e joga uma bomba no nível LeetCode hard, fica difícil se candidatar de novo àquela empresa por um ano. Segundo, elas servem para encobrir vieses do processo, sob a alegação de que deram a todos um objetivo parecido e claro. Se a pessoa for da mesma escola, gênero ou raça, mesmo recebendo o mesmo problema, podem dar dicas, relevar erros de sintaxe e, mesmo que ela não chegue à abordagem ótima, dar uma avaliação forte de contratação por causa da “comunicação”. Se não gostarem da pessoa, basta jogar um problema difícil e ficar em silêncio durante a entrevista inteira. Para a empresa, é um ruído aceitável; para o indivíduo, é perder uma oportunidade de remuneração de centenas de milhares de dólares. Já fiz entrevistas em FAANG e também já fui entrevistador, e vi pessoas contratadas com critérios baixos ao mesmo tempo em que ótimos engenheiros perdiam oportunidades por causa de perguntas absurdas como árvores quádruplas ou teoria dos números

  • Em qualquer processo, se alguém estiver decidido, pode agir de forma injusta, mas acho que ter uma prova padronizada torna o processo muito mais justo
    Partindo da premissa de um entrevistador justo, esse método dá a candidatos que não têm nomes famosos no currículo uma chance de mostrar competência. Algumas das oportunidades que tive, sem ter diploma em ciência da computação, jamais teriam existido se não fosse por entrevistas no quadro branco. É difícil imaginar uma forma de impedir um entrevistador de distorcer o processo de propósito para contratar um amigo
  • O problema descrito aqui não é o LeetCode em si, mas a variação entre entrevistas e o viés de contratação. Isso aparece em qualquer formato de entrevista
    Muitas empresas têm bancos de questões projetados para serem justos e, em alguma medida, relacionados a problemas reais. As empresas em que entrevistei em geral eram assim e, mesmo quando não eram problemas literalmente do LeetCode, no fim ainda eram problemas isolados de programação, então considero isso estilo LeetCode. As entrevistas de empresas que operavam bem esse método foram bastante razoáveis. Boas empresas e bons entrevistadores olham para mais coisas do que apenas o código final, e também dão notas de contratação em uma escala, reduzindo o binarismo
  • O problema não é o formato em si de uma entrevista simples de programação de 30 a 50 minutos e de estruturas de dados e algoritmos, mas a escalada da dificuldade
    Na prática, só fizzbuzz já filtrava 75%. Muita gente não consegue escrever código sob pressão, e há também quem sobreviva na marra com copiar e colar. Não é que essas pessoas não consigam fazer nada, mas elas são lentas, produzem abstrações estranhas e consomem muito tempo até se obter um resultado aproveitável. E essas pessoas também rebatem do mesmo jeito, porque há centenas de milhares de dólares em jogo
  • Esse método também é ótimo para filtrar pessoas com restrições de tempo, como filhos, pais idosos para cuidar ou problemas de saúde
    Do ponto de vista da empresa, é racional. Ela quer funcionários que não se distraiam e possam fazer hora extra
  • Se você quer a remuneração máxima, precisa jogar esse jogo. É assim em qualquer profissão; alguém acha que é mais fácil para advogados que querem entrar nos maiores escritórios?
    Há muitas críticas válidas às práticas atuais de contratação em tecnologia, mas a reclamação de que “não dá para ficar absurdamente rico sem vender a alma” não é muito convincente

• Ao selecionar engenheiros de software, o importante não é conhecimento, mas a capacidade de resolver problemas e de construir um modelo mental do problema
  Se o candidato nunca viu aquele problema antes e o entrevistador entende o que deve observar, a entrevista no quadro branco é uma boa forma de avaliar essa capacidade. Mas, como na lei de Goodhart, quando a métrica vira objetivo, ela deixa de ser um bom indicador. Pessoas com pouca capacidade de resolver problemas ou de modelar também querem cargos de software com salários altos, então moem LeetCode; com o tempo, quando essas pessoas viram entrevistadores, conduzem entrevistas como testes de memória, assim como fizeram com elas. Ainda assim, dadas as restrições da empresa, a necessidade de reduzir perda de tempo dos candidatos e de manter uma ficha de avaliação consistente que o RH gosta, ainda não vi um método de entrevista melhor ser proposto, e isso deve continuar sendo usado por um bom tempo

  • Um método melhor é fácil de implementar. Peça ao candidato para construir algo conhecido, como uma calculadora ou um calendário, ou dê um conjunto de código para ele modificar ou encontrar bugs
    Isso fica mais próximo do trabalho de criar software. LeetCode é distante demais do trabalho real, e o desempenho tem correlação fraca demais com a adequação real
  • Também dá para concluir que uma pontuação alta no LeetCode é um bom indicador de pessoas que serão substituídas por LLMs
  • Dizem que “pessoas A contratam pessoas B, e pessoas B contratam pessoas C”; no fim, colocaram mais LeetCode no processo de entrevista para tentar impedir isso
  • Por que a empresa se importaria sinceramente com esse problema e tentaria tornar o processo de contratação menos hostil? Ainda há muitos candidatos dispostos a passar por qualquer prova que apareça
    É um balde furado, mas a empresa está satisfeita com o estado atual, e os desenvolvedores continuam moendo LeetCode. Não parece que vá mudar tão cedo, mas felizmente, quando procuro um novo emprego, estou em uma situação em que posso recusar esse tipo de entrevista

• Um amigo meu, no meio de uma entrevista técnica, de repente parou de falar, levantou e foi embora. O pessoal da empresa foi atrás dizendo “o que houve, você está indo bem!”, mas ele disse que tinha ficado deprimido demais e não tinha mais interesse
  É triste, porque para a maioria das pessoas deveria ser uma profissão divertida

  • Eu já fiz algo parecido. Era uma empresa de jogos famosa pelos benefícios, mas também conhecida por cronogramas de produção insanos, e no começo eu realmente queria entrar
    Só que, mais ou menos no meio da entrevista, surgiu um quadro branco e colegas entraram para me pedir que implementasse coisas básicas com uma caneta; conforme avançava, eles foram ficando cada vez mais hostis e grosseiros, a ponto de parecer uma humilhação ritualizada. Parecia que estavam testando se eu conseguia suportar insultos e hostilidade enquanto entregava resultados tecnicamente triviais. No fim, interrompi a entrevista e disse: “já vi como vocês trabalham, então decidi que não quero trabalhar aqui. Agradeço a oportunidade e peço desculpas por desperdiçarmos o tempo um do outro”, e fui embora. O CEO me seguiu até o estacionamento para perguntar por que aquilo tinha acontecido, e pareceu genuinamente chocado com o fato de um candidato poder tomar uma decisão durante a entrevista. As pessoas esquecem que uma entrevista de emprego é uma via de mão dupla. Depois daquele dia, percebi que tenho o direito de observar todos os aspectos de uma empresa onde eu talvez trabalhe, e que, se eu vir algo negativo no processo, não preciso aceitar concessões. No dia seguinte, encontrei em uma concorrente pessoas que até hoje são bons amigos e colegas, então foi a decisão certa. Esta profissão é divertida, mas quando essa diversão é colhida e explorada como em uma fazenda, não é diferente de outras formas de escravização
  • Fiz algo parecido em uma entrevista por Zoom. Recebi um problema difícil de LeetCode hard e travei completamente, e os entrevistadores não pareciam ter intenção de ajudar
    Quando eu disse “acho que hoje não é meu dia e gostaria de encerrar a entrevista”, eles se esforçaram bastante, pelo resto do tempo, para me fazer ficar. Acho que, se o candidato quer sair, devem deixá-lo ir

• Mesmo passados 5 anos, ainda me recuso a fazer esse tipo de entrevista e não quero nunca mais passar por esse processo. Fui atormentado e ridicularizado por pessoas que tratam candidatos como se fossem um jogo de chutar alguém por uma hora, e não quero mais lidar com isso
  Como houve muitas entrevistas de LeetCode sem aviso prévio, deixei claro nos meus perfis do LinkedIn [1] e do GitHub [2] o que é aceitável e o que não é. “Tenho uma política pessoal contra qualquer forma de live coding ou teste de programação online durante entrevistas, e não gosto nem participo de programação competitiva. Em vez disso, aceito de bom grado desafios de programação offline com objetivos e prazos razoáveis, além de discussões técnicas profundas sobre arquitetura e design de software e tecnologias relacionadas.”
  [1] https://www.linkedin.com/in/mtodor
  [2] https://github.com/mihaitodor

  • Pessoas que procuram desenvolvedores poderiam até criar algo como termos de uso em conjunto. Isso poderia fazer o RH tomar conhecimento e repensar também a própria abordagem
  • Gosto da abordagem. Você pode compartilhar o quanto isso funcionou na prática?
    Dito isso, ouve-se que fraudes são generalizadas em entrevistas com tarefas para casa, então me preocupa que o número de empregadores dispostos a usá-las caia drasticamente

• Fazendo o papel de advogado do diabo, o LeetCode é usado para filtrar uma ou ambas de duas coisas na contratação de um colaborador individual médio: se a pessoa é esforçada — isto é, alguém que estudou muitos problemas, decorou soluções e consegue repeti-las —, ou se é inteligente — isto é, alguém que conhece os fundamentos e consegue sintetizar conhecimentos anteriores para responder a uma pergunta nova mesmo sem praticar LeetCode
  Na ausência de qualquer outra informação, eu diria que alguém que não consegue passar em um problema de LeetCode tem maior probabilidade de não ser nenhuma das duas coisas. Se a função exige programação, acho que a pessoa deveria conseguir resolver ao menos um problema fácil a médio de LeetCode, ainda que com alguma orientação do entrevistador. Na prática, as empresas reduzem o peso da habilidade em LeetCode quanto mais sênior é a vaga ou quanto mais especializada é a função. Também há muitas entrevistas de correção de bugs, design de sistemas, comportamentais, tarefas, perguntas de conhecimentos variados e perguntas específicas do histórico da pessoa; em contratações acima do nível júnior, LeetCode não é tudo. Não é uma ferramenta mágica para escolher os melhores engenheiros, mas apenas mais um sinal usado pelo comitê de contratação

  • Isso é uma habilidade que universitários de cursos de 4 anos aprendem por volta dos 19 anos e depois quase não usam durante os 50 anos seguintes enquanto constroem coisas de verdade
    Ela não mede a capacidade de engenharia de levar algo até o fim dentro do orçamento. Na melhor das hipóteses é algo periférico; na pior, é uma métrica substituta para discriminação etária, favorecendo pessoas mais próximas dos 19 anos. Talvez seja por isso que esta indústria tenha tanta dificuldade em entregar software de boa qualidade. Um método melhor é dar uma situação de falha, como um build quebrado ou código que está crashando, e pedir para a pessoa corrigir. Se ela consegue explorar o sistema, diagnosticar o defeito, encontrar a causa, propor um patch e seguir o estilo de código e comentários, então é alguém que realmente é necessário. Pode haver branches e um issue tracker, uma discussão de bug já em andamento, ou um arquivo de patch nos comentários que precisa ser aplicado manualmente. O patch pode conter um novo bug, ou pode ser uma isca que mexe em um problema parecido, mas não relacionado. Pode ser uma regressão de um bug fechado sem teste unitário; ou, mesmo havendo teste, o candidato talvez tenha que encontrá-lo, ou o próprio teste pode estar obsoleto e cheio de bugs. Esse é o trabalho de verdade. No fim, dizer “os testes unitários estavam quebrados” e dizer “não entendi como executá-los corretamente, então pulei” revela uma grande diferença de postura, e o jogador de equipe é o segundo
  • A maioria dos candidatos já tem emprego. Se a pessoa realmente trabalha duro, é raro que tenha energia de sobra para resolver problemas de LeetCode além do trabalho principal
    Por isso, ao contrário, você pode acabar contratando um candidato que não tem grande desempenho no cargo atual, mas gastou a energia excedente moendo LeetCode
  • Problemas de LeetCode, por definição, não podem ser próximos de problemas reais. Eles estão separados do contexto
    Depois de apenas algumas semanas em um projeto, uma pessoa inteligente consegue obter os insights realmente necessários. Os quebra-cabeças repentinos que o LeetCode lança são mais parecidos com palavras cruzadas de revistas antigas
  • Achar que alguém consegue chegar ao algoritmo de Dijkstra numa entrevista apenas a partir de princípios é uma arrogância enorme
    A única razão para conseguir fazer isso é já ter estudado antes
  • Dizem que o peso do LeetCode diminui quando você vira sênior, mas quando isso começa? Tenho mais de 8 anos de experiência e estou cansado de ouvir que preciso criar uma solução para bingo NxM em 30 minutos
    Se fosse 2022, eu concordaria que LeetCode não é uma ferramenta para escolher os melhores engenheiros, mas em 2024 as pessoas são filtradas com muito mais frequência porque, mesmo acertando o problema, não foram rápidas o suficiente ou não resolveram sem dicas. Eu não sou um gênio de LeetCode, tenho coisas demais para estudar, e o LeetCode responde por cerca de 20% das entrevistas; ainda assim, não sinto que tenha ficado tão pior do que há 2 anos. As expectativas das empresas é que dispararam para o céu, e o clima é de querer comprar cargos com mais de 15 anos de experiência pagando salário de alguém com 5 anos

• Um ponto interessante pouco mencionado sobre entrevistas ao estilo LeetCode é que elas são uma espécie de trote intelectual
  Já foi demonstrado várias vezes que, quanto mais duro é o rito de iniciação, maior se torna o comprometimento das pessoas que entram no grupo

  • O problema é que os perdedores não passam no teste, mas os vencedores passam
    Quando uma empresa capitalista contrata programadores, o que é melhor: “pessoas inteligentes e parecidas, que acreditam em respostas certas” ou “um grupo aleatório de profissionais habilidosos”? Se você responde que é a segunda opção, está sendo idealista, e essa opinião não importa de verdade. A natureza vai substituí-lo por alguém mais inteligente e realista

• Em algumas entrevistas recentes, mostramos um código de exemplo ao candidato e pedimos que ele fizesse uma revisão. O exemplo tinha pelo menos um bug ou problema em cada linha
  Depois vem uma tarefa de modelagem, geralmente feita no quadro branco. Também há um exercício simples no estilo fizzbuzz para ver se um júnior realmente consegue atuar como júnior, e isso serve como ponto de partida para conversar sobre temas como complexidade de tempo de execução ou layout de memória. O processo é bem interativo, dependendo do desempenho do candidato, com o objetivo de filtrar impostores que de algum modo passaram pela triagem e também sentir um pouco o fit cultural

  • Gosto de dar ao candidato testes unitários quebrados e pedir que os corrija em até 1 hora, no próprio ambiente e com suas próprias ferramentas, como se estivesse em casa
    Crio um problema bagunçado, como validação de fuso horário ou de número de telefone, e uso um documento da Wikipedia como especificação. Ao final, pergunto sobre a solução e fazemos uma revisão de código. Os melhores seniores simplesmente usam uma biblioteca. Bons candidatos implementam por conta própria, mas conseguem explicar os trade-offs. Juniores apenas fazem os testes passarem e param por aí
  • O que costumo usar é isto
    https://github.com/emilybache/GildedRose-Refactoring-Kata
    Deixei o candidato usar a linguagem que preferisse, e foi um filtro muito eficaz

• Já entrevistei candidatos a desenvolvedor que pareciam saber muita teoria, mas fracassavam miseravelmente quando tinham que escrever código de fato. Não conseguiam nem implementar fizzbuzz, e um desenvolvedor Java sênior não conseguia importar HashMap sem pesquisar
  É parecido com matemática. Para 562 * 1041, o certo é usar uma calculadora, mas, se alguém pega a calculadora para saber quanto é 3 * 7, você passa a duvidar que seja especialista. Muitas empresas exageram nas entrevistas no estilo LeetCode, mas uma entrevista de live coding que mostre manipulação de arrays, controle de fluxo e uso de estruturas de dados básicas revela se a pessoa tem aquela memória muscular que só vem da experiência. Se for preciso estudar algoritmos de travessia de grafos para passar, provavelmente já está LeetCode demais

  • Ver se a pessoa decorou o nome do pacote de HashMap é o teste de programação Java mais idiota de que já ouvi falar
  • Não conseguir importar HashMap é, por si só, um critério ridículo. Um universitário que acabou de ver um exemplo de HashMap em Java talvez se lembre do import
    Mas um programa precisa de vários desses pequenos elementos e, nessa visão de mundo, seria preciso decorar todos. Em 562 * 1041, espera-se que a pessoa conheça o princípio do cálculo, ou seja, saiba como fazer. O cálculo em si pode sair errado, mas a ideia da multiplicação longa não deveria estar errada. Nesse contexto, não há problema em esquecer um item da tabuada como 3 * 7. Programadores são pessoas que organizam o cálculo, não que calculam diretamente; quem faz isso é o computador. Concordo que, para algoritmos de travessia de grafos, basta saber onde encontrar a solução, não é preciso ter todas as soluções na cabeça
  • O Eclipse faz o import para mim sem eu nem ver. O IntelliJ também
    Em que situação essas pessoas precisaram importar manualmente? Não havia IDE?
  • A pessoa que não sabe em qual namespace fica HashMap é equivalente a alguém que não sabe quanto é 3 * 7?
    Não sei bem se isso foi uma sátira aos estereótipos de entrevistadores