O que as pessoas querem dizer com perguntas de coding em entrevistas
São tarefas de programação curtas e bem definidas para estimar como você pensa sob restrições. Não medem o trabalho perfeito no dia a dia, mas padronizam comparação quando currículos parecem parecidos. Na prática testam se você transforma ambiguidade em especificação, escolhe algoritmo razoável, implementa sem erros bobos e explica trade-offs.
Por isso duas pessoas com o mesmo número de exercícios resolvidos podem ter resultados diferentes: o entrevistador olha suposições ditas em voz alta, casos de borda, recuperação de bugs e se você argumenta complexidade de tempo e espaço com segurança, não no chute.
- Trate o enunciado como colaboração: confirme entradas, saídas e restrições antes de codar.
- Processo repetível: exemplos, força bruta, depois otimização.
- Espere follow-ups: mudam restrições, crescem entradas ou pedem segunda abordagem.
Não é colecionar problemas como troféu. É construir um fluxo confiável que produz código correto e explicável com um estranho ao lado.
Como empresas montam e calibram bancos de questões
Grandes empresas mantêm bibliotecas internas com dificuldade conhecida, controle de vazamento e rubricas. O entrevistador escolhe o que combina com o nível e adapta follow-ups conforme você estrutura rápido. Empresas menores reaproveitam bancos públicos ou clássicos levemente alterados — por isso os mesmos padrões aparecem com “histórias” diferentes.
Calibração também significa detectar falso positivo: solução decorada que quebra quando muda uma restrição. Daí variações como vetor ordenado virando fluxo, grafo implícito em grade ou DP disfarçada de contagem de caminhos. O que permanece é reconhecimento de padrão + implementação disciplinada.
- Loops mais difíceis costumam adicionar dimensão: dois ponteiros viram merge k-vias, BFS ganha estado, DP ganha restrição extra.
- Muitas rubricas pontuam resolução de problema, código, comunicação e ritmo relativo ao nível.
- Pleno costuma ser cobrado em implementação; sênior recebe mais trade-offs e extensões.
A biblioteca de padrões que cobre a maioria das entrevistas
A maior parte das perguntas cai em cerca de uma dúzia de ideias: hash para O(1), dois ponteiros em sequências monotônicas, janela deslizante, somas prefixadas, pilhas para aninhamento, heaps para “top k”, BFS/DFS, union-find, ordenação topológica e templates clássicos de DP em vetor ou string.
Estude por padrão, não só por tag de site. “Binary search na resposta” treina outro músculo que busca binária em vetor ordenado, mas ambos pedem monotonicidade e encolher o espaço de busca.
- Por padrão: um problema canônico, um mais difícil e um “pegadinha” de borda.
- Refaça no quadro ou editor vazio depois de pausa; reconhecer sem recuperar é frágil.
- Registre erros: invariante errada, off-by-one, vazio, overflow, mutar enquanto itera.
Se só medir volume, você estagna. Meça cobertura de padrões, taxa de bugs e tempo até a solução.
Arrays e strings: frequência, armadilhas e sinal
São a superfície mais comum porque o enunciado é simples e os follow-ups são ricos. Pequenas mudanças de restrição mudam a estrutura ótima. O sinal é se você declara invariantes: o que cada índice significa, o que é garantido a cada iteração e por que o algoritmo termina.
Armadilhas típicas: mutar coleção enquanto itera, confundir substring com subsequência, esquecer Unicode ou string vazia, ignorar que o vetor já vem ordenado.
- Pergunte se a entrada cabe na RAM, se é fluxo ou quase ordenada.
- Escreva duas vezes: uma verbosa e segura, outra limpa quando o invariante estiver claro.
- Estime complexidade com cuidado: laços aninhados nem sempre são O(n²) com amortização.
Listas ligadas, pilhas, filas e mapas hash
Estruturas ligadas testam disciplina de ponteiros e desenho de estado; muita gente perde prev/curr/next em reversão ou merge. Pilhas e filas aparecem com adiamento de trabalho: parênteses, pilha monotônica para “próximo maior”, travessias em camadas que não são árvore pura.
Mapas hash são o upgrade padrão para frequência, última posição, deduplicação ou chave de memoização. O sinal é justificar memória extra com ganho real de tempo, não só nomear a estrutura.
- Use nó sentinela quando simplificar borda de cabeça/cauda.
- Em LRU, saiba explicar lista duplamente ligada + mapa para O(1).
- Se usar recursão profunda, cite risco de estouro de pilha e versão iterativa em produção.
Árvores, heaps e grafos: quando o DFS faz sentido
Árvores exploram ordem de travessia, propriedades de subárvore e agregação de caminho. Grafos acrescentam ciclos, componentes desconexos e grades implícitas. Estado limpo (visitado, cores, indegree em DAG) conta muito.
Heaps entram em “top k”, merge de k fluxos ordenados ou priorização. Erro comum: esquecer log nas operações de heap ou duplicatas exigindo remoção preguiçosa.
- BFS para menor caminho em grafo sem peso; DFS quando a recursão espelha a estrutura.
- Em grade, células como nós e arestas nas quatro direções salvo enunciado diferente.
- Em árvore, diga casos base explicitamente; suposição silenciosa vira bug sutil.
Muitos problemas de matriz são grafo disfarçado. Se você nomeia o grafo, costuma reaproveitar BFS/DFS com poucas mudanças.
Programação dinâmica e gulosos: reconhecer, não decorar
DP aparece com subestrutura ótima e subproblemas sobrepostos; importa mais definir estado mínimo suficiente do que decorar dezenas de templates. Greedy entra quando escolhas locais são seguras globalmente; a conversa pode pedir contraexemplo ou esboço de prova.
Caminho prático: domine três famílias até ficarem chatas — DP linear em vetor, DP em intervalos de string e decisões estilo mochila. Depois que a recorrência e o bottom-up fluem, variantes de entrevista viram mais pensamento que digitação.
- Topo-baixo com memo quando a recorrência for mais clara; bottom-up quando a dimensão for pequena.
- Otimize memória só com solução correta; micro-otimização cedo esconde bug lógico.
- Se travar, enumere estados no papel para n pequeno até a transição aparecer.
Complexidade, testes e comunicação como multiplicadores de nota
Quem narra trade-offs costuma pontuar mais mesmo com mesma assíntota. Dizer “é O(n log n) porque ordenamos” ok; dizer quando ordenar é desnecessário porque um mapa basta é melhor. Teste não é passo final — é prova de confiabilidade.
Exemplos pequenos e depois bordas: vazio, um elemento, duplicados, negativos, overflow. Ao achar bug, corrija com calma e explique a causa.
- Toda otimização vem com modelo de carga: o que é n, médio vs pior caso.
- Se usar estrutura de biblioteca, saiba a complexidade dela.
- Resuma a abordagem em ~30s antes de digitar para evitar becos caros.
Roteiro de 30 / 60 / 90 dias que sobrevive à rotina
Em 30 dias dá para reforçar fundamentos se você já programava com frequência: semana 1 arrays/hash/dois ponteiros; semana 2 pilhas/filas/heap/padrões de busca binária; semana 3 árvores e grafos; semana 4 mistura + tempo cronometrado. Duas horas focadas vencem seis dispersas.
60 dias adiciona profundidade: grafos mais duros, famílias de DP e um mock semanal com comunicação. 90 dias serve a saltos de nível ou retorno à indústria — inclua design de sistemas ou pair se o loop alvo pedir. Dias de recuperação entram no plano, não só depois do esgotamento.
- Painel semanal: quantidade, mediana de tempo, bugs, erros repetidos.
- Alterne dias de criação e revisão; sem repetição espaçada o volume some.
- Simule pressão semanalmente; estresse revela buraco de processo cedo.
FAQs, erros comuns e próximos passos
Linguagem importa menos que fluência: escolha uma mainstream em que você use a biblioteca padrão sem tropeçar. “Quantos problemas bastam?” não tem número mágico — basta quando o recall de padrão é rápido, bugs são raros e você explica decisões com clareza.
Se travar, use resgate estruturado: repita o objetivo, proponha força bruta, ache o gargalo, melhore. Pós-entrevista, escreva um pós-mortem curto: o que quebrou, o que funcionou, um ajuste para a próxima.
- Erro: pular clarificação e codar o problema errado — corrija com mini-especificação em 2 minutos.
- Erro: ideia ótima mas código confuso — funções menores e nomes claros.
- Erro: não falar de complexidade — feche sempre com Big-O.
Junte leitura com execução cronometrada. A Preplyer ajuda a ensaiar prompts técnicos realistas com feedback para levar seus padrões da prática solo para a sala de entrevista.
Key Takeaways
- Perguntas de coding valorizam processo e comunicação tanto quanto o código final.
- Estudo por padrão vence volume aleatório; acompanhe bugs e tempo, não só “feitos”.
- Espere follow-ups que mudam restrições; flexibilidade vence memorização de uma tacada.
- Arrays, strings, árvores, grafos e DP seletiva cobrem a maior parte dos loops.
- Plano 30/60/90 sustentável vence maratona heroica que quebra sob estresse.
