~/pcn $ iniciando_
enunciados + leetcode
Enunciados como los de una entrevista real para resolver por tu cuenta, con el tiempo que te darían, y problemas de LeetCode recomendados para cada tecnología y seniority. Nada se corrige acá: resolvelo en tu editor, en voz alta, y marcá lo que ya practicaste.
Se viene una promoción y el negocio espera hasta 300 usuarios concurrentes en el checkout. Cada usuario hace: POST /api/login con email y contraseña (devuelve un token), GET /api/products, POST /api/cart con 1 a 3 productos al azar y POST /api/orders. El SLO acordado es p95 menor a 800 ms en POST /api/orders, p95 menor a 400 ms en el resto y menos de 1% de errores.
Escribí un script de k6 que modele ese escenario con un ramp-up a 300 VUs en 5 minutos, 10 minutos sostenidos y un ramp-down de 2 minutos, con thresholds que hagan fallar la corrida si no se cumple el SLO. Si no tenés un servicio contra el que correrlo, alcanza con que el script sea correcto y lo valides contra un mock local.
# requisitos
stages o un scenario ramping-vus con los tiempos pedidos.SharedArray para que cada VU use credenciales distintas.check sobre status y contenido de cada respuesta y sleep con think time realista.# si te sobra tiempo, te van a preguntar
Te suman a un equipo con una app web (login, catálogo, carrito, checkout y un panel de admin) que hoy tiene 400 tests E2E de Cypress en un único repo, tardan 50 minutos, fallan de forma intermitente cerca del 8% de las corridas y nadie confía en ellos. No hay tests de API y los datos de prueba dependen de una base de staging compartida.
Armá en código la base de una suite nueva con Playwright o Cypress que muestre cómo resolverías esto: estructura de carpetas, configuración por entorno, fixtures para autenticación y datos, un helper para crear datos por API, dos tests E2E de ejemplo y dos tests de API de ejemplo. Acompañalo con un README corto con las decisiones tomadas.
# requisitos
@smoke y @regression).# si te sobra tiempo, te van a preguntar
El endpoint GET /api/transactions?cursor=<c>&limit=<n> devuelve { "items": [...], "nextCursor": string | null } ordenado por createdAt descendente, con limit entre 1 y 100 (por defecto 20). El endpoint POST /api/transactions acepta un header Idempotency-Key: si se repite la misma key con el mismo body, debe devolver la misma transacción sin duplicarla; si se repite con otro body, debe responder 422.
Escribí una suite automatizada que valide la paginación y la idempotencia, incluyendo qué pasa cuando se crean transacciones nuevas mientras alguien está paginando. Usá la herramienta de API testing que prefieras y un mock propio si no tenés el servicio.
# requisitos
limit (0, 1, 100, 101) y un cursor inválido.Idempotency-Key y verificar que se crea una sola transacción.# si te sobra tiempo, te van a preguntar