Uma das perguntas que mais escuto na minha experiência como professora atualmente tem sido: “como entrar na área de TI?”

Pra essa pergunta não existe uma resposta exata, mas, por conta dela, resolvi falar um pouco sobre como têm sido as minhas experiências com entrevistas.

Antes de tudo: o que vou trazer aqui é baseado na minha vivência pessoal, tá? O recorte é bem específico. Estou falando de vagas de desenvolvedor pleno (e sênior em alguns casos), com stack de Ruby on Rails, React e JavaScript, em empresas brasileiras e, principalmente, estrangeiras.

Infelizmente, não tenho registros das entrevistas de júnior porque, na época, eu não documentava nada. Então, este post foca no que vivi depois disso.

E, claro, cada empresa organiza o processo de um jeito. A ideia aqui não é dizer que a sua entrevista vai ser exatamente assim, mas mostrar alguns formatos que já encontrei e coisas que podem ajudar na preparação.

Dito isso, vamos lá.

Como costumam ser os processos?

Os processos variam bastante. Tem empresa que começa com recruiter, tem empresa que já coloca você numa conversa direto com o CTO. Tem processo com cinco etapas bem definidas e tem processo que apresenta um roteiro completo e depois muda tudo no meio do caminho.

Uma coisa que ficou bem clara pra mim é que o nome da etapa nem sempre descreve o que vai acontecer. Uma “conversa inicial” pode ser só informativa, mas também pode ser a primeira avaliação mais aprofundada do processo.

Por isso, antes de cada entrevista, vale tentar entender duas coisas: qual é a etapa e com quem você vai conversar.

1. Entrevista com recruiter

Geralmente, a primeira etapa de um processo seletivo é com uma pessoa de recrutamento.

Mas vai uma dica: antes de entrar na call, vale pesquisar no LinkedIn o nome que aparece no convite da reunião. Em alguns casos, essa primeira conversa pode ser diretamente com alguém de engenharia, e saber disso com antecedência muda bastante o tipo de preparação que pode fazer sentido.

No geral, o que costuma aparecer numa conversa com recruiter é:

  • sua trajetória
  • as tecnologias com que você trabalha
  • algum projeto ou desafio relevante
  • sua motivação pra buscar uma vaga nova
  • expectativa salarial

Esse último apareceu em quase todos os processos que fiz, então é bom entrar já sabendo como pretende responder. Uma coisa que aprendi é que não tem problema perguntar se a empresa tem um range salarial, em muitos casos eles respondem. Mas quando não definem, você vai ter que dizer um valor mesmo.

Se for uma pessoa de recrutamento, provavelmente você não vai precisar aprofundar tanto a parte técnica. O mais importante tende a ser explicar sua experiência com clareza e conectar o que você já fez com o que a vaga está buscando.

Uma coisa que me ajudou muito foi ensaiar antes, principalmente nas entrevistas em inglês. Isso deu muito mais fluidez na fala e me ajudou a manter o foco no que realmente precisava demonstrar.

2. Entrevista com alguém de engenharia ou liderança

Em vários processos, é normal e esperado ter uma conversa com uma pessoa de engenharia, um CTO ou alguma outra liderança. Isso pode acontecer logo na primeira etapa ou em outro momento do processo. Vai depender muito da empresa.

E geralmente essa conversa costuma ser bem mais técnica do que o nome da etapa faz parecer.

Já tive uma conversa que não envolvia código nem exercício, mas em que precisei explicar um projeto em profundidade: qual era o problema, quais decisões foram tomadas, quais trade-offs existiam e o que eu faria diferente hoje.

Também já me perguntaram coisas como:

  • como eu tomo decisões técnicas
  • como começo a trabalhar com uma API que nunca usei
  • como lido quando encontro um bug em produção
  • o que mudaria no sistema em que trabalho hoje
  • como defenderia uma mudança técnica pra meu manager
  • como ajo quando um prazo fica mais apertado
  • o que gosto e o que não gosto na stack que uso

Entre muitas outras.

Então, vale chegar preparado pra falar não só sobre o que você fez, mas por que fez daquela forma.

Uma coisa que aprendi é que ajuda muito ter dois ou três projetos que você conhece de verdade. Não precisa decorar um discurso, mas é bom conseguir explicar o contexto, a sua participação, as decisões, o resultado e o que aprendeu.

3. Culture fit/entrevista comportamental

Alguns processos têm uma etapa voltada pra cultura e comportamento, mais voltada pra entender como você trabalha e ver se “casa” com a forma da empresa de trabalhar.

Se a empresa tiver uma página sobre valores, vale dar uma lida antes da entrevista. Provavelmente vão ser comportamentos alinhados com esses valores que a empresa vai procurar na sua fala.

Então se a empresa valoriza, por exemplo, independência e comunicação assíncrona, não pega bem você demonstrar que prefere alinhamentos diários ou que precisa de muita validação do time pra tomar decisões.

E lembre-se: nessa etapa o foco é comportamental.

Uma vez, tive uma entrevista assim conduzida por dois engenheiros e, por serem engenheiros, achei que precisava caprichar nos detalhes técnicos.

Lembro que teve uma pergunta sobre como eu lido com desacordo no time e eu fui parar na arquitetura do sistema. Não era isso que eles queriam entender.

O que importava ali era minha postura, como a situação foi resolvida e o que eu aprendi. A parte técnica era só contexto.

Os temas costumam girar em torno de:

  • comunicação e colaboração
  • como você lida com desacordos e feedback
  • autonomia e tomada de decisão
  • erros e aprendizado
  • trabalho remoto e comunicação assíncrona

Quando a gente fica nervoso, a tendência é alongar as respostas e perder o fio. Uma estrutura que pode ajudar é pensar em situação, ação, resultado e aprendizado.

Não precisa ser rígido, mas ter essa sequência na cabeça evita respostas que começam num lugar e terminam em outro.

E essa etapa também pode te contar muita coisa sobre a empresa.

Durante essas conversas, já consegui entender melhor a frequência de reuniões, o nível de autonomia do time e como as decisões costumam ser tomadas. Enquanto você está sendo avaliada, observa também.

4. Entrevista técnica

Essa foi, de longe, a etapa com mais variação nos processos que fiz. Pode ser live coding, perguntas conceituais, uma regra de negócio, um exercício pra casa, um diagrama de arquitetura ou uma combinação de várias coisas. Vou falar principalmente dos formatos que já vivi.

Live coding

Live coding é aquele tipo de entrevista em que você precisa programar ao vivo, compartilhando a tela ou usando algum editor online. Já apareceu pra mim como:

  • exercício de lógica
  • regra de negócio em JavaScript e Ruby
  • implementação em React
  • CRUD em Rails

Nem sempre dá pra saber o formato com antecedência, então vale se preparar tanto pro seu próprio ambiente quanto pra usar um editor online mais limitado.

O que costuma ser avaliado não é só se você chega à solução certa, mas como você interpreta o problema, reage quando algo dá errado e se comunica durante a resolução.

Numa das entrevistas que já fiz, o exercício era percorrer uma string, registrar a posição de cada letra num hash e depois ordenar os resultados.

Cheguei a uma solução funcional, mas com uma abordagem menos elegante. Mesmo assim, consegui avançar.

O que ficou disso é que começar com algo simples costuma ser melhor do que travar esperando a solução perfeita aparecer.

Em outra, o exercício envolvia calcular por quantas semanas uma quantidade de medicamento duraria. O cenário simples foi tranquilo, mas quando a quantidade não fechava em semanas inteiras, a coisa complicou. O problema não era a linguagem, era traduzir uma regra matemática em código sob pressão.

Esses dois exemplos me lembraram de algo importante: vale sempre praticar lógica. Conseguir resolver um problema do zero, sem IA, sem Stack Overflow, é exatamente o que um live coding vai exigir.

A IA é ótima no dia a dia, mas no live coding você não vai ter ela do seu lado. Se você estiver acostumado a depender dela pra pensar, pode ser difícil quando ela não estiver disponível. Vale treinar sem de vez em quando, só pra manter esse músculo ativo.

Uma dica que faz diferença: fala em voz alta enquanto resolve.

Explica o que você entendeu do problema, qual caminho pretende seguir, o que está testando. Ficar em silêncio dificulta a avaliação porque a outra pessoa só vê o código e não consegue acompanhar o raciocínio.

Parece estranho no começo, mas é algo que vale praticar.

Ah, e algumas empresas permitem consultar a documentação durante o exercício. Se for o caso, ótimo, porque no dia a dia ninguém lembra tudo de cabeça.

Perguntas conceituais e cenários de arquitetura

Além do live coding, podem aparecer perguntas sobre conceitos e situações técnicas:

  • Open-Closed Principle
  • separação de responsabilidades
  • background jobs
  • feature flags
  • testes
  • banco de dados
  • cache
  • migrações

Essas perguntas nem sempre são do tipo “explique o conceito X”. Às vezes a pessoa apresenta uma situação e quer entender como você pensa pra construir uma solução.

Numa entrevista, perguntaram como eu faria uma migração em uma tabela que recebia dados constantemente e não poderia ficar bloqueada. A questão não era só saber adicionar uma coluna, era pensar nos dados antigos, nos novos registros durante a migração, na compatibilidade temporária e no risco de indisponibilidade.

Organizar a resposta em etapas, antes, durante e depois da mudança, ajuda bastante nesses casos. E não tem problema levar alguns segundos pra organizar as ideias antes de começar a falar.

Avaliação de arquitetura

Algumas empresas pedem uma avaliação mais voltada pra arquitetura, normalmente no formato de system design durante a entrevista ou de um artefato enviado antes, como um diagrama de um projeto real, pra discutir ao vivo depois.

Diferente do live coding, o foco não está em escrever a implementação. A ideia é entender como você organiza um problema maior e quais pontos considera antes de propor uma solução

Quando a empresa pede um artefato antes, vale perguntar: ele é eliminatório ou só o ponto de partida pra uma conversa? Que nível de escala esperam ver? Querem o projeto que você mais domina ou o maior sistema em que já trabalhou?

Coisas assim vão te ajudar a entender como construir o artefato.

O que a entrevista revela sobre a empresa

Algo que fui percebendo com o tempo é que a entrevista não é só uma prova pra você passar. Ela também conta muita coisa sobre a empresa.

A forma como o processo é conduzido, se os critérios são claros ou implícitos, se as etapas são respeitadas ou mudam sem aviso, se as pessoas chegam preparadas, tudo isso diz bastante sobre como a empresa se organiza e toma decisões no dia a dia.

Então, enquanto você está sendo avaliado, é importante observar também. Você não precisa sair de cada conversa pensando só se a empresa gostou de você.

Também vale pensar se aquilo que ouviu faz sentido pro tipo de lugar em que gostaria de trabalhar. Até porque vai ser nessa empresa que você vai passar boa parte do seu dia.

Tudo que trouxe aqui são experiências que ainda uso pra tentar melhorar a cada processo. Não existe uma fórmula, mas existe prática, autoavaliação e, com o tempo, mais clareza sobre o que funcionou e o que não funcionou pra você.

E isso vale pros dois lados: tanto pra melhorar nas entrevistas quanto pra entender se o lugar que está avaliando você é realmente o lugar onde você quer estar.

Até a próxima!