Mock senior full stack interview: simulação com avaliação e resposta melhorada

O problema

Muita preparação de entrevista ainda acontece em pedaços:

• pergunta isolada
• resposta curta
• dica solta

Isso ajuda.

Mas não simula bem o que realmente decide o round.

Em entrevista senior full stack, o problema costuma vir misturado:

• entendimento de produto
• decisão de frontend
• decisão de API
• noção de dados
• risco operacional
• comunicação sob follow-up

Por isso, mock bom precisa parecer conversa real.

Como usar este mock

O melhor uso é este:

1. leia só o prompt
2. responda em voz alta por 10 a 15 minutos
3. pare antes da avaliação
4. compare sua resposta com a leitura crítica do guia
5. regrave uma versão melhorada

Não use como texto para decorar.

Use como espelho.

Prompt

Você está desenhando uma feature para um produto SaaS B2B. Um gerente quer uma tela de pedidos para o time de operações. Essa tela precisa listar pedidos, permitir filtro por status, busca por cliente, paginação e atualização de status. O volume é moderado hoje, mas tende a crescer. Como você pensaria a solução de ponta a ponta?

Resposta inicial do candidato

Eu começaria criando uma tela com tabela paginada, filtros e busca. No backend, faria um endpoint para listar pedidos com filtros por query string e outro para atualizar status. No banco, eu teria uma tabela de pedidos com índice por status e talvez por cliente. No frontend, eu buscaria os dados conforme os filtros mudassem e atualizaria a lista depois da mudança de status. Se o volume crescer muito, eu pensaria em cache.

O que essa resposta tem de bom

• não viajou em arquitetura cedo demais
• já percebeu que existem dois fluxos principais
• mostrou noção básica de frontend, API e banco

Onde ela ainda perde força

• escopo ainda está genérico demais
• não separou fluxo principal de nice-to-have
• não falou de consistência nem de experiência de atualização
• “se crescer muito eu pensaria em cache” é frase vaga demais

Até aqui, a resposta não está ruim.

Mas ainda não parece claramente senior.

Follow-up 1

Pergunta do entrevistador:

O que você precisaria alinhar antes de desenhar mais?

Resposta comum, mas fraca:

Eu alinharia melhor os requisitos com o PM.

Resposta melhor:

Eu alinharia três pontos que mudam o desenho. Primeiro, se a busca por cliente precisa ser substring livre ou só filtro por campo exato. Segundo, se atualização de status exige regra de transição ou auditoria. Terceiro, se essa tela precisa parecer quase real time para vários operadores ao mesmo tempo ou se refresh sob ação já resolve. Essas três respostas mudam tanto API quanto persistência e UX.

Aqui o sinal melhora porque:

• você saiu do genérico
• mostrou quais perguntas realmente mudam o desenho
• conectou requisito a impacto técnico

Follow-up 2

Pergunta do entrevistador:

Como você evitaria uma experiência ruim quando dois operadores tentam mudar o mesmo pedido ao mesmo tempo?

Resposta apressada:

Eu colocaria lock.

Resposta mais forte:

Antes de pensar em lock, eu tentaria entender o modelo de conflito que o produto tolera. Se o risco principal é sobrescrever status sem perceber, eu já pensaria em versão do registro ou updated_at na atualização para detectar conflito e devolver erro tratável pelo cliente. Se existir regra crítica de transição, a validação precisa acontecer no backend, não só na interface. No frontend, eu mostraria falha explícita e recarregaria o estado do pedido quando a atualização fosse rejeitada por concorrência.

Aqui aparecem:

• leitura de regra de negócio
• noção de backend como fonte de verdade
• tratamento de UX
• escolha mais calibrada do que “lock em tudo”

Follow-up 3

Pergunta do entrevistador:

Onde você acha que esse sistema vai doer primeiro quando o uso crescer?

Resposta rasa:

Provavelmente no banco.

Resposta melhor:

Meu primeiro suspeito seria a leitura da listagem quando busca, filtro e paginação começarem a combinar campos demais sem índice adequado. Se o time também pedir ordenação flexível e busca parcial por cliente, eu olharia cedo para plano de query e estratégia de indexação. Outra dor provável é atualização de status com auditoria e consistência de lista na UI, porque aí o problema deixa de ser só throughput e passa a ser coerência da experiência para operadores diferentes.

Avaliação do entrevistador

Se o candidato ficasse só na resposta inicial, a leitura provável seria:

• boa base
• ainda genérico
• talvez pleno forte, não necessariamente senior claro

Quando ele melhora nos follow-ups, o sinal muda para:

• consegue enquadrar requisito
• enxerga risco de concorrência
• pensa backend e frontend juntos
• sabe onde o sistema tende a doer

Ou seja:

o round sobe menos pelo diagrama e mais pela qualidade do recorte.

Resposta melhorada

Se eu fosse condensar uma resposta mais forte desde o começo, ela soaria perto disto:

Eu começaria delimitando o que essa tela realmente precisa fazer no primeiro corte: listar pedidos, filtrar por status, buscar cliente, paginar e atualizar status com segurança. Antes de abrir solução, eu confirmaria três pontos que mudam o desenho: tipo de busca, regra de transição de status e necessidade ou não de atualização quase em tempo real. Com isso definido, eu separaria dois fluxos principais: leitura da listagem e mutação de status. Na API, eu esperaria um endpoint de listagem com filtros explícitos e paginação estável e um endpoint de atualização que valide transição no backend e registre auditoria se isso importar para operação. No banco, eu partiria de modelagem simples, mas já com atenção a índice em status, data e talvez chave de cliente conforme o padrão de busca. No frontend, eu deixaria filtro e paginação como estado controlado, manteria feedback claro de loading e erro e trataria conflito de atualização com resposta explícita, não com otimismo cego. Se você quiser, eu aprofundo agora em concorrência na mudança de status ou em performance da listagem.

Por que essa versão sobe o nível

• abre pelo escopo
• faz perguntas que realmente mudam a solução
• separa leitura e mutação
• conecta UX, API e dados
• oferece um deep dive plausível

Ela não parece perfeita.

Parece bem dirigida.

E isso é o que mais importa nesse tipo de round.

O que tornararia essa resposta ainda melhor

Se o entrevistador empurrar mais, ainda daria para aprofundar:

• estratégia de paginação por cursor vs offset
• modelo de auditoria
• política de cache ou não-cache
• autorização por papel
• observabilidade de erro operacional

Mas note:

isso vem depois.

Primeiro vem estrutura.

Erros comuns nesse formato

• sair desenhando tabela e endpoint sem alinhar requisito
• falar de escala cedo demais
• esquecer concorrência em ação de status
• tratar busca como detalhe, quando ela muda bastante a solução
• responder follow-up como defesa, não como ajuste de desenho

Ângulo de entrevista

Esse mock é bom porque parece simples, mas cobre bastante coisa de senior full stack:

• produto
• frontend state
• API design
• banco
• concorrência
• comunicação

Se você treinar bem um round desses, treina junto uma parte grande do que aparece em entrevistas modernas.