Las entrevistas de Node.js giran alrededor del event loop, patrones asíncronos, Express o NestJS, y las consecuencias de un runtime de un solo hilo. Aquí están las preguntas más comunes con respuestas modelo. Middle: comprensión más profunda, optimización y situaciones reales de trabajo.
Porque ocupa el único hilo que sirve cada request — un cómputo de dos segundos hace que cada usuario concurrente espere dos segundos. Las opciones son moverla a un worker thread, a un proceso o cola separados, o reemplazar el algoritmo. La trampa es que se ve bien con poco tráfico en desarrollo y aparece como un acantilado de latencia bajo carga.
Te dejan procesar datos en chunks en vez de tenerlos todos en memoria. Leer un upload de un gigabyte con readFile asigna un gigabyte por request concurrente, que es cómo un servicio muere con tres uploads simultáneos. Hacer pipe mantiene la memoria constante sin importar el tamaño del archivo. El backpressure es la parte que la gente se salta — si el destino es más lento que la fuente, un stream sin pipe acumula buffer hasta que el proceso se queda sin memoria.
Confírmala primero — un heap que sube y nunca vuelve después del garbage collection, en vez del sawtooth normal. Luego toma dos snapshots del heap con minutos de diferencia bajo carga y compara los objetos retenidos; el diff usualmente nombra al culpable directamente. Las causas usuales son una caché que crece sin eviction, listeners agregados por request y nunca removidos, y closures manteniendo vivo un objeto grande.
Corre un proceso por núcleo así que usas toda la máquina en vez de un solo hilo, con el SO balanceando conexiones. Lo que no te da es estado compartido — cualquier cosa en memoria ahora existe por worker, así que las cachés en proceso divergen y las sesiones se rompen a menos que se muevan a Redis. Tampoco arregla un handler lento; multiplica la cantidad de cosas que pueden ser lentas.
De la misma forma que en cualquier lado: notas una consulta por elemento en el log, luego cargas las filas relacionadas en una sola consulta. Prisma tiene include, Sequelize tiene eager loading, y un join crudo siempre funciona. La trampa específica de Node es hacer await dentro de un for loop, que serializa llamadas que podrían correr juntas — Promise.all arregla la latencia, pero no arregla la cantidad de consultas.
Si el event loop está bloqueado, que una métrica de lag responde directamente y adivinar no. Si el loop está bien, el tiempo está en una llamada downstream — base de datos, API upstream — y el agotamiento del connection pool es una causa frecuente. Los logs de latencia promedio esconden esto; los percentiles no, porque el p99 es donde vive el agotamiento del pool.
Interceptas en la capa HTTP con algo como nock en vez de mockear tu propio cliente, así el test ejercita la construcción y parsing real del request. Graba una respuesta real como fixture y compara contra ella. Mockear tu propio wrapper testea que tu mock coincide con tu mock, por eso esas suites se mantienen verdes mientras la integración se rompe.
En una entrevista real hablas bajo presión. Cam hace estas mismas preguntas, evalúa cada respuesta y muestra exactamente qué mejorar.
Practicar entrevista de Middle Node.js Backend →