Você conhece o malloc ou a melhor pergunta de entrevista · clacerda

Tenho estado numa caçada – uma busca quase desesperada, por programadores. Não aqueles que conseguem juntar um site com um framework da moda, mas os de verdade. Aqueles que entendem o zumbido e o tremor da máquina, os que conseguem lutar com a lógica bruta que faz tudo funcionar.

Isso não é para o desenvolvedor web médio, Não, não, não. Isso é para alguém que trabalharia com programação de sistemas fullstack de verdade; talvez até mesmo ajustando o kernel, debugando o compilador, criando novas funcionaliades em um grande banco de dados. Isso é para as pessoas que trabalham do metal à cloud, e onde o desempenho realmente importa. Isso é para as programadores que construirão os alicerses do mundo digital.

Então, como você encontra alguém assim? As grandes empresas de tecnologia usam a abordagem de entrevistas com algoritmos, e sim, funciona, mas também é terrivelmente, terrivelmente falha. Ela exclui tantos bons candidatos, pessoas que podem ter o talento bruto e a compreensão, mas não o tempo ou disciplina para moer os exercícios por meses. As big techs podem se dar ao luxo de fazer isso porque têm tantos candidatos na fila para suas vagas. Mas eu não tenho esse luxo. E preciso encontrar muitas pessoas que sacam, e preciso encontrá-las agora.

Então, eu inventei um truque. Uma pergunta, talvez até um pouco sádita, para minhas entrevistas, e acho que acabei de esbarrar na melhor pergunta de entrevista de todos os tempos. Pelo menos, para este cenário.

Começa com as gentilezas habituais, a conversa fiada constrangedora, a dança do “me fale sobre seu currículo”, "me explique recursão", etc. Então, eu me inclino, um brilho de algo parecido com alegria maníaca do coringa, e pergunto: "Então, me diga… você conhece o malloc?"

A reação é sempre a mesma, uma mistura de confusão e confiança. "Sim, claro, eu já usei," eles dizem, como se fosse uma função qualquer.

"Ótimo," eu digo, batendo palmas com um grande entusiasmo forçado. "Você tem quinze minutos para implementá-lo."

E nesse momento sempre acontece a mesma coisa: os olhos dos cantidos se arregalam, não com surpresa, mas com uma espécie de pavor, como se tivessem acabado de ver o rosto da Medusa. A cor foge das bochechas, deixando-os com uma palidez quase patologica, e um leve tremor percorre os dedos, que antes tamborilavam com confiança sobre a mesa. A boca se abre para dizer algo, mas as palavras parecem ter se perdido no labirinto da mente, como se a simples ideia de implementar malloc em quinze minutos tivesse paralisado a capacidade de raciocínio. Um suor fino começa a brotar na testa, e é possível ver as engrenagens mentais girando freneticamente, tentando encontrar uma saída para aquele beco sem saída.

E é nesse silêncio tenso, naquele momento de pura perplexidade, que se separam os fracos dos fortes.

A Verdade Brutal

Malloc não é apenas uma função. Não é uma caixa preta que magicamente conjura memória do nada. É o coração de cada aplicativo. É um um pedido por espaço na vasta e caótica paisagem da RAM. Não importa se sua linguagem de escolha é Python, Java, Javascript, Rust, C#, ou qualquer outra por aí: toda alocação dinâmica eventualmente chama malloc (ou algo muito parecido). É uma chamada em C.

E, na maioria das vezes, é a implementação do glibc – um labirinto de mais de 50.000 linhas de código C, um monumento à otimização.

Então, como um candidato de nível júnior, recém-saído da universade, é esperado para recriar isso em 15 minutos? É um completo absurdo, certo?

Não: o objetivo não é recriar o glibc. O objetivo é ver se eles entendem os princípios básicos. Porque, em sua essência, malloc não é sobre otimização; é sobre:

Algoritmos, Não Encantamentos: Eles conseguem entender a ideia básica de um algoritmo de best-fit ou first-fit? Eles entendem os trade-offs entre velocidade e uso de memória? Eles estão familiarizados com algumas estruturas de dados básicas? Eles sabem o que é uma lista ligada? Ou uma árvore?
Chamadas de Sistema, Não Caixas Pretas: Eles entendem que é, em última análise, uma chamada para o sistema operacional, um chamada para sbrk ou mmap por mais memória? Eles entendem a diferença entre um heap contíguo e um não contíguo?
Abstração, Não Perfeição: Eles conseguem reduzir um problema complexo aos seus componentes essenciais? Eles conseguem construir um alocador simples e funcional sem se perder nos detalhes?

É sobre ver se eles entendem o porquê por trás do como. É sobre testar sua capacidade de raciocinar sobre os mecanismos centrais que fazem todo programa de computador funcionar. É sobre ver se eles conseguem pensar como um engenheiro, não apenas como um programador.

Porque, quando você remove todas as otimizações sofisticadas, malloc se resume a algumas peças essenciais:

Uma forma de obter memória
Uma maneira de rastrear quais blocos estão ocupados
Um processo para de encontrar um espaço livre

É isso. Não é ciência de foguetes. É programação de sistemas básica. Qualquer programador competente que tenha deveria ter uma imagem mental disso no nível mais baixo. Eles podem não saber da sintaxe exata de sbrk ou das complexidades dos pools de memória thread-safe, mas eles devem entender os conceitos básicos.

Um abraço e bons estudos.

Depois de 40 anos, mexendo com isso, estudando o malloc() em várias implementações, entre outras formas de gerenciar memória, entendendo de fundamentos, ensinado muita gente sobre isso, pesquisando para fazer alocadores específicos, eu duvido que eu consiga fazer em 15min qualquer coisa além de um básico muito grande sem nenhuma otimização, e provavelmente sairia bem pouco sem poder consultar documentação.

Concordo com a ideia do artigo, mas a exigência de fazer algo que funciona em tão pouco tempo parece um pouco forçado para quem nunca trabalhou com ele de forma direta e por longo período. Nem sou totalmente contra e em alguns casos pode ser o mínimo.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).