Minha pergunta favorita de programação para fazer a candidatos
Uma publicação popular de blog sobre uma pergunta “favorita” de entrevista de programação – encontrar “clientes fiéis” em dois dias de logs da web – desencadeou um debate sobre o que as entrevistas realmente deveriam medir. Os comentaristas discutem o valor da ambiguidade no enunciado, a insistência em evitar soluções O(n²) e se otimizar algoritmos em memória é realista em comparação a simplesmente usar SQL ou ferramentas de shell. Muitos veem o exercício como um proxy para habilidades de estruturas de dados e comunicação, enquanto outros o criticam como artificioso, favorecendo pessoas boas em enigmas de quadro branco em vez de quem constrói sistemas sustentáveis e focados no negócio.
Ambiguidade e “truque” do enunciado
- Muitos veem a especificação de “clientes fiéis” (especialmente “pelo menos duas páginas únicas”) como mal especificada ou logicamente ambígua.
- Alguns argumentam que isso espelha especificações de produto do mundo real e testa a capacidade de identificar ambiguidades e fazer perguntas esclarecedoras.
- Outros veem isso como uma “leitura de mente” injusta, especialmente em entrevistas estressantes, em que candidatos podem temer que fazer perguntas seja penalizado.
- Há preocupação de que entrevistadores superestimem o quão claramente sinalizaram “por favor, façam perguntas”.
O que a pergunta realmente está testando
- Os defensores dizem que ela testa:
- Reconhecer má complexidade assintótica (rejeitando o ingênuo O(n²)).
- Uso de estruturas de dados básicas (mapas/conjuntos) e trade-offs de tempo e espaço.
- Capacidade de raciocinar sobre grandes volumes de dados e restrições.
- Os críticos dizem que ela recompensa בעיקר reconhecimento de padrões no estilo LeetCode e conversa sobre Big-O, não habilidades do mundo real como entender requisitos, projetar sistemas ou trabalhar com stakeholders.
- Alguns destacam que as soluções ideais em memória são frágeis e fortemente acopladas a “exatamente dois dias”, prejudicando a extensibilidade.
Estilos alternativos de solução (SQL, shell, ferramentas)
- Vários resolveriam com pipelines de shell (sort/uniq/grep/awk) ou uma pequena consulta SQLite/BD, especialmente para relatórios pontuais de negócios.
- Debate:
- Pró-DB/shell: mais rápido de implementar, mais fácil de ajustar requisitos, lida com grandes volumes via sort/índices externos.
- Pró-“20 linhas de código”: mantém dependências mínimas; foca no entendimento algorítmico.
- Alguns observam que o problema é essencialmente um join relacional; os planos de execução do BD (hash join, merge join) espelham as soluções de CS propostas.
Desempenho vs praticidade
- Há forte discordância sobre “nenhum grande engenheiro deveria aceitar O(n²)”.
- Um lado: algoritmos quadráticos são armadilhas perigosas; abordagens melhores geralmente são igualmente simples e deveriam ser intuitivas.
- O outro lado: para dados pontuais ou pequenos, tempo do desenvolvedor e simplicidade importam mais que assintótica; a otimização prematura é comum.
- Vários apontam que micro-otimizações engenhosas (armazenar apenas 2 páginas, saídas antecipadas etc.) acrescentam complexidade e reduzem a flexibilidade para métricas em evolução.
Design da entrevista, viés e experiência do candidato
- Alguns elogiam a pergunta por ser simples, reveladora e adequada até para pessoas sêniores; outros descrevem codificação algorítmica ao vivo como chata, sem alma ou “desumanizante”.
- Preocupação de que esse estilo selecione:
- Pessoas confortáveis sob testes de alta pressão e com sensação de confronto.
- Quem treinou especificamente em problemas semelhantes.
- Outros defendem exercícios colaborativos, no estilo pair programming, ou tarefas pequenas e realistas (por exemplo, apps de CLI) como sinais melhores de eficácia no dia a dia e de trabalho em equipe.