Um profissional com 15 anos de plataforma perguntou na comunidade como preparar entrevista técnica num mundo onde IA generativa escreve Apex, Flow e integração em minutos. A dúvida é legítima, e a resposta muda o que realmente vale numa entrevista de Salesforce hoje.
Vi essa dúvida circulando na comunidade e ela mexeu comigo, porque é exatamente a pergunta que reflete um mal-estar real de quem está há muito tempo na plataforma: um profissional com 15 anos de Salesforce, que já viu o ecossistema passar por Classic para Lightning, por Process Builder para Flow, por Visualforce para LWC, disse que não sabe mais como se preparar para entrevista técnica. O motivo é simples de entender e incômodo de admitir: hoje qualquer LLM escreve um trigger, monta uma classe de teste, sugere uma arquitetura de integração ou explica governor limits com uma qualidade que, cinco anos atrás, só um consultor sênior entregaria.
Eu já senti esse desconforto em entrevista do outro lado da mesa, entrevistando candidato. Pergunto sobre bulkificação, sobre quando usar Queueable versus Batch Apex, sobre como estruturar uma Price Rule que não vire pesadelo de manutenção, e cada vez mais recebo respostas afinadíssimas, quase de manual, de gente que claramente estudou com apoio de IA generativa antes da call. O problema não é a resposta estar certa. O problema é que resposta certa e decorada não me diz nada sobre se a pessoa já resolveu um problema de verdade em produção, sob pressão, com dado sujo e prazo apertado.
O que realmente separa sênior de júnior agora
A entrevista técnica de commodity, aquela que pergunta "o que é um governor limit" ou "para que serve um Record-Triggered Flow", perdeu quase todo o valor preditivo. Isso qualquer pessoa domina em uma tarde de estudo assistido por IA. O que continua difícil de fingir, e que virou o verdadeiro filtro em processos bem conduzidos, é a capacidade de julgamento em cenário ambíguo: por que você escolheu Flow em vez de Apex nessa automação específica, mesmo sabendo que ambos resolveriam; por que você recomendou não usar CPQ Advanced Approvals para aquele fluxo de aprovação e preferiu Approval Process nativo; como você conduziu a conversa quando o cliente insistiu em Agentforce antes de arrumar a qualidade de dado no Data Cloud.
Isso é o que uma IA generativa não reproduz bem, porque não existe uma resposta canônica. Existe contexto de projeto, política interna do cliente, restrição de orçamento, débito técnico herdado. Entrevistador que ainda faz pergunta de manual está testando memorização, não capacidade de arquitetura. E isso é um problema de quem conduz o processo seletivo, não do candidato.
Onde a entrevista está migrando de fato
Quem está contratando bem para posições sênior e de arquitetura já mudou o formato: menos "explique o que é uma Sharing Rule" e mais estudo de caso completo, com modelo de dados ambíguo, requisito contraditório do negócio e pedido explícito para o candidato defender a decisão e não só descrevê-la. Também virou comum pedir para o candidato revisar uma solução pronta e apontar o que está errado ou frágil, porque isso testa senso crítico, não recall.
Existe também uma cobrança crescente por fluência em Agentforce, não no sentido de decorar features, mas de entender onde um agente autônomo faz sentido e onde ele é over-engineering perigoso em cima de processo mal desenhado. Cliente que quer Agentforce antes de arrumar Data Cloud, permissão e processo é hoje o equivalente ao cliente que queria Einstein antes de limpar a base de contatos.
A leitura para quem tem bagagem
Para quem tem 10, 15 anos de plataforma, o ativo que a IA generativa não replica é a cicatriz de projeto: a vez que uma regra de comissão em CPQ virou exceção comercial e quebrou o cálculo de desconto em cascata; a vez que um Flow simples virou dívida técnica porque ninguém documentou a ordem de execução com outros automatismos no mesmo objeto; a vez que uma Sharing Rule mal pensada em Experience Cloud vazou dado de um portal para outro. Isso não se aprende gerando prompt, se aprende apanhando em produção.
O conselho prático é parar de estudar para reproduzir definição de plataforma e passar a estudar para defender decisão. Leve estudo de caso real, com trade-off explícito, para a entrevista. Se o processo seletivo insistir em pergunta de flashcard, isso já é um sinal sobre a maturidade técnica de quem está contratando, não sobre a sua.
O mercado de trabalho Salesforce está em transição silenciosa: entrevistas que medem memorização de sintaxe e definição de feature perderam valor preditivo, porque IA generativa nivela esse tipo de conhecimento em qualquer candidato disposto a estudar com apoio dela. Isso empurra o critério de contratação para julgamento arquitetural, capacidade de defender decisão sob ambiguidade e experiência real de projeto, exatamente o que separa consultor júnior de arquiteto sênior.
Para quem lidera contratação, ignorar essa mudança significa continuar filtrando pelo critério errado e perder candidato bom que não decora resposta de manual, ou aprovar candidato que só reproduz conteúdo de IA sem nunca ter sustentado uma decisão de arquitetura em produção.
Se você está se preparando para entrevista, monte um repertório de dois ou três casos reais de projeto onde você tomou uma decisão de arquitetura difícil, incluindo o trade-off que descartou e o motivo. Pratique explicar isso em voz alta, porque estudo de caso pede narrativa, não definição.
Se você conduz entrevista técnica, substitua pergunta de definição por cenário: dê um requisito ambíguo de CPQ, Flow ou integração e peça para o candidato questionar o requisito antes de propor solução. Isso revela maturidade que nenhuma pergunta de manual revela.
Cuidado para não jogar fora certificação e conhecimento de plataforma como se não importassem mais. Eles continuam sendo pré-requisito de entrada, só deixaram de ser diferencial competitivo sozinhos. Confundir isso pode levar consultor a negligenciar fundamento técnico achando que só experiência de projeto basta.
Do lado de quem contrata, também existe risco de exagerar na direção oposta e transformar toda entrevista em teste de personalidade ou soft skill, esvaziando a avaliação técnica real. O equilíbrio é avaliar fundamento e julgamento de arquitetura juntos, não um no lugar do outro.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.