Entrevista técnica de programador: mostre seu raciocínio

Uma entrevista técnica de programação serve para mostrar como você entende um problema, toma decisões e verifica o resultado. Nesta lição, você vai preparar seu projeto, praticar um desafio em JavaScript, reproduzir um caso de borda e organizar histórias profissionais sem decorar uma personagem.

Live coding é a etapa em que você escreve código enquanto conversa ou compartilha a tela. Take-home é um exercício feito fora da reunião. Algumas empresas discutem um projeto; outras combinam código, fundamentos e perguntas comportamentais. Não existe um roteiro universal, então o primeiro passo é perguntar qual será o formato daquela vaga.

O desafio abaixo foi executado no Node 26.3.0. A saída e o TypeError são reais. Eles comprovam o comportamento do exemplo, não antecipam uma questão que alguma empresa fará.

A pessoa no banco do passageiro precisa enxergar a rota

Imagine dirigir até um endereço novo com alguém avaliando sua navegação. Chegar ao destino importa, mas a pessoa também precisa perceber que você leu a placa, reduziu num cruzamento confuso, conferiu o mapa e corrigiu uma entrada errada. Ficar em silêncio até estacionar esconde todas essas decisões.

Na entrevista, o destino é o resultado; requisitos são placas; exemplos são o mapa; testes são conferências; e pensar em voz alta torna a rota observável. O limite da analogia: falar muito não compensa código incorreto nem colaboração ruim. A comunicação serve para expor raciocínio e aceitar feedback, não para encher o tempo.

Monte um pacote simples antes do encontro:

- descrição da vaga marcada
- currículo que foi enviado
- um projeto aberto e executável
- editor e runtime testados
- quatro histórias profissionais verdadeiras
- perguntas sobre equipe, trabalho e próximos passos

Microsoft informa que suas entrevistas técnicas avaliam princípios, métodos e abordagem de resolução, além de perguntas sobre competências e currículo. A Amazon orienta candidatos a aplicar fundamentos, não apenas memorizar detalhes. Essas páginas descrevem processos dessas empresas; use-as como exemplos de critérios possíveis, não como regra para toda contratação brasileira.

Descubra o formato antes de escolher o estudo

Envie uma pergunta objetiva à pessoa recrutadora:

Para eu me preparar no formato correto, você pode confirmar as etapas técnicas?
Haverá live coding, exercício assíncrono ou conversa sobre projeto? Posso usar
minha linguagem principal e consultar documentação? Existe algum tema ou
ambiente que devo preparar?

Depois transforme a vaga em matriz. Não tente estudar todo o desenvolvimento de software na véspera:

requisito: consumo de API REST
evidencia: Agenda Sorriso busca e atualiza horários
explicacao: loading, erro HTTP, validação e atualização da tela
lacuna: cancelamento de requisição
acao_antes_da_entrevista: revisar AbortController na documentação

Faça isso com os requisitos principais. “Não tenho evidência” é um diagnóstico útil: você pode construir um exemplo pequeno ou dizer honestamente que ainda está aprendendo. A mentira costuma aparecer quando a próxima pergunta pede um detalhe.

Seu LinkedIn para programação e o currículo devem apontar para projetos que você realmente consegue abrir durante a conversa.

Antes de programar, transforme frase em casos

Use este enunciado de prática:

Receba uma lista de pedidos, cada um com status, e devolva quantos pedidos
existem em cada status.

Não comece pelo reduce. Faça perguntas que mudam a implementação:

1. A lista pode vir vazia?
2. Status desconhecido deve entrar na contagem?
3. O objeto original pode ser alterado?
4. Preciso preservar alguma ordem?
5. Qual volume aproximado de itens?

Para este treino, vamos assumir lista vazia válida, qualquer status textual, entrada não modificada e nenhuma exigência de ordem.

Implemente pequeno e faça o resultado aparecer

Crie desafio-entrevista.mjs:

import assert from "node:assert/strict";

export function contarStatus(pedidos) {
  return pedidos.reduce((total, pedido) => {
    total[pedido.status] = (total[pedido.status] ?? 0) + 1;
    return total;
  }, {});
}

const casos = [
  { entrada: [], esperado: {} },
  { entrada: [{ status: "enviado" }], esperado: { enviado: 1 } },
  {
    entrada: [
      { status: "enviado" },
      { status: "preparando" },
      { status: "enviado" },
    ],
    esperado: { enviado: 2, preparando: 1 },
  },
];

for (const caso of casos) {
  assert.deepEqual(contarStatus(caso.entrada), caso.esperado);
}

console.log(`casos: ${casos.length}`);
console.log(`passaram: ${casos.length}`);
console.log("complexidade: O(n) tempo | O(k) espaço");

Execute:

node desafio-entrevista.mjs

n é a quantidade de pedidos percorridos uma vez. k é a quantidade de status distintos guardados no objeto. Diga isso em português antes da notação: “passo uma vez pela lista e guardo uma chave por status”. O nome técnico vem depois da ideia, não no lugar dela.

Durante a conversa, narre pontos de decisão: “vou iniciar com objeto vazio para o caso sem pedidos funcionar”; “uso ?? 0 para o primeiro item de cada status”; “não altero o array recebido”. Essa fala permite que a pessoa corrija uma premissa antes de você construir em cima dela.

Caso vazio revela a regra que uma solução apressada esqueceu

Considere uma função feita só para o primeiro exemplo preenchido:

function primeiroStatus(pedidos) {
  return pedidos[0].status;
}

console.log(primeiroStatus([]));

O erro diz que pedidos[0] devolveu undefined; tentar ler .status falhou. Não é um pedido para decorar o stack trace. É um sinal de que a entrada vazia não tinha comportamento definido.

Uma correção explícita depende do contrato:

function primeiroStatus(pedidos) {
  return pedidos[0]?.status ?? null;
}

console.log(primeiroStatus([]));

Se a lista vazia deveria ser inválida, lançar um erro com mensagem de domínio seria melhor. Entrevista técnica também mede essa conversa: não existe correção universal sem requisito.

Quando travar, volte a um exemplo pequeno, diga o que já sabe e teste uma hipótese. Inventar o nome de um método para parecer rápido cria uma segunda tarefa: esconder o erro.

Seu projeto vira uma conversa de engenharia

Prepare um projeto do portfólio com cinco cartões:

Problema: dois atendentes podiam reservar o mesmo horário.
Minha responsabilidade: interface, API e regra de conflito.
Decisão: validar no servidor, que recebe todas as tentativas.
Alternativa: validar só no navegador; rejeitada porque duas telas não compartilham estado.
Limite atual: ainda falta lidar com horário de verão e fuso de outras cidades.

Espere perguntas sobre README, commits, testes, segurança e o que você faria com mais tempo. “Eu fiz tudo” não ajuda se o repositório nasceu em grupo. Diga a sua parte e reconheça contribuições.

Abra o projeto antes da reunião, rode os testes e deixe um dado de exemplo. Uma demo que depende da sua memória para criar usuário e preencher banco aumenta ruído desnecessário.

Histórias comportamentais também precisam de evidência

O método STAR organiza Situação, Tarefa, Ação e Resultado. A Amazon o ensina em materiais de preparação comportamental. Use-o para recuperar fatos, não para inventar números:

Situação: a agenda em papel gerava conflito entre dois balcões.
Tarefa: eu precisava provar uma regra antes de construir a interface inteira.
Ação: modelei horários, escrevi três casos e movi a validação para a API.
Resultado: os três casos passaram e a demo bloqueia a segunda reserva.
Aprendizado: eu adicionaria teste de concorrência com banco real na próxima versão.

Para quem vem de outra área, use atendimento difícil, treinamento de colega, priorização ou correção de processo. Experiência não técnica continua mostrando comunicação e responsabilidade. Não troque uma lembrança honesta por uma história de liderança que nunca aconteceu.

Entrevista remota também testa o ambiente

Faça uma chamada de teste com a mesma máquina e fone. Confira áudio, câmera, compartilhamento da janela certa, tamanho da fonte e notificações. Tenha o link, o fuso e um contato fora da plataforma caso a reunião falhe.

Use uma lista que possa ser marcada:

audio: testado
camera: testada ou necessidade comunicada
compartilhamento: editor legível
runtime: node --version conferido
notificacoes: pausadas
plano_b: telefone e contato do recrutamento
acomodacao: solicitada antes, quando necessária

Empresas como Microsoft e Amazon publicam canais de acomodação em seus próprios processos. No Brasil, peça pelo canal da vaga ou recrutamento. A necessidade de acessibilidade não é falha de preparação.

Faça perguntas que revelam o trabalho real

No fim, “não tenho perguntas” perde uma oportunidade de verificar se você quer a vaga. Escolha perguntas que não foram respondidas:

- Qual problema a pessoa júnior atacará nos primeiros meses?
- Como código é revisado e colocado em produção?
- Quem ajuda quando uma tarefa trava?
- Como a equipe decide que uma entrega está pronta?
- Qual é a próxima etapa e quando devo esperar retorno?

Evite transformar esse momento em interrogatório. Escute as respostas e anote o que muda sua decisão. Essas informações também serão úteis se chegar uma proposta para negociar.

Missão: grave uma solução que outra pessoa consegue acompanhar

Sem olhar a implementação pronta, resolva contarStatus nesta sequência:

1. Leia o enunciado e faça duas perguntas.
2. Escreva exemplos, incluindo array vazio.
3. Explique a estratégia em uma frase.
4. Implemente e rode os três casos.
5. Diga complexidade e uma limitação.
6. Reveja a gravação e marque onde ficou mais de um passo sem explicar.

Repita depois com um projeto seu: explique uma decisão, a alternativa e um erro real. Você não precisa parecer uma enciclopédia. Precisa tornar visível como trabalha com o que sabe, como reconhece o que falta e como verifica antes de afirmar.