Backend - Senior

Información del candidato

Nombre completo

Teléfono (opcional)

Años de experiencia

CV / Currículum Formatos aceptados: PDF, DOC, DOCX. Máximo 5MB

Preguntas de conocimiento

Este código Eloquent tiene un problema de rendimiento: `$posts = Post::all(); foreach ($posts as $post) { echo $post->author->name; }`. ¿Cuál es el problema?

Debería usar `Post::get()` en vez de `Post::all()` porque `get()` es más eficiente al utilizar lazy loading optimizado internamente por Eloquent

El problema es usar `foreach` nativo de PHP en vez del método `->each()` de la colección, que está optimizado para iterar modelos Eloquent

N+1 Query Problem: se ejecuta 1 query para posts + N queries adicionales (una por cada post para cargar el autor). Solución: `Post::with("author")->get()` (eager loading)

Falta paginación en la query; sin `->paginate()` Eloquent carga todos los registros en memoria causando un timeout del servidor

Este middleware Laravel no funciona: `public function handle($request, Closure $next) { if (!$request->user()->isAdmin()) { abort(403); } $next($request); }`. ¿Qué falta?

Falta el import de la clase `Closure` en la parte superior del archivo del middleware para que PHP pueda resolver el type hint correctamente

Debería usar `$request->user` como propiedad sin paréntesis en vez de `$request->user()` como método, ya que es un accessor de Eloquent

El `abort(403)` debería ser `throw new HttpException(403)` porque `abort()` no detiene la ejecución del middleware en Laravel 10+

No se retorna la respuesta de `$next($request)`. Debe ser `return $next($request);` — sin el return, la response se pierde y el cliente recibe respuesta vacía

¿Cómo funciona el Container de DI en Symfony y qué son los services tagged?

El DI Container gestiona creación y ciclo de vida de servicios, resolviendo dependencias automáticamente. Los tagged services agrupan servicios bajo una etiqueta para procesarlos en batch (ej: event listeners, voters, twig extensions)

El container solo sirve para instanciar clases manualmente mediante el patrón factory, sin resolución automática de dependencias ni inyección

Los tags en Symfony son exclusivamente para documentación y no tienen ningún efecto funcional en la resolución de servicios del container

Symfony no tiene un DI container propio; utiliza un service locator pattern donde cada clase busca sus dependencias en un registro global

Este código asyncio tiene race condition: `counter = 0 async def increment(): global counter temp = counter await asyncio.sleep(0) counter = temp + 1`. Con 100 tareas concurrentes, ¿qué pasa?

counter será siempre exactamente 100 porque asyncio ejecuta las coroutines secuencialmente y el `await` no permite intercalación de tareas

counter será menor que 100: el `await` permite que otras coroutines lean el mismo valor de `temp` antes de incrementar, perdiendo incrementos. Solución: `asyncio.Lock()` para proteger la sección crítica

asyncio no puede tener race conditions porque es single-threaded y el GIL de Python previene cualquier acceso concurrente a variables compartidas

El error es simplemente usar `global` en vez de pasar counter como parámetro; cambiando a parámetro se elimina la race condition automáticamente

Endpoint FastAPI devuelve 422: `@app.post("/users") async def create(user: UserCreate): ...` con body `{"name": "John", "age": "twenty"}` y `class UserCreate(BaseModel): name: str; age: int`. ¿Por qué?

El endpoint debería usar el método PUT en vez de POST para creación de recursos, ya que POST no soporta validación automática de body en FastAPI

Falta la keyword `async` en la definición de la función; sin ella FastAPI no puede procesar el request body de forma asíncrona

`BaseModel` de Pydantic no soporta el tipo `int` como field type; solo acepta `str`, `float` y `bool` como tipos primitivos válidos

Pydantic no puede convertir el string "twenty" a `int` — la validación de tipos falla automáticamente y FastAPI retorna 422 Unprocessable Entity con detalles del error de validación

¿Cuándo usar asyncio vs threading vs multiprocessing en Python?

Siempre usar asyncio porque es superior en absolutamente todos los casos de uso, independientemente de si la tarea es I/O-bound o CPU-bound

threading es siempre mejor que asyncio para operaciones I/O porque los threads del OS son más eficientes que las coroutines para manejar conexiones

asyncio: I/O-bound con muchas conexiones concurrentes (HTTP, DB). threading: I/O-bound con librerías sin soporte async. multiprocessing: CPU-bound (cálculos pesados) porque evita el GIL ejecutando en procesos separados

multiprocessing solo funciona en sistemas Linux y no es compatible con Windows ni macOS debido a limitaciones del fork() en esos sistemas operativos

Memory leak en Express: `app.post("/upload", (req, res) => { const data = req.body; processLater(() => { analyze(data); }); res.send("ok"); });` donde `processLater` guarda en array global. ¿Por qué?

El closure en `processLater` retiene referencia al objeto `data` (potencialmente grande) indefinidamente en el array global. Sin limpieza, la memoria crece con cada request. Solución: extraer solo campos necesarios y limpiar tras procesar

El problema es acceder a `req.body` directamente sin clonar el objeto primero; Express reutiliza el buffer del body entre requests causando corrupción

Express no soporta request bodies grandes (>1MB) y el intento de procesarlos causa fragmentación de memoria en el heap de V8

El memory leak es causado por `res.send("ok")` que mantiene la conexión HTTP abierta indefinidamente sin cerrar el socket del cliente

¿Cómo escalar una aplicación Node.js?

Solo aumentar la RAM del servidor es suficiente para escalar cualquier aplicación Node.js independientemente del tipo de carga o número de conexiones

Node.js es inherentemente no-escalable y la única solución viable es migrar a Java o Go para aplicaciones con alta concurrencia

Solo usar PM2 como process manager es suficiente para manejar cualquier nivel de carga sin necesidad de arquitectura adicional

Cluster mode (múltiples procesos en todos los cores), Worker Threads (tareas CPU-bound), escalado horizontal (instancias tras load balancer), y message queues (Redis/RabbitMQ) para tareas pesadas asíncronas

Deadlock en Go: `func main() { ch := make(chan int); ch <- 42; fmt.Println(<-ch) }`. ¿Por qué?

Falta llamar a `close(ch)` antes de intentar leer del channel, ya que los channels no-cerrados no permiten operaciones de lectura en Go

Channel unbuffered: `ch <- 42` bloquea hasta que alguien lea, pero el lector está en la línea siguiente que nunca se alcanza. Solución: goroutine para enviar o channel buffered `make(chan int, 1)`

El problema es usar `fmt.Println` con el resultado de una lectura de channel; se necesita asignar a una variable primero antes de imprimir

La sintaxis `make(chan int)` es inválida en Go; se requiere especificar siempre el tamaño del buffer como segundo argumento obligatorio

¿Cuál es el manejo idiomático de errores en Go y cuándo usar panic vs error returns?

Siempre usar panic para todos los errores porque es más conciso y permite centralizar el manejo de errores con recover en un solo punto

Go utiliza try/catch como Java y C# para el manejo de excepciones; panic/recover es un mecanismo legacy que no debería usarse

Retorno explícito de errores (`val, err := fn(); if err != nil {...}`). `panic` solo para errores irrecuperables del programador. Errores se envuelven con `fmt.Errorf("context: %w", err)` para mantener la cadena

Error returns son un patrón obsoleto que será eliminado en Go 2; el equipo de Go ha confirmado la adopción de excepciones tradicionales

Esta query es lenta: `SELECT * FROM orders WHERE total > (SELECT AVG(total) FROM orders WHERE user_id = orders.user_id)`. ¿Cómo optimizarla?

Añadir `LIMIT 1000` a la query principal es suficiente para resolver el problema de rendimiento sin necesidad de reestructurar la consulta

La subquery correlacionada se ejecuta por cada fila. Solución: convertir a JOIN con CTE (`WITH avg_totals AS (SELECT user_id, AVG(total) as avg FROM orders GROUP BY user_id)`) + índice en (user_id, total)

El único problema es usar `SELECT *`; cambiando a columnas específicas se resuelve completamente el problema de rendimiento de la query

Cambiar a una base de datos NoSQL como MongoDB resuelve automáticamente este tipo de problemas de rendimiento en queries analíticas

¿Cuáles son los niveles de aislamiento de transacciones SQL y qué problemas previene cada uno?

Solo existen dos niveles: READ y WRITE, que controlan si una transacción puede leer o escribir datos respectivamente

Los niveles de aislamiento son un concepto exclusivo de bases de datos NoSQL y no aplican a sistemas relacionales como PostgreSQL o MySQL

Todas las bases de datos SQL usan SERIALIZABLE por defecto porque es el único nivel que garantiza consistencia completa sin configuración

READ UNCOMMITTED (permite dirty reads), READ COMMITTED (previene dirty reads), REPEATABLE READ (previene non-repeatable reads), SERIALIZABLE (previene phantom reads). Mayor aislamiento = menor concurrencia

¿Cómo modelar una relación many-to-many en MongoDB? ¿Embedding vs referencing?

Embedding: cuando los datos relacionados se leen juntos y son pocos (ej: tags en un post). Referencing: cuando los datos son grandes, se actualizan independientemente, o la relación es unbounded (ej: usuarios en un grupo). Híbrido: embeber un subset y referenciar el resto

Siempre usar embedding sin excepción porque MongoDB no soporta referencias entre documentos ni operaciones de lookup entre colecciones

Siempre usar referencing exactamente como en SQL relacional, creando una colección intermedia de join para todas las relaciones many-to-many

MongoDB no puede modelar relaciones many-to-many de ninguna forma; para este tipo de relaciones se necesita obligatoriamente una base de datos relacional

Race condition en cache-aside con Redis: Thread A lee cache (miss), Thread B actualiza DB e invalida cache, Thread A escribe dato viejo en cache. ¿Cómo prevenirlo?

La única solución es no usar cache en absoluto; cualquier sistema de caching introduce inevitablemente inconsistencias que no pueden ser mitigadas

Redis no tiene race conditions porque todas las operaciones son atómicas y single-threaded, haciendo imposible la escritura de datos obsoletos

Usar TTL corto como safety net, write-through en vez de cache-aside para datos críticos, o versioning/timestamps en las entradas de cache para detectar escrituras obsoletas. También se puede usar distributed lock para operaciones de escritura

Usar `MULTI/EXEC` (transacciones Redis) en absolutamente todas las operaciones de lectura para garantizar aislamiento completo entre threads

¿Cómo implementar un rate limiter distribuido con Redis? ¿Sliding window vs token bucket?

Solo usar `INCR` con `EXPIRE` en una key simple es suficiente para implementar rate limiting preciso sin necesidad de algoritmos más complejos

Rate limiting no se puede implementar de forma distribuida; cada instancia del servidor debe mantener su propio contador local independiente

Solo se necesita un middleware en el servidor web (nginx/Apache) y no es necesario involucrar Redis ni ningún almacén externo para rate limiting

Sliding window log: almacena timestamps de requests en sorted set, cuenta en ventana deslizante (preciso pero más memoria). Token bucket: contador que se recarga periódicamente (eficiente, permite bursts). Implementación con Lua scripts para atomicidad

¿Cuáles son las ventajas y desventajas de Event Sourcing vs CRUD tradicional?

Event Sourcing es siempre superior a CRUD en todos los escenarios posibles y debería ser el patrón por defecto para cualquier aplicación nueva

Event Sourcing: audit trail completo, reconstrucción de estado, temporal queries, event replay. Desventajas: complejidad, eventual consistency, storage creciente, queries complejas requieren projections. CRUD: simple, queries directas, pero pierde historial

CRUD tradicional no soporta transacciones de base de datos y por eso Event Sourcing es necesario para garantizar consistencia de datos

Event Sourcing es un patrón exclusivamente diseñado para aplicaciones de chat y mensajería en tiempo real, sin aplicabilidad en otros dominios

¿Cómo implementar una Saga distribuida para un flujo de pago? ¿Orquestación vs coreografía?

Las sagas no son necesarias cuando se usan microservicios porque cada servicio gestiona su propia transacción de forma completamente independiente

Siempre usar transacciones distribuidas (2PC - Two Phase Commit) en vez de sagas porque 2PC garantiza consistencia fuerte sin compensaciones

Orquestación: un coordinador central dirige los pasos (más control, single point of failure). Coreografía: cada servicio reacciona a eventos (desacoplado, pero difícil de rastrear). Para pagos: reservar stock → cobrar → confirmar, con compensaciones inversas si falla

Las sagas solo funcionan con bases de datos SQL y no son compatibles con sistemas que usan bases de datos NoSQL o event stores

Del OWASP Top 10, ¿cuáles son 5 vulnerabilidades comunes y cómo prevenirlas?

OWASP Top 10 solo aplica a aplicaciones desarrolladas en Java y no es relevante para otros lenguajes de programación o frameworks modernos

Solo SQL Injection sigue siendo relevante en 2024; las demás vulnerabilidades del OWASP Top 10 han sido eliminadas por los frameworks modernos

El OWASP Top 10 se resuelve completamente solo con un WAF (Web Application Firewall) sin necesidad de cambios en el código de la aplicación

Injection (prepared statements), Broken Auth (MFA, session management), XSS (output encoding, CSP), SSRF (whitelist URLs, validar inputs), Security Misconfiguration (hardening, headers seguros). Cada una requiere defensa en profundidad

¿Cuál es la diferencia entre unit, integration y e2e tests, y qué es la pirámide de testing?

Unit: función aislada (rápidos, muchos). Integration: interacción entre módulos/servicios (DB real, APIs). E2E: flujo completo del usuario. Pirámide: muchos unit (base), menos integration (medio), pocos e2e (cima). Más arriba = más lento pero más confianza

Solo e2e tests son necesarios porque cubren todo el stack completo y hacen redundantes tanto los unit tests como los integration tests

La pirámide de testing indica que hay que tener más e2e tests que unit tests porque los e2e proporcionan mayor confianza en el sistema completo

Integration tests reemplazan completamente a los unit tests porque testean la misma funcionalidad con mayor cobertura y contexto real

Este código tiene un bottleneck: `async function exportUsers() { const users = await db.query("SELECT * FROM users"); return JSON.stringify(users); }` con 10K+ registros. ¿Cuál es el problema?

El problema es usar `async/await` en vez de callbacks tradicionales; los callbacks son más eficientes para operaciones de base de datos grandes

Carga todos los registros en memoria de golpe y la serialización JSON bloquea el event loop. Solución: usar streaming (cursor/pagination de DB + JSON streaming por chunks o librerías como `JSONStream`) para procesar incrementalmente

`JSON.stringify` es siempre instantáneo independientemente del tamaño del input porque V8 lo ejecuta en un thread separado automáticamente

El problema es exclusivamente la query SQL sin WHERE clause; añadiendo un filtro se resuelve el bottleneck sin necesidad de cambiar la arquitectura

Desafío de código

Diseña e implementa un sistema de notificaciones en tiempo real que combine REST API con WebSockets, cola de mensajes con Redis pub/sub, y retry con backoff exponencial. Incluye tests de integración y documenta las decisiones arquitectónicas.

Requisitos

REST API para gestionar suscripciones y consultar historial de notificaciones
WebSocket server para entrega en tiempo real con reconexión automática
Cola de mensajes con Redis pub/sub para desacoplar productores y consumidores
Retry con backoff exponencial para entregas fallidas (max 5 intentos)
Tests de integración que cubran el flujo completo (envío → cola → entrega)

Ejemplos

Entrada:

POST /api/notifications { "userId": "123", "type": "order_update", "payload": { "orderId": "456", "status": "shipped" } }

Salida: Notificación encolada en Redis, entregada via WebSocket al usuario conectado, con confirmación de recepción

Tecnologías aceptadas

Node.js + Socket.io/ws
Python + FastAPI + websockets
Go + gorilla/websocket
TypeScript + NestJS
Elixir + Phoenix Channels

Envío de solución

URL del repositorio * Plataformas soportadas: GitHub, GitLab, Bitbucket Introduce una URL válida de repositorio (https://github.com, gitlab.com o bitbucket.org seguido de usuario/repositorio)