Dark Patterns em Entrevista Tech: 7 Armadilhas que Identifiquei em 12 Processos
Passei por 12 processos seletivos tech no primeiro semestre de 2026. Empresas nacionais, empresas gringas com escritório no Brasil, uma empresa remote-only que me pediu para trabalhar em UTC-8. Aceitei 1, rejeitei 4 durante o processo, fui rejeitado em 6, e no último a proposta foi tão baixa que eu ri em voz alta durante a call.
Ao longo do caminho, comecei a catalogar padrões. Não os “sinais de red flag” genéricos que já circulam há anos, tipo “eles perguntam demais sobre disponibilidade em fim de semana”. Padrões mais finos, mais educados na aparência, mais eficazes em pegar dev cansado que só quer terminar o processo e voltar pro código.
Eu chamo esses padrões de dark patterns, no mesmo sentido em que a gente usa a palavra para interfaces manipulativas. Não é a mesma coisa que uma vaga tóxica gritante. É o processo desenhado para explorar o candidato de forma que fica difícil de nomear em tempo real.
São 7 padrões, e vou passar por cada um com o que aconteceu comigo e o que eu faço hoje quando vejo o padrão de novo.

1. Teste técnico “curto” que exige 8h+ e não paga
Foi o mais frequente. 7 das 12 empresas pediram algum tipo de take-home. O tempo estimado no e-mail era invariavelmente “3 a 4 horas”. O tempo real, se você quer entregar algo que passe na review, ficava entre 8 e 15 horas.
O pior caso: uma fintech pediu um “sistema completo de contas com autenticação, transferências, extrato e testes”. Estimativa oficial: 4h. Estimativa real, medida por mim com pomodoro: 22h ao longo de um fim de semana inteiro. Depois disso, rejeição sem feedback.
A OCDE e o próprio Ministério do Trabalho brasileiro já discutem publicamente que trabalho técnico não remunerado pode configurar prestação de serviço, especialmente quando o output entregue tem valor comercial. Isso ainda não virou fiscalização em massa, mas o precedente jurídico existe.
Como identifico hoje: pergunto na primeira call quantas horas o take-home vai levar segundo ex-candidatos que passaram. Se a resposta for evasiva ou “depende da sua senioridade”, eu proponho um pair-programming ao vivo de 90 minutos como alternativa. Se recusam, tiro a candidatura.
2. “Match cultural” que só pergunta sobre disponibilidade
Ronda batizada de “conversa com o time” ou “cultural fit”. Cinco de cinco vezes que a etapa apareceu, as perguntas foram:
- “Como você reage a prazos apertados?”
- “Você tem problema em resolver bug crítico de madrugada?”
- “Como você prioriza quando o time está sobrecarregado?”
Zero perguntas sobre valores da empresa, sobre conflito de opinião com liderança, sobre limite entre trabalho e vida pessoal. É um radar de conformidade, não um cultural fit.
Como identifico hoje: reverso a dinâmica. “Me conta uma vez em que um dev do time discordou publicamente do CTO. O que aconteceu?” Se a resposta é um silêncio incômodo seguido de “aqui todo mundo se dá bem”, já sei o preço da concordância.
3. Rounds infinitos, escopo indefinido
“São 3 etapas” vira 5. “Falta só a última call” precede mais 2 semanas de agenda mexida. Um dos processos me consumiu 8 chamadas ao longo de 6 semanas antes da proposta. Somando take-home, calls e preparação, mais de 40 horas do meu tempo — grátis.
Isso não é acaso. É uma versão do que a pesquisa em psicologia comportamental chama de escalada de compromisso: quanto mais tempo você já investiu, maior a probabilidade de você aceitar uma proposta ruim no final, só para “não perder tudo”.
Como identifico hoje: no e-mail de agendamento da primeira call, peço à empresa para listar quantas etapas são, com nomes e durações estimadas. Depois pergunto se elas se comprometem por escrito com esse número. A maioria concorda. A minoria que se irrita já se autodenuncia.
4. Faixa salarial que só aparece na proposta final
Nove das doze empresas se recusaram a compartilhar a faixa antes da última etapa. Frases padrão:
- “Temos uma faixa competitiva.”
- “Vamos alinhar valores no final, quando você entender melhor o desafio.”
- “Depende muito do seu perfil, difícil dizer agora.”
O que isso esconde: a empresa quer que você invista tanto tempo no processo que você aceite qualquer coisa razoável no fim. E “razoável” nesse contexto significa, em média, 20 a 30% abaixo do mercado — porque a empresa sabe que você sabe.
Como identifico hoje: pergunto a faixa na primeira mensagem. Antes de aceitar a call inicial. Se recusam, respondo educadamente que preciso do range mínimo para não desperdiçar meu tempo nem o deles. Metade responde com um número honesto. A outra metade desiste, e é uma economia de 40 horas.
5. Urgência artificial (“precisamos fechar essa semana”)
Aconteceu 3 vezes. Sempre depois de eu ter concluído o processo. Sempre com a proposta abaixo do combinado no início. Sempre com um prazo de 24 a 48h para responder.
Isso é ancoragem + escassez em livro-texto. A pressão temporal desliga o Sistema 2, aquele que faz contas, e ativa o Sistema 1, aquele que só quer resolver o desconforto. Se você aceita nesse estado, você acorda na segunda-feira com o contrato assinado e uma sensação estranha no estômago.
Como identifico hoje: adoto uma regra pessoal. Não assino nenhum contrato de emprego em menos de 72 horas de análise. Se a empresa não aceita esse prazo, revela que o processo dela vale mais do que a decisão que ela quer que eu tome.
6. Feedback zero após rejeição (“obrigado pelo seu tempo”)
Dos 6 processos em que fui rejeitado, 5 me deram exatamente esta frase: “Você tem um perfil excelente, mas seguimos com outro candidato. Obrigado pelo seu tempo.” Nada de específico. Zero possibilidade de aprendizado.
Isso é dark pattern porque protege a empresa de acusações de discriminação (não há registro escrito de critério), extrai valor do candidato (40h de teste, dados sobre a stack interna, ideias arquiteturais discutidas), e devolve zero. Se a empresa realmente respeita seu tempo, ela devolve pelo menos o que ela aprendeu com você.
Como identifico hoje: respondo com uma pergunta específica. “Fico grato pelo processo. Para eu evoluir, qual foi o principal ponto que fez vocês seguirem com outro candidato — foi conhecimento técnico específico, senioridade percebida, fit com o time, ou orçamento?” Uma parte responde. A outra parte confirma o padrão.
7. Take-home que vira feature de produção
O padrão mais sutil e o mais indignante. Uma empresa me pediu para “prototipar um endpoint que faz X”. Três meses depois, um ex-colega meu que trabalha lá me mostrou o repositório. O código de produção que fazia X tinha comentários idênticos aos que eu tinha escrito no meu take-home.
Isso é apropriação de trabalho não pago. Existe um debate jurídico se cabe ação civil, mas na prática ninguém entra com ação porque o custo é alto e a prova é difícil. A defesa é anterior: não deixar acontecer.
Como identifico hoje: dois filtros. Primeiro, o take-home tem que resolver um problema abstrato, tipo “sistema de reserva de biblioteca”, nunca “endpoint que faz X para nosso produto Y”. Segundo, incluo no repositório uma licença Apache 2.0 com meu nome e uma cláusula explícita: “Uso comercial não autorizado sem contrato assinado.” Se a empresa reclama da licença, já sei o motivo real da reclamação.
O que eu carrego para o próximo processo
Não é uma lista de coisas para fazer. É um único critério, que eu forjei ao longo desses 12 processos:
Um bom processo seletivo é aquele em que a empresa também está sendo entrevistada.
Isso soa óbvio quando escrito. Mas na prática, no meio de uma call às 8 da manhã depois de uma noite mal dormida, é fácil esquecer. Cada uma das 7 armadilhas acima explora esse esquecimento. Cada contra-medida devolve à conversa a simetria que ela deveria ter tido desde o início.
Se o processo se recusa a essa simetria, ele revela o que a relação de trabalho vai ser. Custo baixo pelo lado da empresa, custo alto pelo lado do candidato. É melhor pagar esse preço em 40 horas de entrevista do que em 40 horas por semana durante 2 anos.
Se você já passou por algum desses 7 no primeiro semestre de 2026, comenta em qual etapa você notou. Estou tentando montar um cruzamento entre padrão × senioridade × porte da empresa, e cada relato adiciona sinal.
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews
Este artigo foi útil?