Qué evalúan realmente las entrevistas para backend engineer

Buscaste una lista de preguntas. Hay muchas, y la mayoría son inútiles, porque un proceso de backend no es una prueba repetida cuatro veces. Son tres o cuatro pruebas diferentes, conducidas por personas distintas, que evalúan cosas distintas, y una lista las aplana en trivialidades. Alguien que recita el teorema CAP aún reprueba la ronda de diseño. Alguien que resuelve el problema de arrays en quince minutos aún reprueba la inmersión profunda en su propio trabajo.

Lo que sigue es la estructura de la cosa, y qué está escuchando realmente la persona del otro lado.

La estructura del proceso

Para un puesto backend de nivel medio o senior en una empresa con más de unos cincuenta ingenieros, el proceso suele ser algún subconjunto de:

1. Filtro con reclutador, 20–30 minutos. Stack, nivel, período de preaviso, ubicación y visa, expectativas de compensación, si estás de guardia ahora y si estarías dispuesto a estarlo.
2. Llamada con hiring manager, 30–45 minutos. Qué gestionas, qué has lanzado, por qué te vas. A veces una sonda técnica ligera.
3. Un ejercicio de código. En vivo en un editor compartido, en vivo en tu propio repo haciendo pair programming con un ingeniero, o un take-home que entregas y luego explicas.
4. Una ronda de diseño de sistemas, 45–60 minutos, pizarra o un canvas de Excalidraw en blanco.
5. Una inmersión profunda en algo que construiste, a veces fusionada con la ronda de diseño, a veces separada.
6. Una ronda conductual o cross-funcional, a menudo con un ingeniero de otro equipo o un product manager.

Empresas más pequeñas comprimen esto: llamada con founder, un take-home, un onsite final que hace todo a la vez. Los procesos de big-tech añaden una ronda dedicada al sistema de valores de la empresa y pueden ponderar mucho más el código algorítmico. Si un filtro algorítmico intenso predice el desempeño laboral es genuinamente debatido — encontrarás ingenieros con opiniones fuertes en ambas direcciones y muy poca evidencia pública de cualquier forma. Sigue siendo la puerta en muchos lugares, así que la pregunta práctica no es si es justo sino si este empleador en particular lo usa. Pregunta al reclutador. Te lo dirá, y el formato que nombre te dice qué preparar.

Quién está realmente en la sala

La ronda de código suele ser conducida por un senior engineer del equipo o cercano, a veces con una segunda persona en silencio tomando notas. Tienen una rúbrica. No intentan engañarte, y para la tercera ronda están mayormente aburridos, lo cual es peor.

La ronda de diseño es más a menudo un staff o principal engineer, o un senior experimentado que hace esto frecuentemente. Esta persona tiene opiniones sobre colas, y los han despertado a las 04:00 por algo que estás a punto de describir casualmente.

La inmersión profunda puede ser el hiring manager o un tech lead. Su trabajo es establecer si las decisiones en tus historias fueron tuyas o te las dieron.

Esto importa porque la misma respuesta puntúa diferente según quién pregunte. "Usamos Kafka" es un hecho para un reclutador, un punto de partida para un manager, y para el staff engineer es una invitación a preguntar por qué no SQS, cuál era tu partition key, y qué pasó con el ordering cuando tuviste que reprocesar.

El ejercicio de código, y qué evalúa realmente

Dominan tres formatos, y puntúan cosas diferentes.

Filtro algorítmico. Usualmente 45 minutos, uno o dos problemas, hash maps y two pointers y el ocasional graph traversal. La puntuación es mayormente: llegaste a una solución funcional, hablaste mientras lo hacías, notaste la complejidad, lo probaste. El silencio es el modo de fallo común, no la incorrección.

Ejercicio realista. Cada vez más común en empresas medianas. Parsea este archivo y exponlo sobre HTTP. Implementa un rate limiter. Añade un endpoint a este repo existente. Aquí la puntuación se acerca más al code review real: manejas errores o los tragas, validas input, tus nombres tienen sentido, escribiste un test, notaste la ambigüedad en la spec y preguntaste en lugar de adivinar.

Pairing en un codebase real. Te soltarán en un repo desconocido con un bug o una funcionalidad pequeña. Esto prueba navegación más que autoría: puedes encontrar dónde vive la cosa, lees los tests primero, lo ejecutas antes de cambiarlo.

En los tres, surge la pregunta del lenguaje. Si eliges Go, espera que alguien pregunte sobre context cancellation, goroutine leaks, o por qué usaste un channel donde un mutex era más simple. Si eliges Java, espera la JVM: heap versus off-heap, qué hace una pausa de full GC a tu p99, dimensionamiento de thread-pool, y algo con forma de Spring sobre bean scopes o transaction boundaries. Python invita el GIL y si tu blocking call acaba de parar el event loop. Node invita la misma pregunta con ropa distinta. Elige el lenguaje que realmente escribes, no el que crees que suena senior.

Diseño de sistemas: las preguntas dentro de la pregunta

El prompt será amplio — diseña un acortador de URL, un servicio de notificaciones, un sistema de reserva de tickets, lo que sea que el entrevistador haya hecho cuarenta veces. El prompt no es la prueba. La prueba es el conjunto de seguimientos, y son bastante predecibles porque son las cosas que realmente se rompen en producción.

Idempotencia. "El cliente llama POST /payments, timeout, y reintenta. ¿Ahora qué?" Una buena respuesta alcanza una idempotency key proporcionada por el cliente, una unique constraint en la base de datos, y una decisión sobre qué devolver en el duplicado. Una muy buena respuesta menciona el transactional outbox, porque estás a punto de publicar un evento sobre este pago y la escritura y la publicación no son atómicas.

Semántica de entrega. Casi todas las colas que nombrarás son at-least-once. Así que: cómo no cobras al cliente dos veces, y cuál es tu ventana de deduplicación, y dónde vive el estado de dedup, y qué pasa cuando expira. Si dices "exactly-once" sin calificar inmediatamente qué quieres decir, le has dado al entrevistador su siguiente pregunta.

Propagación de fallos. "Tu servicio llama a un servicio downstream que se acaba de volver lento — no caído, lento." La respuesta que quieren recorre la cadena: las requests mantienen conexiones más tiempo, el pool se satura, tu propia cola crece, tu latencia sube, tus llamadores hacen timeout y reintentan, y los reintentos amplifican la carga en lo que ya estaba luchando. Luego las mitigaciones: timeouts que realmente están configurados, budgets en lugar de timeouts por llamada, exponential backoff con jitter, circuit breakers, bulkheads, load shedding. La frase "retry storm" te gana crédito porque muestra que has visto una.

Datos. Espera preguntas de índices planteadas como síntomas en lugar de teoría: una query que era rápida el mes pasado y es lenta ahora sin cambio de código. Plan flips, estadísticas obsoletas, una asunción de selectividad que dejó de sostenerse a medida que la tabla creció, lock contention, bloat y comportamiento de vacuum en Postgres. Espera una pregunta de migración de esquema — renombrar o dividir una columna sin downtime — donde la respuesta esperada es expand and contract: añadir la nueva columna, dual-write, backfill en lotes, mover lecturas, dejar de escribir la antigua, eliminarla después.

Caching. "Añade un cache" es el comienzo de la conversación. Los seguimientos son estrategia de invalidación, TTL versus eviction explícita, qué pasa al origin cuando una hot key expira y mil requests llegan a la vez, y si estás preparado para servir datos stale y por cuánto tiempo.

Medición. Si dices que un sistema es rápido, alguien preguntará cómo lo sabes, y la moneda correcta son percentiles y tasas de error, no promedios. Saber por qué la media oculta el problema — y que el usuario que experimenta el p99 es a menudo tu usuario de mayor valor, porque tiene más datos — es una pequeña cosa que se lee como experiencia.

La inmersión profunda en tu propio trabajo

Esta ronda decide seniority más a menudo que la ronda de código. El prompt es alguna versión de "cuéntame sobre un sistema que diseñaste o cambiaste sustancialmente." Luego:

• ¿Cuáles fueron las alternativas, y por qué las rechazaste?
• ¿Qué hiciste mal?
• ¿Qué se rompió después de lanzarlo?
• ¿Cómo supiste que estaba funcionando?
• ¿Qué harías diferente ahora?
• ¿Quién no estuvo de acuerdo contigo, y qué pasó?

El entrevistador está probando si fuiste quien tomó decisiones. Candidatos que heredaron un diseño lo describen bellamente y luego no tienen nada cuando preguntan sobre las alternativas, porque nunca hubo ninguna desde su punto de vista. Eso está bien — dilo, y describe una decisión que fue genuinamente tuya, incluso si fue más pequeña. Una elección bien razonada sobre cómo hacer backfill de doscientos millones de filas es mejor evidencia que un relato vago de una arquitectura que alguien más dibujó.

Ten detalle de rollout listo. Feature flag o percentage rollout, cuál era el kill switch, qué métrica vigilaste, cuál era el plan de rollback, y si tuviste que usarlo. Ten un incidente listo en el que fuiste la causa. Blameless es la cultura; apropiar el error sin teatralidades es la señal.

Cómo suena una respuesta superficial

Desde el otro lado de la mesa, estas son las señales:

• "Usamos Kafka porque escala." Sin partition key, sin consumer group, sin mención de qué garantía de ordering necesitabas o perdiste.
• "Añadiríamos Redis." Cache declarado como la solución, sin historia de invalidación, sin TTL, sin pensar en el stampede.
• "Microservicios." Ofrecido como arquitectura en lugar de un trade — sin mención de la transacción que acabas de perder, la llamada de red que acabas de añadir, o cómo ahora los despliegas juntos de todas formas.
• "Indexaríamos esa columna." Sin sentido de cardinalidad, costo de escritura, o si la query lo usaría en absoluto.
• "Es eventually consistent." Usado como respuesta en lugar de descripción de un problema que luego tienes que manejar en la UI o el reconciliation job.
• "Era rápido, como 50 milisegundos." Promedio, a qué carga, medido dónde.
• "Tenemos cien por ciento de test coverage." Ofrecido sin ningún relato de qué assertan realmente los tests, si corren contra una base de datos real, o cómo se manejan los flakes.
• "Tendría que buscar eso." Bien para un detalle de sintaxis. No bien como respuesta a qué pasa cuando el downstream de tu servicio se vuelve lento.

El hilo común es un sustantivo donde debería haber un trade-off. Nombrar una tecnología no es una respuesta; describir qué te cuesta y por qué aceptaste ese costo sí lo es.

Qué hacer a continuación

Cuatro cosas, en orden de cuánto moverán la aguja.

Escribe dos de tus propios sistemas, apropiadamente. Un diagrama, las tres decisiones que realmente tomaste, las alternativas, qué se rompió, qué mediste. Una hora cada uno. Esta es la ronda que más se pierde y menos se prepara.

Ensaya la cadena de fallos en voz alta. Downstream lento, saturación de pool, amplificación de retry, y las cuatro mitigaciones. Si puedes decirlo con fluidez, una gran fracción de seguimientos de diseño se vuelven la misma respuesta con disfraz diferente.

Elige un lenguaje y prepárate para sus aristas filosas. Un párrafo cada uno sobre el modelo de memoria o concurrencia, cómo encontrarías un leak, y cómo perfilarías un endpoint lento.

Pregunta al reclutador qué es la ronda de código. Algorítmica, realista, o pairing. Te lo dirá, y las tres demandan preparación diferente. Preparar para la equivocada es la pérdida evitable más común en este proceso.