Backend - Junior

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 PHP tiene una vulnerabilidad crítica: `$id = $_GET["id"]; $result = mysqli_query($conn, "SELECT * FROM users WHERE id = $id");`. ¿Cuál es el problema?

Falta cerrar la conexión con `mysqli_close($conn)` después de ejecutar la query, lo que causa memory leaks en conexiones persistentes del pool

El problema principal es usar la extensión `mysqli` en vez de PDO, que ofrece prepared statements nativos y abstracción de base de datos más segura

SQL Injection: el valor de `$_GET["id"]` se concatena directamente en la query sin sanitizar, permitiendo inyectar SQL arbitrario. Solución: usar prepared statements con `mysqli_prepare()` y `bind_param()`

Falta validar que `$conn` no sea null antes de ejecutar la query, lo que causaría un fatal error si la conexión al servidor de base de datos falló

¿Cuál es la diferencia entre `include`, `require`, `include_once` y `require_once` en PHP?

`require` lanza error fatal si el archivo no existe (detiene ejecución), `include` solo emite warning y continúa. Las variantes `_once` evitan incluir el mismo archivo múltiples veces previniendo redeclaraciones

No hay diferencia funcional entre ellas, son sinónimos mantenidos por retrocompatibilidad con versiones anteriores de PHP y se pueden usar indistintamente

`include` está diseñado para archivos CSS y assets estáticos mientras que `require` es exclusivamente para archivos PHP con lógica de negocio

`require_once` es significativamente más lento que `require` debido al tracking interno de archivos incluidos y no debería usarse en producción por rendimiento

Este código Python tiene un bug sutil: `def add_item(item, items=[]): items.append(item); return items`. Al llamar `add_item("a")` y luego `add_item("b")`, ¿qué retorna la segunda llamada?

Retorna `["b"]` porque Python crea una nueva lista vacía en cada invocación de la función cuando el argumento no se proporciona explícitamente

Lanza un TypeError porque no se puede usar una lista mutable como valor por defecto en la firma de una función en Python 3

Retorna `["a"]` y `["b"]` por separado ya que cada llamada a la función opera en un scope completamente independiente con su propia copia de la lista

`["a", "b"]` — porque el argumento por defecto mutable (`[]`) se comparte entre todas las llamadas a la función. Solución: usar `items=None` y `if items is None: items = []`

¿Cuál es la diferencia entre lista, tupla y diccionario en Python?

Son estructuras de datos idénticas con diferente sintaxis, mantenidas por retrocompatibilidad con versiones anteriores del lenguaje Python

Lista es mutable y ordenada (`[]`), tupla es inmutable y ordenada (`()`), diccionario es mutable con pares clave-valor (`{}`). Listas para colecciones modificables, tuplas para datos fijos, diccionarios para mapeos

Tupla es más rápida que lista en absolutamente todos los casos de uso porque el intérprete de Python optimiza las estructuras inmutables a nivel de bytecode

Diccionario mantiene orden de inserción solo en Python 2; en Python 3 los diccionarios son desordenados y se necesita OrderedDict para mantener el orden

Este endpoint en Node.js/Express no responde nunca: `app.get("/users", async (req, res, next) => { const users = getUsers(); res.json(users); });` donde `getUsers()` retorna una Promise. ¿Por qué?

El problema es usar `res.json()` en vez de `res.send()`, ya que `res.json()` no puede serializar objetos Promise y se queda en un estado pendiente indefinido

La keyword `async` no se puede usar en callbacks de rutas de Express porque el router no soporta funciones asíncronas como handlers de peticiones

Falta `await` antes de `getUsers()` — sin await, `users` es una Promise pendiente (no los datos reales), y si la Promise rechaza, el error no se captura y la request queda colgada

Falta llamar a `app.listen()` al final del archivo para que el servidor comience a escuchar conexiones entrantes en el puerto configurado

¿Cómo funciona el event loop de Node.js si es single-threaded?

Node.js utiliza múltiples threads internamente para absolutamente todas las operaciones, incluyendo la ejecución de JavaScript y el procesamiento de callbacks

Node.js no puede manejar múltiples requests simultáneamente; las procesa una por una en orden FIFO y cada request debe completarse antes de atender la siguiente

El event loop procesa callbacks en un solo thread, pero delega operaciones I/O (disco, red, DNS) a libuv que usa un thread pool. Esto permite manejar miles de conexiones concurrentes sin bloquear el thread principal

Single-threaded significa que Node.js solo puede procesar una request por segundo, lo que lo hace inadecuado para aplicaciones con alta concurrencia

Esta query SQL devuelve menos resultados de los esperados: `SELECT users.name, orders.total FROM users LEFT JOIN orders ON users.id = orders.user_id WHERE orders.total > 100`. ¿Por qué?

El `WHERE orders.total > 100` elimina las filas donde `orders.total` es NULL (usuarios sin pedidos), convirtiendo el LEFT JOIN en un INNER JOIN efectivo. Solución: mover la condición al `ON` o añadir `OR orders.total IS NULL`

La cláusula LEFT JOIN no es compatible con la cláusula WHERE en SQL estándar y produce comportamiento indefinido dependiendo del motor de base de datos utilizado

Debería usar RIGHT JOIN en vez de LEFT JOIN para obtener todos los usuarios, ya que LEFT JOIN solo retorna registros de la tabla derecha que tienen coincidencia

El problema es que falta un índice compuesto en `orders(user_id, total)`, lo que causa que el optimizador de queries descarte resultados por timeout de ejecución

¿Cuál es la diferencia entre `WHERE` y `HAVING` en SQL?

Son cláusulas completamente intercambiables que solo difieren en la posición sintáctica dentro de la query, sin ninguna diferencia funcional real

`HAVING` es más rápido que `WHERE` en todos los casos porque se ejecuta después de la indexación y aprovecha los índices de forma más eficiente

`WHERE` solo funciona con columnas numéricas y operadores de comparación, mientras que `HAVING` está diseñado exclusivamente para filtrar columnas de tipo texto

`WHERE` filtra filas individuales antes de la agrupación (no puede usar funciones de agregación). `HAVING` filtra grupos después del `GROUP BY` (puede usar COUNT, SUM, AVG, etc.)

¿Cuándo elegirías MongoDB sobre PostgreSQL y viceversa?

MongoDB: esquema flexible (catálogos de productos variables, logs, datos semi-estructurados), escalado horizontal nativo. PostgreSQL: relaciones complejas (e-commerce con inventario, finanzas), transacciones ACID, queries complejas con JOINs

MongoDB siempre es mejor para aplicaciones web modernas porque su modelo de documentos es más natural para APIs REST y elimina la necesidad de migraciones

PostgreSQL solo sirve para aplicaciones legacy y sistemas heredados; cualquier proyecto nuevo debería usar exclusivamente bases de datos NoSQL por rendimiento

MongoDB es una base de datos relacional con sintaxis JSON y PostgreSQL es NoSQL con soporte para documentos, por lo que sus casos de uso son invertidos

¿Para qué se usa Redis y qué estructuras de datos ofrece además de key-value simple?

Redis es exclusivamente un cache de key-value simple idéntico a Memcached, sin soporte para estructuras de datos complejas ni persistencia en disco

Redis es una base de datos relacional que opera completamente en memoria, con soporte para tablas, JOINs y transacciones SQL estándar

Redis solo almacena strings planos y no soporta ninguna otra estructura de datos; para estructuras complejas se necesita complementar con MongoDB

Redis es un almacén en memoria usado para cache, sesiones, colas y pub/sub. Ofrece: Strings, Hashes, Lists, Sets, Sorted Sets, Streams, y estructuras probabilísticas (HyperLogLog, Bloom filters)

¿Qué códigos HTTP corresponden a: recurso creado, validación fallida, no autorizado, y rate limit excedido?

200 OK, 400 Bad Request, 401 Unauthorized, 500 Internal Server Error — usando los códigos más genéricos disponibles para cada categoría de respuesta

201 Created, 422 Unprocessable Entity, 401 Unauthorized, 429 Too Many Requests — cada código comunica semánticamente la situación específica al cliente

200 OK, 404 Not Found, 403 Forbidden, 503 Service Unavailable — priorizando los códigos más comúnmente implementados en APIs REST modernas

201 Created, 500 Internal Server Error, 403 Forbidden, 408 Request Timeout — combinando códigos de éxito con errores de servidor para máxima compatibilidad

¿Cuál es la diferencia entre goroutines en Go y threads del sistema operativo?

Son exactamente lo mismo; goroutines es simplemente el nombre que Go utiliza para referirse a threads del sistema operativo sin ninguna diferencia de implementación

Los OS threads son más ligeros que las goroutines porque el kernel del sistema operativo está optimizado para gestionar concurrencia de forma más eficiente que un runtime

Las goroutines son green threads gestionados por el runtime de Go: pesan ~2KB de stack (vs ~1MB de un OS thread), se multiplexan sobre pocos OS threads (M:N scheduling), y su creación/cambio de contexto es mucho más barato

Las goroutines no pueden ejecutarse en paralelo real, solo concurrentemente en un único core; para paralelismo verdadero se necesitan OS threads nativos

Desafío de código

Desarrolla una API REST con autenticación JWT que gestione un CRUD completo de "proyectos". La API debe incluir validación de datos, manejo consistente de errores, y paginación en los endpoints de listado.

Requisitos

Autenticación con JWT (registro, login, protección de rutas)
CRUD completo de proyectos (crear, leer, actualizar, eliminar)
Validación de datos de entrada con mensajes de error claros
Paginación en el endpoint de listado (limit/offset o cursor)
Manejo consistente de errores con códigos HTTP apropiados

Ejemplos

Entrada: POST /api/projects { "name": "Mi Proyecto", "description": "Descripción" } con header Authorization: Bearer <token>

Salida: 201 Created { "id": "uuid", "name": "Mi Proyecto", "description": "Descripción", "createdAt": "2024-01-15T10:00:00Z" }

Entrada: GET /api/projects?page=1&limit=10 sin token

Salida: 401 Unauthorized { "error": "Token no proporcionado o inválido" }

Tecnologías aceptadas

Node.js + Express/Fastify
Python + FastAPI/Flask
PHP + Laravel/Symfony
Go + Gin/Echo
TypeScript + NestJS

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)