A experiência de um desenvolvedor rejeitado em uma entrevista com tarefa da Kagi Search
(bloggeroo.dev)- No processo seletivo de backend da Kagi Search, um desenvolvedor implementou um cliente de e-mail com aparência de terminal trabalhando em tempo integral por cerca de uma semana, mas foi rejeitado após a entrega sem sequer passar por uma entrevista de acompanhamento
- A tarefa era aberta em vários aspectos, como TUI ou aplicativo web, consulta e envio básicos de e-mail, backend falso ou escolha entre IMAP/POP/JMAP, então o candidato precisava decidir por conta própria o escopo da implementação e os critérios de avaliação
- O candidato enviou antecipadamente um plano detalhado incluindo aplicativo web em Go, AWS ECS Fargate, SSL, Postmark, login, Pulumi, Pocketbase, TEMPL e mais, mas a Kagi não informou critérios concretos de aprovação
- Ao pedir feedback após a rejeição, recebeu apenas a resposta de que havia “entregas mais simples e mais fortes”, junto com a informação de que normalmente não fornecem feedback individual nessa etapa
- Essa experiência mostra como entrevistas com tarefas não remuneradas e quebra-cabeças de programação com tempo limitado podem testar mais o tempo disponível e as condições de vida do candidato do que sua real capacidade de engenharia
Candidatura e recebimento da tarefa
- O candidato enviou seu currículo para uma vaga de backend na Kagi Search, e o resumo da função incluía as seguintes competências
- experiência na construção de sistemas backend
- proficiência em Go
- compreensão de escalabilidade e manutenção de sistemas backend
- capacidade de colaborar com SREs e colegas de equipe
- entendimento de tecnologias de conteinerização como Docker
- Depois disso, recebeu da Kagi um e-mail pedindo que concluísse a próxima etapa, o Kagi Developer Assessment
- a URL da tarefa foi enviada via HackMD
- o e-mail dizia que, após a conclusão, bastava entrar em contato para que eles analisassem o material e, em caso de aprovação, discutissem a abordagem e a solução em uma entrevista posterior
Requisitos da tarefa e critérios de avaliação abertos
- O objetivo da tarefa era criar “um cliente de e-mail minimalista com sensação de terminal”
- As condições de implementação eram relativamente abertas
- o cliente de e-mail podia ser implementado como TUI de terminal ou aplicativo web
- era necessário ter funcionalidades básicas de leitura e envio de e-mail
- podia usar um backend falso (DB, memória etc.) ou um backend real com IMAP/POP/JMAP
- mensagens em rich text estavam fora do escopo, então bastava lidar com texto simples
- Foi informado que a avaliação não envolveria apenas habilidade de programação, mas também a capacidade de lidar com ambiguidade e problemas abertos necessária em projetos de P&D como os da Kagi Labs
- As entregas exigidas eram as seguintes
- implementar de uma forma que mostrasse as habilidades do candidato como desenvolvedor
- publicar o projeto concluído em um repositório no GitHub e fazer o deploy em algum lugar para facilitar os testes
- escrever no README como realizar a configuração
Comunicação com o recrutador
- O candidato considerou os requisitos amplos demais e enviou perguntas ao recrutador
- O recrutador respondeu que havia muitos candidatos e que alguns implementavam apenas o básico, enquanto outros entregavam recursos extras, documentação excelente, explicação das decisões tomadas, demo publicada e até planos futuros
- Quando perguntou quais recursos extras eram mais valorizados, o recrutador respondeu que “isso em si faz parte da avaliação” e que queriam ver quais extras o próprio candidato conseguiria imaginar
- Antes de começar a programar de fato, o candidato decidiu escrever e enviar um plano detalhado de implementação de toda a entrega
- ele esperava que, se a proposta fosse bem recebida, isso o aproximaria de uma entrevista por telefone ou de uma oferta
- depois de ver o resultado, concluiu que o esforço para alinhar as condições antecipadamente não teve grande importância para o recrutador
Implementação proposta pelo candidato
- O centro da proposta era um cliente de e-mail baseado em aplicativo web em Go
- deploy na AWS
- uso de ECS Fargate
- aplicação de SSL/HTTPS
- integração com um provedor de envio de e-mail
- autenticação por meio de tela de login
- envio de e-mail baseado em formulário
- exibição de e-mails recebidos na interface
- Na proposta, ele indicou a data de entrega como domingo, 30 de março, no fim do dia, ou seja, dois dias úteis além de duas semanas após o e-mail inicial
- As escolhas técnicas foram as seguintes
- backend em Go: uso de Pocketbase e TEMPL
- infraestrutura como código: uso de Pulumi com o SDK de TypeScript
- provedor de serviço de e-mail: uso de Postmark
- UI: paginação de e-mails enviados e recebidos, tela de login e 2 contas de demonstração
- Os motivos das escolhas estavam mais ligados a mostrar um escopo amplo em relação à função e à avaliação
- embora fosse uma vaga de backend, adicionar frontend web poderia mostrar amplitude nas tecnologias web
- banco de dados era relevante para uma função backend
- deploy na AWS e infraestrutura como código se conectavam a discussões sobre IaC, Docker, rede e resiliência
- um serviço de e-mail como o Postmark reduzia a complexidade da integração com IMAP/POP sem abrir mão da funcionalidade
- O candidato perguntou “que tipo de reação eu poderia esperar da Kagi se eu concluir isso”, mas a resposta ficou em algo como “parece muito interessante e estamos ansiosos pela entrega”
Entrega e rejeição
- O candidato afirmou que implementou tudo o que havia proposto e que todo o trabalho consumiu uma semana em tempo integral
- A demonstração do aplicativo web foi publicada no YouTube, e o código foi disponibilizado no GitHub com documentação
- Depois de receber um e-mail automático de rejeição, pediu feedback, e a Kagi respondeu o seguinte
- normalmente não fornecem feedback nessa etapa
- havia entregas mais simples e mais fortes, então decidiram continuar com esses candidatos
- há muito interesse e muitas candidaturas para cada posição, tornando a seleção muito competitiva
- pediram que ele continue acompanhando vagas futuras e se candidate novamente
Dúvidas que ficaram após a rejeição
- O candidato entende que, se queriam uma “solução mais simples”, isso poderia ter sido dito quando ele enviou a proposta em 18 de março
- Se a solução não era adequada para a vaga, ele acredita que isso também poderia ter sido avaliado já na etapa da proposta de 18 de março
- Ele escreveu que, em 13 de maio, já fazia um mês e meio desde a rejeição e a vaga ainda continuava publicada
- reconhece que a empresa pode preencher várias funções com o mesmo anúncio
- mas não considera que a situação parecesse uma “competição por uma única vaga já preenchida pelo vencedor”
- As instruções originais da tarefa diziam que ter uma demo publicada seria desejável, mas não obrigatório; segundo ele, depois da entrega as instruções foram alteradas e o deploy passou a ser um requisito mais rígido
Proposta de métodos melhores de seleção
- O candidato critica tarefas não remuneradas por serem um grande peso para quem procura emprego, especialmente para pessoas desempregadas vendo suas economias diminuírem
- Ele também tem uma visão negativa de entrevistas no estilo LeetCode
- escreveu que, recentemente, em uma vaga baseada em Clojure, resolveu um problema de “coin change” e conseguiu passar em cerca de metade dos testes em 50 minutos, mas não teve tempo de implementar a parte de backtracking
- Como alternativa, propõe revisão de código ao vivo
- considera viável tanto de forma assíncrona quanto síncrona
- seria possível discutir verbalmente problemas e temas de projetos reais de software
- isso poderia revelar melhor o conhecimento de engenheiros de software experientes
- Ele não se opõe totalmente a live coding, mas considera que a habilidade de resolver knapsack em 50 minutos está distante do trabalho cotidiano de engenharia
- A menos que a situação seja desesperadora, recomenda recusar vagas que exijam esse tipo de trabalho não remunerado
1 comentários
Opiniões no Hacker News
Do ponto de vista de quem contrata, eu não gosto de processos com tarefa prática por estes motivos. Eles desperdiçam o tempo de todos e, embora possam ser aceitáveis como última etapa antes da contratação, são inadequados como filtro
Ainda assim, a competência e a sinceridade parecem claras; estou apenas fazendo o papel de advogado do diabo a partir de outra perspectiva
“Crie um cliente de e-mail com estilo de terminal que possa ser testado em alfa com alguns clientes” é um pedido razoável para um engenheiro em uma startup em estágio inicial, e os detalhes inevitavelmente ficam a cargo do engenheiro
Em especial, a solicitação “gostaria de saber que reação posso esperar da Kagi se eu levar isso até a conclusão” foi ruim. Quando é preciso analisar centenas ou milhares de submissões, não há como dar uma resposta garantida
Se tentar esclarecer os requisitos é um comportamento indesejado, isso não é muito diferente de pedir para a pessoa escolher um número de 1 a 10 e reprovar quem escolher errado
Testes práticos servem para demonstrar capacidade, mas, sem orientação específica, como adivinhar até que ponto é preciso demonstrá-la?
O polimento só é ruim quando impede a entrega; reprovar alguém por “ter refinado demais” parece reprovar porque a pessoa fez o trabalho bem demais
Esse tipo de teste ambíguo acaba parecendo mais uma forma de filtrar pessoas sob o pretexto de não haver adequação cultural
Ambientes de “faça primeiro e revise depois” foram os mais tóxicos da minha carreira, e é péssimo passar dias criando uma funcionalidade para depois descobrir que ela não era desejada
Por isso, descrever uma funcionalidade por escrito e obter aprovação é algo próximo do padrão da indústria para lançar projetos, e este candidato seguiu práticas de software adotadas por organizações saudáveis
É assim que vejo também como gerente de contratação em uma empresa com mais de mil engenheiros
Claro, elas só deveriam ser dadas a candidatos para quem o resultado realmente possa decidir a aprovação
Na minha última busca por emprego, recebi uma tarefa ampla desse tipo e, embora fosse para uma vaga para a qual eu era qualificado demais, fui reprovado porque não consegui adivinhar quais partes seriam avaliadas
Parece improvável que eu consiga emprego no futuro por um caminho que não seja indicação, mas passei a ter forte aversão tanto a receber quanto a aplicar esse tipo de tarefa
A tarefa avaliava a capacidade de fazer algumas perguntas, registrar pressupostos e mergulhar com confiança em algo ambíguo para construir
Provavelmente, depois daquele e-mail, o código já nem importava mais; a empresa deveria ter encerrado ali para que o candidato não desperdiçasse tempo implementando a tarefa
Ao ver o código e o vídeo de demonstração, meu primeiro pensamento foi: “Levou uma semana para criar um web app de duas páginas, e ainda faltam as funções mais básicas de e-mail, como abrir mensagens”
Olhando os requisitos, essa pessoa se candidatou a “Email Backend Engineer”, mas usou produtos de terceiros como Postmark e Turso para o backend de e-mail real
Faltavam elementos básicos como formato de e-mail em texto puro, visualização, pastas e, no mínimo, caixa de entrada e enviados; já recursos opcionais como tela de login, página de administração e framework de backend estavam presentes
O banco de dados do backend nem sequer tinha um mapa de cabeçalhos de e-mail
Pode ser um ótimo engenheiro, mas não parece adequado para esta vaga específica, e eu também teria recusado
Ao olhar o anúncio original, o título era “The project is to build a minimal, terminal-inspired email client”, e ele dizia explicitamente para se inspirar em ferramentas de e-mail de terminal existentes, como aerc, mutt e himalaya
Isso parece um caso de não ter lido os requisitos corretamente, então eu veria como não contratável
Parece que ambos foram atendidos de forma suficiente
Inspirar-se em ferramentas existentes é algo subjetivo, e, em uma tarefa para uma vaga de backend, talvez a pessoa não tenha considerado que gastar tempo na interface de usuário fosse a melhor forma de demonstrar competência
Entendo que, em vagas populares, quando recrutadores precisam avaliar centenas de pessoas, isso nem sempre é realista, mas é justamente por isso que processos com tarefa prática são ruins
O candidato pode desperdiçar horas da vida sem obter nada em troca, então os dois lados deveriam respeitar o tempo um do outro
Entendo que a resposta tenha sido muito curta e pouco útil, mas os requisitos diziam claramente para criar um cliente de e-mail inspirado em terminal.
Pelo vídeo compartilhado https://www.youtube.com/watch?v=yY1sVXMkP_o, parece um app web de e-mail comum, sem nada particularmente inspirado em terminal.
Se a ideia era aceitar tanto uma TUI real quanto um app web, é bem provável que o app web também tivesse de ter um visual/estilo de terminal.
Na seção “Inspiration” dos requisitos completos, está explícito que a inspiração deveria vir de “ferramentas de e-mail de terminal existentes, como aerc, mutt e himalaya”.
Ainda assim, o prompt mencionava outros clientes de terminal como inspiração.
Além disso, o requisito de ser um cliente de terminal muda bastante o que está sendo avaliado. UI web de e-mail é um domínio conhecido há muito tempo, mas a experiência de usuário de clientes de terminal ainda não é uma área completamente “resolvida”.
É bem possível que a rubrica de avaliação desse um peso grande a decisões de design de clientes de terminal que a submissão do candidato não abordou de forma alguma.
Avaliações por desafio podem ter valor em um processo seletivo, mas precisam necessariamente de um limite de tempo. Em 2 ou 3 horas já dá para obter as informações necessárias; mais do que isso começa a parecer uma forma de filtrar apenas juniores sem dependentes, hobbies ou responsabilidades.
Se o limite fosse de 3 horas, no pior caso o candidato teria perdido só 3 horas e, no cenário mais provável, teria apresentado uma proposta ou solução completamente diferente, adequada a esse tempo.
O candidato também precisa confirmar se querem “qualquer resposta” ou uma boa resposta.
Alguns desafios só verificam se um conjunto de testes passa e não se importam com a abordagem; outros preferem um código melhor mesmo que só cubra 80% dos requisitos. Já vi candidatos errarem a leitura em ambos os casos.
Esse tipo de desafio tende a filtrar pessoas que conseguem desperdiçar muito tempo no projeto e a deixar passar justamente pessoas ocupadas — ou seja, as que você provavelmente gostaria de contratar.
Ao contratar para competências de engenharia de dados, aplico um desafio simples de ETL. Peço para extrair dados de um arquivo ZIP, transformá-los e inseri-los em qualquer banco de dados.
Deixo algumas partes ambíguas e coloco elementos escondidos no dataset, como valores null inesperados ou CSV mal formatado, para avaliar a execução.
Limito a 4 horas, mas não dava orientação sobre o que fazer se o tempo não fosse suficiente; essa é uma boa sugestão.
Depois, em uma chamada, analisamos o código juntos e faço perguntas como “e se o dataset não couber inteiro na memória?”, pedindo ideias de melhoria; é aí que acontece a avaliação técnica de fato.
Como não há garantia de que todos os candidatos tenham usado o mesmo tempo, isso vira um problema de teoria dos jogos, e o candidato geralmente sai prejudicado de algum jeito.
Em muitos casos, a resposta correta é gastar mais tempo para criar uma solução muito polida — mas não polida demais — e fingir que respeitou o limite.
Mesmo 3 horas é muito tempo para um candidato que talvez nem saiba se vai conversar com a próxima pessoa.
Em uma entrevista de 1 hora, dá para conduzir um exercício de programação e garantir que o candidato não desperdice tempo extra.
Se o candidato quiser, pode enviar uma versão melhorada depois; normalmente, nesse ponto, eu já avaliei bem a competência dele e posso dizer “se quiser, faça, mas você já passou”.
Manter o investimento de tempo do candidato e do entrevistador equivalente faz com que eu respeite o tempo do candidato assim como respeito o meu.
Se um gestor de contratação não respeita o tempo dos candidatos, parece pouco provável que respeite o tempo dos funcionários.
Fiz entrevistas em vários lugares recentemente e a experiência foi muito parecida com esta. Apresentei uma ótima solução para o desafio, mas fui rejeitado sem nenhuma discussão sobre o resultado.
Como alguém que já conduziu processos com desafios para candidatos várias vezes, acredito que, se você pede para alguém fazer um projeto em casa, precisa obrigatoriamente conversar sobre o código.
Se receber um desafio desse tipo, recomendo fortemente confirmar se haverá uma conversa posterior independentemente do resultado da avaliação; se não concordarem, não faça a “lição de casa”.
Sinceramente, muitas equipes de contratação têm um nível baixo, então implementar uma boa solução pode acabar contando contra você. Dá para ser reprovado pelo motivo frustrante de a equipe de contratação não estar à altura daquele nível.
Eu era usuário inicial da Kagi, mas estou considerando cancelar minha conta por causa disso. Se não há tempo para conversar com o candidato, não deveriam pedir trabalho em primeiro lugar.
Desafios desse tipo exigem bastante esforço não só do candidato, mas também de quem os administra e da equipe de contratação; se o projeto foi revisado, é razoável esperar feedback ou uma resposta quando solicitado.
Mas também há a realidade. Se existem 20 ótimos candidatos para uma vaga, muitas pessoas competentes serão rejeitadas. Isso não significa que elas eram insuficientes ou que “falharam”.
Se, por motivos legais, for preciso explicar por que A foi escolhido e B não, fica difícil dizer “ambos eram excelentes, mas escolhemos um”; no fim, a tendência pode ser inventar defeitos que nem existiam.
Na cultura corporativa dos EUA, vi isso acontecer com frequência, e a Kagi é sediada em Palo Alto.
Ser reprovado no desafio é aceitável, mas desperdiçar o tempo de alguém sem devolver nada é difícil de aceitar.
Muitas empresas, inclusive startups populares, lidam bem com isso.
O resultado não se parecia muito com um “cliente de e-mail mínimo com estilo de terminal”, e parece ter ignorado completamente as ferramentas indicadas como inspiração.
Se os requisitos foram mal compreendidos de forma tão grande, eu também não gastaria tempo discutindo.
Este é um caso clássico de ler errado o contexto implícito. A empresa queria alguém capaz de criar de forma independente o próprio trabalho e os próprios objetivos.
A ambiguidade da tarefa não era para ficar investigando por vários e-mails, mas uma tela em branco para receber uma tarefa bem ampla, explorar por conta própria o espaço do problema e mostrar como produz um resultado.
É muito parecido com o que se vê na universidade quando um aluno que não entendeu a tarefa recebe uma nota inesperada e reclama.
Numa situação de entrevista em que a pessoa quer causar uma boa impressão, não é comum alguém ousar agir de forma “preguiçosa”.
Para uma empresa com uma abordagem centrada em lançar experimentos rápidos e protótipos, algumas pessoas simplesmente não se encaixam, e isso é ruim para todos.
Talvez algum candidato tenha passado 10 minutos pensando no que poderia fazer em 60 minutos, usado autenticação HTTP e um formulário, colocado para rodar com um pequeno backend em Go e enviado junto com um e-mail curto. É bem possível que essa pessoa tenha parecido muito melhor no processo.
Não dá para saber se é um protótipo descartável, algo que usuários reais vão ver, se a pessoa será criticada por uma experiência de usuário incompleta, ou se eles só querem ver alguma coisa.
No fim, vira um exercício de adivinhar o gosto do avaliador.
Por outro lado, também deve haver gente reprovada por não insistir o suficiente para esclarecer os requisitos, algo que é uma virtude importante em engenheiros.
A vida não é justa, mas eu espero mais de gerentes de contratação, e por isso continuo me decepcionando.
Talvez o aluno tenha entendido errado porque não sabe ler mentes e as instruções foram muito mal escritas.
Um bom professor é quem faz o máximo possível de alunos entenderem; um mau professor faz o oposto.
Com os melhores professores que tive, nunca precisei questionar a nota porque os critérios de avaliação eram transparentes desde o início.
Se muitos alunos estão confusos, o denominador comum pode ser o professor.
Só porque monges budistas aprendem resolvendo enigmas difíceis chamados koans, não quer dizer que a mesma abordagem deva ser aplicada a universitários que pagam mensalidade.
Como parece que o próprio autor postou isto, vou tentar explicar o contexto da reação que ele recebeu. Trabalhei na Kagi no passado e passei por um teste take-home parecido.
Na época, a empresa era muito pequena, Vlad analisava os candidatos pessoalmente e usava projetos desse tipo. Agora a empresa cresceu e talvez ele não veja tudo diretamente, mas o núcleo parece semelhante.
Conversando com Vlad, ele é praticamente o arquétipo de um comentarista do Hacker News, e a entrevista é mais uma checagem de vibe para ver se a pessoa “parece decente”.
Para ele, escrever um documento longo de design dizendo “vou usar Galactor, deixá-lo florp-ready e fazer fleem” é exatamente o oposto de parecer legal.
Se a tarefa é “um cliente de e-mail com cara de terminal”, um projeto quase nota máxima provavelmente seria algo em que todas as funcionalidades têm atalhos de teclado e que explica em um parágrafo que não leva mais de 2 ms para desenhar um frame.
O entrevistador provavelmente achou que o candidato tinha uma mentalidade enterprise demais para trabalhar na Kagi.
Claro, se esse método de seleção é bom ou não é outra questão. Vlad quer pessoas que pensem como ele, e há muitos problemas bastante discutidos e estudados nesse tipo de entrevista.
Mas, se você entende isso e tem espaço para aguentar esse tipo de processo, a tarefa de fato faz sentido. A Kagi poderia ter comunicado esse ponto melhor.
É uma pena que você tenha perdido tanto tempo, mas espero que encontre um lugar mais alinhado ao seu modo de trabalhar.
Para trazer novos insights para um problema, é preciso diversidade de pensamento. Se todo mundo pensa do mesmo jeito, quando uma pessoa trava, é provável que todas travem.
Isso parece um problema comum em startups, e talvez seja um sinal que explique por que 9 em cada 10 startups fracassam.
Isso é diferente de testar competência. Aqui, para passar, você precisa tirar uma nota alta em métricas que não foram informadas.
Não é muito diferente de dar uma tarefa dizendo “codifique qualquer coisa, porque você precisa lidar bem com ambiguidade”, quando na verdade a pessoa precisa adivinhar o que eu tinha em mente.
É uma forma muito pouco atenciosa de tratar as pessoas, e também não é um bom sinal sobre quem é Vlad.
Quer dizer que eu deveria vasculhar as redes sociais das pessoas da empresa para descobrir isso?
No fim, se eu já tinha deixado claro o bastante que não era “legal” e mesmo assim me disseram para “seguir em frente” só para satisfazer a curiosidade deles, espero que sejam tratados exatamente como tratam os outros.
Agradeço pela explicação e não tenho ressentimentos. Só gostaria de ter visto um texto assim antes.
Daqui para frente, seria bom classificar vagas com “take-home” como vagas para a galera legal. Assim, engenheiros chatos, mas experientes, podem pressionar as empresas a mudar o processo se elas realmente quiserem nosso trabalho.
Se a empresa não mudar, dá para inferir que tipo de empresa está “oferecendo” aquele cargo.
Dei uma olhada no código para ver como eu avaliaria se fosse o revisor.
Eu teria parado por aqui, no primeiro arquivo que abri: https://github.com/Sleepful/mymail/blob/main/app/router/page...
O primeiro comentário é muito estranho e não tem relação com o trabalho; parece copiado de um exemplo de blog. De qualquer forma, deixá-lo ali demonstra falta de cuidado.
A formulação da segunda linha não é consistente com a terceira linha.
Eu teria encerrado a revisão nesse ponto. É falta de atenção aos detalhes e não demonstra capacidade de pensar com clareza.
O que recebi em troca foi um e-mail de rejeição vazio.
Nessa situação, tenho dificuldade em concordar que eu deveria ter dedicado ainda mais tempo aos comentários do código.
Quero dizer isso como entrevistador de engenharia. Não gosto nem de LeetCode nem de tarefas para fazer em casa. Ambos consomem muito tempo e geram pouca informação
Ainda assim, neste caso, eu provavelmente teria rejeitado o autor. A Kagi Search é uma startup, e lugares assim geralmente procuram otimistas pragmáticos que consigam equilibrar profundidade e amplitude
Já tive um colega que, no passado, reuniu os inputs, ficou isolado por vários dias, saiu com uma solução pronta, e nesse meio-tempo os requisitos tinham mudado. Não foi uma experiência agradável para ninguém
Eu realmente detesto processos com tarefa para casa
A frase “este projeto testa não só programação, mas também a capacidade de lidar com ambiguidade e problemas em aberto” na prática soa como: a) a tarefa foi tão mal desenhada que nem criaram uma rubrica de avaliação, ou b) o ambiente de trabalho é tão caótico que nenhuma especificação ou requisito é definido com clareza
Além disso, as instruções “mostre suas habilidades técnicas” e “entregue uma solução prática e funcional” entram em conflito. Uma boa solução simples não é chamativa
Saber fazer requisições HTTP e criar uma tela básica de edição CRUD não diz quase nada. Ferramentas de IA também conseguem produzir isso rapidamente com qualidade bem razoável
O que quero ver é como o engenheiro implementa uma lógica de negócio esquisita
Quero ver se vira um milhão de
ifs aninhados e comentários do tipo “aqui há dragões”, ou se encontra padrões adequados e produz código legível e fácil de raciocinarIsso é muito mais valioso no trabalho real, dá um sinal mais forte na entrevista, é mais difícil para a IA acertar e toma menos tempo
Criar uma boa solução simples pode ser justamente uma forma de demonstrar competência
Vejo isso como uma grande parte do papel de um engenheiro de software sênior
Esse formato talvez não seja a melhor maneira de testar isso, mas “vamos ver se você consegue lidar com ambiguidade” não significa que tudo seja ambíguo
Pode significar que todo trabalho precisa passar pelo caminho de “requisitos ambíguos” para “especificação clara”