O que entrevistas sênior medem

Duas respostas para a mesma pergunta

"Esse endpoint está lento. O que você faria?"

A primeira pessoa lista técnicas: criar um índice, cachear a resposta, jogar o trabalho para um job em background. Nada disso está errado. A segunda pergunta quão lento, para quem e desde quando. Depois ela vai estreitando. A listagem de faturas está num p95 de 1,8 segundo, e regrediu depois de um release de três semanas atrás. O índice óbvio já existe, e o custo só aparece em contas com mais de cinquenta itens. Ou seja, é um N+1 que os dados de seed nunca produziram. Ela também diz o que não faria: nada de cache aqui, porque o cache esconderia um bug que está prestes a piorar.

As duas conhecem Rails. Só uma tomou uma decisão.

O que muda nesse nível

Entrevistas anteriores perguntam se você consegue construir a coisa. O problema chega com as bordas já desenhadas, e o seu trabalho é preenchê-lo direito.

Entrevistas sênior perguntam se você consegue decidir o que construir quando ninguém desenhou as bordas, e acertar com frequência suficiente para um time seguir você.

As duas últimas linhas decidem a oferta. Quem espera receber as restrições está respondendo uma pergunta de nível pleno, por melhor que seja o código.

O loop que você vai encontrar

Em empresas Rails que contratam sênior, o processo costuma ser assim: uma conversa com recrutamento, uma triagem técnica e depois cinco ou seis rounds. Esses rounds cobrem código, system design, comportamento e um mergulho em algo que você construiu. Dois deles pegam as pessoas de surpresa.

O primeiro é a leitura de código. Você recebe algumas centenas de linhas de código real que não conhece, muitas vezes com um defeito que alguém já mapeou. Ninguém está cronometrando quanto tempo você leva para achá-lo. Estão olhando como você se move. Você lê o teste primeiro? Confere o que o método chamado retorna antes de afirmar que quem chama ignora o retorno? Fala em voz alta o que já descartou e por quê?

O segundo é a conversa de arquitetura: "Me conte a decisão técnica mais difícil que você tomou este ano." Isso não é contar história. Querem as alternativas que você descartou, aquilo em que você errou e o que faria diferente hoje.

Há também um round com outras áreas: produto, design e às vezes suporte. É um round pontuado de verdade, e quem o trata como formalidade perde ofertas nele.

Os quatro sinais

Por trás de qualquer rubrica, quem entrevista está ouvindo quatro coisas.

O primeiro é o escopo. Quanto do sistema você considera sem ser provocado? Diante de um endpoint lento, você fica dentro do controller, ou alcança a fila, o atraso da réplica e o deploy que causou aquilo?

O segundo é a ambiguidade. O que você faz com um problema mal especificado? Quem vai bem declara as premissas em voz alta e segue em frente. Quem vai mal trava ou finge que a ambiguidade não existe.

O terceiro é a direção. Você consegue dizer o que deve acontecer em seguida, em que ordem e por que essa ordem? "A gente corrige o N+1 primeiro porque é um dia de trabalho e tira a pressão de shardear" é direção. "Existem várias opções" não é.

O quarto é o julgamento. Os seus trade-offs aguentam pressão? Esse é o sinal que separa resposta ensaiada de resposta real, porque resposta ensaiada não tem segunda camada.

Sênior ou staff?

Os dois títulos recebem as mesmas perguntas. A pontuação é que muda.

Uma resposta sênior é dona de um serviço em produção de ponta a ponta. Ela quantifica a carga, nomeia o SLO, acha o gargalo, trata falhas e plantão e defende os trade-offs sem esperar que entreguem todas as restrições.

Uma resposta staff mantém essa profundidade e acrescenta o que atravessa times. Isso inclui onde fica a fronteira entre serviços, como é a interface com os outros três times, como a migração roda enquanto o negócio continua entregando e quem precisa adotar aquilo para o trabalho ter valor.

Se você está entrevistando para staff e a sua resposta nunca sai de um repositório, estão pontuando você como sênior.

Três formas de perder esses rounds estando qualificado

A primeira é responder à versão de nível pleno da pergunta. Diante de "como você faria cache disso?", uma resposta de nível pleno explica chave de cache e expiração. Uma resposta sênior diz se aquilo deve ter cache, e o que quebra quando o cache está errado. A pergunta soa técnica, mas testa se você percebeu que era uma decisão.

A segunda é ficar dentro do código. Uma resposta sênior alcança deploy, migração, plantão, o custo da mudança e quem mais precisa saber sem que ninguém pergunte. Uma resposta que nunca sai do editor pontua como um pleno forte.

A terceira é ganhar a discussão. Quem entrevista contesta de propósito, às vezes com algo que sabe estar errado. Trate a contestação como informação a ponderar, e não como um debate a ganhar. É aqui que as pessoas perdem rounds em que já tinham passado pelo mérito técnico.

Meridian: o sistema sobre o qual vão perguntar a você

Todas as lições aqui usam o mesmo sistema, do jeito que um loop real fica voltando ao mesmo lugar.

O Meridian é um SaaS de faturamento B2B. Ele roda Rails 8, PostgreSQL e Solid Queue para o trabalho em background, com doze pessoas no time e cerca de 4.000 clientes empresariais. As faturas são geradas toda noite por conta, algumas contas têm centenas de milhares de itens e o fechamento mensal, no primeiro dia útil, traz quatro vezes o tráfego normal. Os contratos enterprise têm um compromisso de disponibilidade, e ninguém escreveu o que ele significa.

Essa última frase é de propósito. A maioria das perguntas sênior é uma restrição não escrita vestida de pergunta técnica.

O que este curso cobre

1. O que entrevistas sênior medem: esta lição
2. Perguntas de arquitetura e trade-offs: as quatro coisas que todo round de design pontua
3. Perguntas sobre escalar Rails: réplicas, shards, caches e quando cada um é a resposta errada
4. Perguntas sobre observabilidade e incidentes: SLOs, error budgets e a história de incidente que você precisa ter pronta
5. Perguntas sobre dívida técnica e upgrades: transformar dívida em argumento de engenharia, e não em reclamação
6. Respondendo bem "depende": a frase mais mal usada nesse nível
7. Simulado sênior, juntando tudo: um loop completo sobre o Meridian, com pontuação

Comece pelo round que pesa mais: a conversa de design, onde raciocinar sobre trade-off vale mais do que o diagrama.