A experiência de ser rejeitado em uma entrevista com tarefa prática da Kagi Search

 (bloggeroo.dev)
4 pontos por GN⁺ 2025-05-16 | 1 comentários | Compartilhar no WhatsApp
  • Enfatiza a ineficiência dos take-home assignments pedidos em entrevistas para desenvolvedores de software e o problema do desperdício de tempo dos candidatos
  • No processo seletivo da Kagi Search, relata ter enfrentado exigências de tarefa excessivamente amplas e vagas
  • Ao compartilhar um plano de execução concreto, diz ter recebido falta de feedback claro do gerente e uma comunicação ineficiente
  • Após enviar um projeto desenvolvido com grande dedicação, sentiu injustiça ao ser rejeitado sem motivo claro e diante de mudanças nos critérios
  • Compartilha alternativas para um processo de contratação melhor (como revisão de código em tempo real) e critica exigências excessivas em entrevistas com tarefa prática

Introdução

  • Take-home assignment é um formato de avaliação em entrevistas para desenvolvedores de software no qual o candidato recebe um problema, implementa a solução em código e a entrega
  • Este post busca apontar a irracionalidade desse método e o desperdício de tempo dos candidatos com base na tarefa e na experiência real vivida ao se candidatar à Kagi Search, uma empresa que o autor considerava bem conceituada

Candidatura à Kagi Search

  • Enviou o currículo para uma vaga de desenvolvedor backend na Kagi Search
  • Os requisitos da função eram os seguintes
    • Experiência na construção de sistemas backend
    • Domínio da linguagem Go
    • Experiência em escalar e manter sistemas backend de grande porte
    • Capacidade de colaboração com integrantes da equipe, como SREs
    • Entendimento de tecnologias de contêiner, como Docker

Orientação da tarefa de entrevista e requisitos

  • Após passar pela triagem inicial, recebeu um e-mail com as instruções do take-home assignment
  • Tema da tarefa: "implementar um cliente de e-mail minimalista inspirado em terminal"
    • Podia escolher entre formato de terminal ou web app
    • Funções básicas de visualizar/enviar e-mails
    • Backend de e-mail falso ou real (IMAP/POP etc.) à escolha
    • Era obrigatório apenas tratar mensagens em plaintext; rich text não era necessário
    • Entrega do projeto: repositório no GitHub, versão implantada e documentação de instalação
  • Havia falta de orientação clara e a escala do projeto era considerável
  • Ainda assim, decidiu fazer a tarefa por causa da reputação da empresa

Comunicação com o gerente

  • Ao perguntar sobre o escopo claro da tarefa e recursos adicionais, recebeu apenas a resposta vaga de que "ficava a critério do candidato decidir o que acrescentar"
  • Antes de investir tempo e esforço na tarefa, compartilhou um plano de execução concreto (proposal) e pediu retorno sobre ele, mas o processo seguiu sem feedback relevante

Proposta e plano da tarefa

  • Plano de execução:
    • Web app baseado em Go
    • Deploy com AWS ECS Fargate e aplicação de SSL
    • Integração com serviço de envio de e-mails (Postmark)
    • Inclusão de login/autenticação
    • Envio e recebimento de e-mails com exibição na UI
  • Motivos da escolha tecnológica:
    • Uso de várias tecnologias relacionadas ao papel de backend
    • Construção de um sistema real com uso de ferramentas de Infra-as-Code
    • Implementação de funções mais próximas de um serviço real, indo além de uma simples integração de API
  • Principais elementos implementados:
    • Pocketbase (backend/DB), TEMPL (template), Pulumi (IaC), Postmark (serviço de e-mail)
    • Implementação de paginação, login etc.
    • Stretch Goal: estabilidade, como backup e recuperação de dados
  • Conclusão: havia apresentado previamente explicações e justificativas suficientes, e esperava uma análise clara e uma resposta objetiva sobre isso

Resposta do gerente e problemas de comunicação

  • Recebeu apenas uma resposta curta dizendo que era uma "proposta interessante", sem análise concreta
  • Não houve qualquer feedback sobre a adequação da proposta ou pedidos de melhoria
  • Do ponto de vista do candidato, isso pareceu falta de respeito com o tempo investido e o esforço dedicado

Execução do projeto da tarefa

  • Implementou tudo o que havia sido pedido e proposto e dedicou uma semana inteira em tempo integral
  • Também enviou vídeo de demonstração do projeto, repositório no GitHub e documentação detalhada

Notificação de rejeição e feedback recebido

  • Depois de receber um e-mail automático de rejeição, pediu feedback e recebeu a seguinte resposta:
    • "Houve entregas de candidatos mais fortes" e "a concorrência na contratação é acirrada"
  • Problemas apontados
    1. Se havia preferência por uma solução mais simples, isso poderia ter sido informado desde o início
    2. Se a proposta era insuficiente, seria possível dar feedback naquele momento
    3. Mesmo após a rejeição, a vaga continuava publicada, o que levou à conclusão de que não era apenas competição, mas uma exigência de consumo excessivo de tempo
    4. Após a entrega do projeto, os requisitos ficaram ainda mais rígidos, de modo que a solução enviada acabou elevando o próprio padrão de avaliação

Conclusão e problematização

  • Esse tipo de processo é injusto para muitos candidatos e pode até trazer impacto real ao sustento de quem busca emprego
  • Reforça a necessidade de recusar ou questionar exigências excessivas de tarefas não remuneradas
  • Defende que há processos de contratação melhores, como revisão de código em tempo real, para substituir tarefas em formato de projeto
    • A capacidade real de resolver problemas de desenvolvimento pode ser observada por meio de revisões de código síncronas ou assíncronas
    • Aponta a distância entre problemas no estilo Leetcode e as exigências do trabalho real
  • Faz um apelo por mudanças na cultura de esgotamento de candidatos e avaliações injustas

Sugestões para um processo seletivo melhor

  • Apresenta alternativas, como revisão de código em tempo real, para avaliar a capacidade do desenvolvedor de forma mais significativa
  • Defende a necessidade de mudar de processos centrados em resolver quebra-cabeças algorítmicos com timer para avaliações focadas em competência real e capacidade de resolver problemas

Leituras relacionadas

1 comentários

 
GN⁺ 2025-05-16
Opinião do Hacker News
  • Opinião honesta do ponto de vista de quem contrata. Pessoalmente, odeio tarefa take-home. Esse tipo de tarefa faz todo mundo perder tempo. Se for a etapa final da contratação, até dá para entender, mas usar isso para filtrar candidatos é ineficiente.
    1. Chegaram perguntas demais. Resolver usando julgamento em meio à ambiguidade também faz parte da tarefa. Pelas condições dadas, investir um ou dois dias e fazer algo no nível de um projeto local simples já teria sido suficiente.
    2. A elaboração e o compartilhamento da proposta foram excessivos. O candidato provavelmente quis mostrar capricho, mas na prática a empresa pode considerar isso ineficiente e perda de tempo.
    3. O resultado final era funcional, mas houve esforço demais em infraestrutura e acabamento. Com a reprovação, isso acabou virando perda de tempo.
    4. Parece que havia uma exigência de ser um cliente de e-mail inspirado em terminal, mas não consegui ver essa direção no resultado.
      Reconheço a capacidade e a paixão do candidato pelo trabalho. Só quis oferecer uma visão um pouco diferente.
    • A postura do autor do blog me incomoda um pouco. Só pelo texto já passa a impressão de alguém com quem seria difícil trabalhar, que teria dificuldade para tomar decisões com autonomia e precisaria de diretrizes muito claras. Serve para empresa grande, mas não combina com startup.
      "Desenvolver um cliente de e-mail inspirado em terminal para fazer alpha test com clientes" é um pedido razoável para um engenheiro de startup em estágio inicial. Mesmo que haja mais especificações, muita coisa depende do julgamento do engenheiro. O candidato parece querer certeza demais.
      Ficar curioso com antecedência sobre que tipo de feedback a Kagi daria após a conclusão da tarefa não é um bom sinal. Não era uma situação em que eles poderiam dar uma resposta definitiva. Provavelmente estavam avaliando centenas ou milhares de candidaturas.
    • O autor fez um bom trabalho, mas falhou implicitamente na condição de "não se esforçar demais".
      Se não era necessário esclarecer requisitos, então seria como mandar alguém "adivinhar um número de 1 a 10" para eliminar quem escolheu errado.
      Não concordo com eliminar alguém por ter se esforçado na tarefa e dado um bom acabamento.
      Essas tarefas ambíguas, na prática, são só mais uma forma de filtrar por "fit cultural".
    • Na minha opinião, a abordagem do candidato de validar suas ideias se parece com a forma moderna de fazer engenharia. Uma equipe saudável explica a especificação funcional em inglês, obtém aprovação e então segue em frente.
      A cultura de "código primeiro, feedback depois" foi a experiência mais nociva da minha carreira. Este candidato seguiu práticas modernas de software. (Sou responsável por contratação em uma empresa com mais de 1.000 engenheiros.)
    • Como contratante, gosto de tarefas take-home que possam ser concluídas em 30 minutos, tenham critérios de avaliação claros e incluam diferentes abordagens e trade-offs a considerar.
      Na minha última busca de emprego, também fui reprovado numa tarefa take-home muito ampla sem saber que parte era o critério de avaliação. Depois dessa experiência, passei a ter forte aversão a esse tipo de tarefa.
    • Acho que o motivo da reprovação foi a proposta ter ficado grande demais. As instruções não pediam uma proposta, e enviar algo tão detalhado pode até ser interpretado como "falta de autonomia para tocar as coisas". A partir daí, a qualidade do código deixa de importar.
      A empresa não deveria deixar a pessoa perder tempo; seria melhor encerrar a tarefa naquele ponto.
    • É lamentável que hoje em dia a indústria, em vez de avaliar a capacidade de entender requisitos, acabe filtrando desenvolvedores por habilidades de ler mentes.
    • O fato de o candidato não ter cumprido o prazo também é um problema. Atrasar sem explicar uma circunstância especial já é motivo de reprovação. O objetivo da tarefa era desenhar uma solução adequada dentro do prazo.
    • Sobre a menção ao terminal no item 4, na versão completa compartilhada pelo autor há explicação dessa parte.
    • Esse tipo de discussão sempre fica fácil olhando o resultado depois. Uma estratégia oposta (não confirmar requisitos, cumprir só o mínimo) poderia ter levado ao mesmo resultado. Em situações assim, sempre dá para dizer, no sentido contrário, que "faltou esclarecer melhor os requisitos de forma mais proativa".
  • Ao ver o código e depois o vídeo de demonstração, minha impressão foi: então levou bastante tempo durante uma semana para fazer um web app de duas páginas.
    Nem as funcionalidades mais básicas de e-mail (como abrir mensagens) existem, e apesar de a vaga ser para engenheiro de backend, na prática foram usados produtos externos como postmark e turso, além de faltar funcionalidades básicas (formatação em texto simples, visualização, pastas etc.).
    Havia recursos acessórios como painel administrativo e login, mas faltavam até estruturas mínimas de dados, como um mapa de cabeçalhos de e-mail.
    Pode até ser um bom engenheiro, mas julgo que não é adequado para essa posição.
    A proposta take-home também me pareceu estranhamente fora do comum.
    Relendo o anúncio original, estava explícito "cliente de e-mail mínimo inspirado em terminal" e referências como aerc, mutt, himalaya. Isso é claramente uma falha de interpretação dos requisitos.
    • Quando você diz "falha de interpretação dos requisitos", fico me perguntando quais requisitos exatamente não foram atendidos.
      Foi pedido um cliente de e-mail em terminal ou web app com funcionalidades básicas, e eu acho que isso foi atendido.
      A parte de se inspirar em ferramentas baseadas em terminal é subjetiva. Se for uma posição de backend, também acho que gastar energia demais com UI pode ser ineficiente.
    • É duro investir tempo e receber só um e-mail de rejeição.
      Se ao menos fosse possível receber feedback, isso ajudaria no crescimento, mas muitas vezes nem isso é realisticamente viável.
      Por isso fico cético com tarefas take-home. Tanto candidatos quanto contratantes precisam respeitar o tempo uns dos outros.
    • Existe a frase: "Email client can either be in the terminal (i.e. a TUI) or a web app".
  • Avaliação take-home pode ser útil, mas precisa obrigatoriamente ter limite de tempo.
    Com 2 a 3 horas já dá para avaliar bem um candidato. Se houvesse limite de tempo, o candidato também poderia apresentar uma solução apropriada dentro dele, e o que a empresa queria teria ficado mais claro.
    Além disso, a empresa precisa informar claramente se "qualquer resposta está OK" ou se "espera a melhor resposta possível".
    A intenção do take-home pode variar: passar no teste, taxa de cumprimento da missão, qualidade do código etc., e isso pode confundir o candidato.
    • Do ponto de vista de quem recruta, acho que a tarefa da Kagi é ampla demais e desrespeitosa com o tempo do candidato.
      Na verdade, há o risco de filtrar justamente pessoas ocupadas e sem tempo.
      Na nossa empresa, damos apenas um problema simples de ETL e colocamos limite de 4 horas.
      Também deixamos claro que tudo bem não terminar, e no follow-up fazemos code review e reservamos tempo para perguntas.
      A capacidade real dá para entender nessa reunião posterior.
    • Os candidatos podem investir muito mais tempo do que o tempo real previsto, então fico me perguntando como a pessoa recrutadora pode saber disso.
      Diferentemente de uma tarefa presencial, em que há uma unidade de tempo justa para todos, no take-home as diferenças no tempo dedicado podem acabar prejudicando alguém.
      Nesse caso, é melhor uma sessão presencial de código de 1 hora. Quando candidato e entrevistador investem o mesmo tempo, ambos respeitam melhor o valor do tempo do outro.
    • Acho revisão ao vivo muito melhor do que live coding. Se for para fazer live coding, prefiro o formato em que eu trabalho 45 minutos sozinho no meu laptop e depois volto para revisar.
  • É verdade que a resposta da empresa foi pouco cordial e pouco útil, mas os requisitos diziam claramente "inspirado em terminal".
    No vídeo de demonstração só aparece um web app comum. Foi explicitamente pedido que a solução se inspirasse em clientes de e-mail de terminal já existentes, como aerc, mutt e himalaya.
    Fico curioso se deixei escapar alguma coisa.
    • Teria sido melhor se o e-mail de rejeição explicasse claramente o motivo, mas a própria formulação da tarefa já pedia diretamente referências a clientes de terminal.
      Como a UX específica de clientes de terminal ainda é uma área sem uma "resposta certa", é bem possível que justamente isso tenha sido usado como critério de avaliação.
    • Considerando que o foco era em Go, é estranho ter mergulhado no desenvolvimento de uma GUI web quando dá para fazer um CLI em menos de 20 linhas.
    • Existe a instrução: "Email client can either be in the terminal (i.e. a TUI) or a web app".
  • Recentemente tive uma experiência parecida em uma entrevista. Entreguei muito bem um projeto de tarefa, mas recebi a reprovação direto sem nenhuma conversa sobre o projeto.
    Acredito que, se a empresa pediu uma tarefa, deveria obrigatoriamente haver uma reunião de follow-up.
    Eu já era assinante pago da Kagi, mas por causa disso estou pensando em encerrar minha conta.
    Se não há nem tempo para conversar com o candidato, então a empresa nem deveria pedir a tarefa.
    • Tarefas take-home exigem esforço considerável não só do candidato, mas também do entrevistador que vai avaliá-las.
      Depois de revisar tudo, acho que a pessoa tem direito a receber feedback.
      Mas, na prática, quando se escolhe apenas uma pessoa entre dezenas de candidatos excelentes, ser reprovado não significa necessariamente "falta de capacidade".
      Também existe a realidade jurídica de que uma resposta oficial para "por que vocês contrataram A e recusaram B?" muitas vezes acaba virando apenas procura por defeitos.
    • Teria sido melhor se a empresa tivesse divulgado critérios claros de avaliação ou dado feedback. Perder tempo sem retorno sobre a falha é algo que considero inaceitável.
      Muitas empresas lidam bem com isso.
    • Fico em dúvida se realmente era uma "solução excelente". Parece que a exigência de um cliente de e-mail mínimo inspirado em terminal e as referências relacionadas foram completamente ignoradas.
      Quando o mal-entendido dos requisitos é grande, a discussão em si pode acabar sendo pulada.
  • Este caso é um exemplo típico de leitura equivocada da intenção implícita no enunciado da tarefa.
    A empresa queria alguém autônomo e capaz de definir objetivos por conta própria.
    A ambiguidade existia para ver a capacidade do candidato de explorar a resposta por vários ângulos e resolver o problema.
    • A tarefa era para encontrar alguém capaz de produzir uma solução o mais simples, esperta e funcional possível.
      Como nem todo mundo se encaixa no perfil de uma empresa voltada a protótipos, algum candidato talvez tenha pensado 10 minutos e produzido o máximo possível em 60 minutos.
    • Quando se trata de um projeto de P&D e só se enfatiza "minimizar", fica ambíguo se era protótipo, algo voltado a usuários, se UX importava etc., e vira apenas um jogo de adivinhar o que a pessoa avaliadora valoriza.
    • Em tarefas desse tipo, de "interprete por conta própria", alguém pode ser reprovado justamente por não ter pedido esclarecimentos ou feito perguntas adicionais.
      Mas essa capacidade de perguntar é uma qualidade muito importante em desenvolvedores. Por isso não dá para evitar ter mais expectativas e mais decepção com esse tipo de contratação.
    • Acho que "misreading the subtext" na verdade estava no próprio enunciado.
    • No contexto educacional, culpar apenas o aluno por "não ter entendido" é uma conclusão cômoda demais.
      Na verdade, o problema é a explicação ambígua.
      Um grande professor faz o maior número possível de pessoas entender. Se há muitos alunos confusos, o problema é de quem elaborou a questão.
      Universitários não deveriam ter de resolver koans como monges Zen.
  • Como o autor publicou o texto pessoalmente, quero explicar o contexto com base na minha experiência trabalhando na Kagi.
    Antes, o próprio Vlad avaliava os candidatos, e as tarefas eram desse tipo.
    Com o crescimento da empresa, parece que agora outras pessoas fazem essa avaliação.
    Vlad tem uma inclinação ao estilo HN e quer trabalhar com candidatos que ele considere "legais".
    Por exemplo, se alguém escreve um documento de design longo dizendo "vou usar Galactor e o projeto está flop-ready", isso causa exatamente o efeito contrário.
    Na exigência de ser "inspirado em terminal", existe a tendência de esperar detalhes reais de apps de terminal, como todos os atalhos de teclado e afins.
    Dá para discutir se esse critério é um bom filtro, mas, se alguém entende esse contexto e tem capacidade de passar por ele, a tarefa vai parecer fácil.
    Gostaria que a Kagi comunicasse melhor esse contexto. É uma pena o tempo perdido, mas espero que você encontre uma empresa mais alinhada ao seu perfil.
    • Muitas empresas procuram pessoas que pensam como elas mesmas.
      Uma equipe sem diversidade pode acabar batendo toda hora na mesma parede e estagnando.
      Acho que isso é especialmente comum em startups e se relaciona também com o motivo de 9 em cada 10 fracassarem.
    • O problema, para mim, é que o Vlad faz gente demais perder tempo para encontrar "pessoas legais".
      Acho injusto aplicar uma tarefa avaliada sem critérios claros.
      No fim, não deixa de ser uma tarefa implícita de adivinhar "a resposta que eu tenho na cabeça".
      Isso passa a impressão de pouca consideração pelas pessoas.
    • Fica a dúvida: "Eu realmente deveria saber disso com antecedência?"
      Numa cultura assim, não sei se todo mundo teria de investigar como agente infiltrado para descobrir.
      Seria melhor se candidatos "não legais" como eu também recebessem um sinal claro e pudessem rapidamente procurar outras empresas.
  • Depois de revisar o código diretamente, encontrei já no primeiro arquivo comentários que pareciam cópia de código de exemplo sem propósito, explicações inconsistentes e expressões que passam falta de atenção aos detalhes.
    Por falhas desse tipo, eu pararia a revisão.
    • Eu implantei o app no meu domínio e não houve problema de desempenho. Também implementei bem autenticação e infraestrutura, aspectos típicos de backend. Mas não concordo com a crítica de que eu deveria ter dado mais atenção aos comentários do código.
    • O ponto central neste caso não é a reprovação em si, mas o fato de um processo seletivo sem orientação clara e sem sequer fornecer feedback ter sido totalmente desrespeitoso com o tempo do candidato.
  • Também tive uma experiência parecida no DuckDuckGo, mas recebi uma pequena compensação em todas as etapas da candidatura.
    Desde uma proposta simples de design até a tarefa de implementação, tudo foi conduzido com limite de tempo claro.
    No fim, eu não fui aprovado e não me disseram o motivo exato.
    Parece que havia candidatos demais, mas essa experiência me marcou emocionalmente por muito tempo. Entendo como o OP se sente.
  • Falando como entrevistador de engenharia: tanto leetcode quanto take-home consomem muito tempo e entregam pouca informação.
    Ainda assim, se eu fosse o responsável pela contratação, acho que também reprovaria o autor.
    Startups querem pessoas que trabalhem rápido e de forma pragmática.
    Já tive colegas que passavam dias mergulhados sozinhos depois de coletar opiniões ao redor, mas nesse meio-tempo os requisitos já tinham mudado, e isso não fez bem para ninguém.