Pitches de Práctica

Hola, soy [nombre] — un ingeniero backend con [X] años en Node.js y los últimos [Y] enfocados en NestJS y TypeScript. Construyo y escalo APIs y servicios.

Más recientemente [entregué / fui dueño de] [un servicio o dominio] — [una cosa concreta: por ejemplo, un servicio de auth, un pipeline de pagos, una API GraphQL] — manejando [escala: por ejemplo, unos pocos miles de RPS], con enfoque en límites de módulos limpios, testing y observabilidad.

Me atrae este rol porque es senior, enfocado en backend y tiene NestJS como núcleo.

Soy [nombre], un ingeniero backend / full-stack con [X] años en JavaScript y TypeScript, los últimos [Y] construyendo servicios en NestJS sobre Node.

Lo que hago bien: diseño servicios modulares, probables — límites de módulos claros, inyección de dependencias, DTOs validados — y me importa lo que sucede después del despliegue: logging estructurado, tracing, apagado graceful y no bloquear el event loop. Soy cómodo en la capa de datos (Postgres con TypeORM/Prisma, Redis), auth (JWT + RBAC) y trabajo asíncrono (colas, eventos).

Un hito reciente: [un proyecto específico — qué hacía, tu rol y un resultado medible, por ejemplo, reduje la latencia p99 en 40% o entregué un microservicio que maneja N eventos/día].

Busco un rol senior de backend donde pueda ser dueño de la arquitectura y elevar el estándar del equipo — que es exactamente lo que esto parece.

Empieza en el arco, no en el CV. [Empecé en [frontend/full-stack], me moví a backend porque me gustaba ser dueño de los datos y los contratos.]

Luego 2–3 capítulos, cada uno con una oración de contexto + una cosa de la que estás orgulloso: "En [empresa] [construí X], lo que me enseñó [Y]." Muestra una progresión — más propiedad, sistemas más grandes, más impacto.

Aterriza en el presente: "Ahora soy más fuerte en [diseño de servicios con DI / rendimiento / sistemas distribuidos], y quiero un rol donde [sea dueño de la arquitectura / mentoree / escale una plataforma]." Conecta con este empleo.

Express es genial pero no tiene opiniones — las aplicaciones grandes se desordenan. NestJS me da estructura e inyección de dependencias sobre la capa HTTP de Node, para que la arquitectura sea consistente y probable desde el primer día.

Concretamente: el sistema de módulos impone límites, DI hace que todo sea mockeable, y el pipeline de requests — guards, interceptores, pipes, filtros — me da lugares limpios para auth, validación y preocupaciones transversales. Y porque es TypeScript de extremo a extremo, el compilador atrapa clases enteras de bugs.

Escala de un monolito modular a microservicios sin cambiar el modelo de programación — eso es raro y valioso.

Tres razones honestas, personalizadas: (1) el problema — [qué están construyendo y por qué te interesa]; (2) el ajuste técnico — [su stack/escala coincide con lo que hago: NestJS, [su stack de datos], [su escala]]; (3) el rol — [propiedad senior / el equipo / remoto / el dominio].

Cierra con una línea con visión de futuro: "Quisiera pasar mis primeras semanas entendiendo [su servicio principal] y encontrando dónde puedo añadir más palanca más rápido."

Dos cosas definen a Nest: inyección de dependencias y el ciclo de vida de requests.

DI: las clases declaran lo que necesitan en el constructor, y el contenedor IoC lo provee. El tipo es el token; durante el arranque Nest construye el grafo de dependencias e instancia de abajo hacia arriba, cacheando singletons. Por eso todo está desacoplado y trivialmente mockeable en tests.

El ciclo de vida: una request fluye a través de middleware → guards → interceptores → pipes → el manejador → interceptores de nuevo → filtros de excepción. Cada uno tiene una función — guards hacen autorización, pipes validan y transforman, interceptores envuelven el manejador para cosas como caché y timeouts, filtros dan forma a los errores. Conocer ese orden me permite poner cada preocupación exactamente en el lugar correcto.

Situación: [un endpoint / servicio] estaba [lento / con timeout] bajo carga — [p99 saltó a X / colapsó en Y RPS].

Tarea: Fui dueño de encontrar y corregir la causa raíz sin reescribir.

Acción: Medí en lugar de adivinar — [revisé el event-loop lag / leí traces / capturé un flamegraph] y encontré [la causa: una consulta N+1 / trabajo de CPU bloqueante / un índice faltante / concurrencia sin límite]. [Agrupé la consulta con un DataLoader / moví el trabajo a un worker thread / añadí el índice / acoté la concurrencia] y añadí [una caché / una prueba de regresión].

Resultado: [p99 bajó de X a Y / throughput Nx], y añadí una alerta en [loop lag / p99] para que no pueda retroceder silenciosamente.

Situación: tuvimos que [elegir entre X y Y — por ejemplo, monolito vs microservicio, SQL vs NoSQL, síncrono vs cola].

Tarea: Tenía que tomar la decisión y alinear al equipo.

Acción: La enmarqué por las restricciones que realmente importaban — [escala, consistencia, tamaño del equipo, fecha límite] — y nombré el compromiso explícitamente: "[Opción A] nos da [beneficio] al costo de [desventaja]." [Prototipeé / hice benchmarks / escribí un ADR corto] y recomendé [la elección], con un fallback si [la suposición] resultaba incorrecta.

Resultado: [resultado], y porque había documentado el compromiso, no lo volvimos a discutir después.

Node ejecuta tu JavaScript en un solo hilo Piensa en un chef en una cocina: puede empezar muchos platos (llamadas de red, lecturas de archivos) y dejar que los hornos (el OS y un pequeño pool de hilos) cocinen en background, revisando cuando algo está listo. Por eso Node maneja miles de operaciones de E/O lentas a la vez.

La trampa: si el chef se detiene a picar una montaña de verduras a mano — una tarea de CPU pesada — cada otro plato espera. Eso es bloquear el event loop. Por eso mantenemos el trabajo pesado de CPU fuera de ese hilo: worker threads o una cola.

Ese modelo mental — excelente esperando, malo moliendo — explica la mayoría de consejos de rendimiento de Node.

Siempre ten 3–4 listas. Las buenas señalan senioridad:

"¿Cómo se ve la arquitectura de servicios hoy — monolito modular, microservicios, algo intermedio — y cuál es el mayor punto de dolor?"

"¿Cómo manejan el testing, CI/CD y observabilidad? ¿Cómo es el story de on-call?"

"¿Cómo sería el éxito en este rol en los primeros 90 días?"

"¿Dónde está la base de código pagando deuda técnica y dónde tendría más palanca al inicio?"

Se mapean a diferentes necesidades. Express es la capa middleware universal, no opinada — excelente para BFFs, webhooks y proxies delgados. Fastify es la jugada de rendimiento: serialización basada en esquema y encapsulación de plugins. NestJS es la jugada de estructura: módulos, DI y un pipeline de requests que escala con el equipo y la base de código.

Sobre velocidad — cito los números, pero honestamente. La ejecución oficial de fastify/benchmarks hello-world tiene Fastify alrededor de 45,140 req/s vs Express alrededor de 10,702 — unas 4.5× en esa ejecución; otros benchmarks llegan más cerca de 2–3×. Pero el repo en sí dice que esos números "no pretenden representar un escenario del mundo real", y se ejecutan en hardware CI compartido ruidoso, así que los resultados varían. Los trato como direccionales, nunca como titular.

Porque en una carga real el framework raramente es el cuello de botella — la base de datos, las llamadas posteriores y la lógica comercial dominan. Así que elijo por ajuste de equipo y estructura, y llego a NestJS. Y si un servicio específico es genuinamente crítico en rendimiento, Nest se ejecuta en el adaptador Fastify y recupera la mayoría de esa velocidad — no tengo que elegir.

La meta-habilidad senior no es conocer la respuesta — es enmarcar la decisión. Una oración, cada vez: "La Opción A optimiza X al costo de Y; dadas las restricciones Z, elegiría ___ y revisaría si [umbral]."

Concretamente, digamos que preguntan si ejecutar una exportación pesada inline o en una cola: "Hacerlo sincrónicamente optimiza la simpleza y la retroalimentación inmediata, al costo de mantener una request abierta y riesgo de timeouts bajo carga. Encolarlo optimiza la resiliencia y el rendimiento, al costo de complejidad de consistencia eventual y una UX de estado de trabajo. Dada que nuestra exportación toma unos pocos segundos y el tráfico es irregular, la encolaría — y revisaría el camino síncrono solo si la latencia p95 del trabajo cae bajo un segundo y el volumen sigue bajo."

Mira lo que eso hace: nombra ambos costos, ata la elección a una restricción real, y da un disparador medible para reabrirla — latencia p95/p99, tasa de error, costo por request. Esa es la diferencia entre "Elegí la cola" y "Tomé una decisión que puedo defender y deshacer."

Usa CARL — Contexto, Acciones, Resultados, Aprendizajes. El tiempo de Aprendizajes es lo que STAR pierde, y es lo que señala madurez: muestra que reflexionas, no solo ejecutas. Lidera con tu historia de alcance más grande incluso si no es una coincidencia literal, y cuantifica el impacto.

Contexto: [el sistema + las apuestas — por ejemplo [servicio] estaba [fallando / en un punto de decisión] afectando [X usuarios / $Y / una fecha límite]; fui dueño de [alcance].]

Acciones: [lo que tú hiciste — el marco que usaste, las alternativas que rechazaste y por qué, a quién alineaste. "[Medí / hice benchmarks / escribí un ADR], elegí [X] sobre [Y] porque [restricción]."]

Resultados: [el resultado medible — "[métrica] se movió de [A] a [B]" / "[incidente] resuelto en [N] con una post-mortem sin culpa y propietarios asignados."]

Aprendizajes: [qué harías diferente y qué llevaste adelante — "Habría [cambiado] antes; desde entonces [nueva práctica]."]