Entrevistas de Node.js giram em torno do event loop, padrões assíncronos, Express ou NestJS, e as consequências de um runtime de thread única. Abaixo estão as perguntas mais comuns com respostas modelo. Middle: compreensão mais profunda, otimização e situações reais de trabalho.
Porque ela ocupa a única thread que atende todo request — um cálculo de dois segundos faz cada usuário concorrente esperar dois segundos. As opções são mover para um worker thread, para um processo ou fila separados, ou trocar o algoritmo. A armadilha é que isso parece bem com pouco tráfego no desenvolvimento e aparece como um precipício de latência sob carga.
Eles deixam você processar dados em chunks em vez de ter tudo na memória de uma vez. Ler um upload de um gigabyte com readFile aloca um gigabyte por request concorrente, que é como um serviço morre com três uploads simultâneos. Fazer pipe mantém a memória constante não importa o tamanho do arquivo. O backpressure é a parte que as pessoas pulam — se o destino é mais lento que a fonte, um stream sem pipe acumula buffer até o processo ficar sem memória.
Confirme primeiro — um heap que sobe e nunca volta depois do garbage collection, em vez do dente de serra normal. Depois tire dois snapshots do heap com minutos de diferença sob carga e compare os objetos retidos; o diff geralmente aponta o culpado diretamente. As causas mais comuns são um cache que cresce sem eviction, listeners adicionados por request e nunca removidos, e closures mantendo um objeto grande vivo.
Ele roda um processo por núcleo, então você usa a máquina inteira em vez de uma única thread, com o SO balanceando as conexões. O que ele não te dá é estado compartilhado — qualquer coisa em memória agora existe por worker, então caches em processo divergem e sessões quebram a menos que sejam movidas para o Redis. Também não conserta um handler lento; ele multiplica a quantidade de coisas que podem ficar lentas.
Do mesmo jeito que em qualquer lugar: você percebe uma consulta por item no log, depois carrega as linhas relacionadas numa única consulta. Prisma tem include, Sequelize tem eager loading, e um join cru sempre funciona. A armadilha específica do Node é fazer await dentro de um for loop, que serializa chamadas que poderiam rodar juntas — Promise.all resolve a latência, mas não resolve a quantidade de consultas.
Se o event loop está bloqueado, o que uma métrica de lag responde diretamente sem precisar chutar. Se o loop está bem, o tempo está numa chamada downstream — banco de dados, API upstream — e o esgotamento do connection pool é uma causa frequente. Os logs de latência média escondem isso; os percentis não, porque é no p99 que o esgotamento do pool aparece.
Você intercepta na camada HTTP com algo como nock em vez de mockar seu próprio cliente, assim o teste exercita a construção e o parsing reais do request. Grave uma resposta real como fixture e compare com ela. Mockar seu próprio wrapper testa se seu mock coincide com seu mock, por isso essas suítes continuam verdes enquanto a integração quebra.
Numa entrevista de verdade você fala sob pressão. O Cam faz essas mesmas perguntas, avalia cada resposta e mostra exatamente o que melhorar.
Praticar entrevista de Middle Node.js Backend →