~/pcn $ iniciando_

programaConNosotros

Iniciar sesiónCrear cuenta
  • programaConNosotrosprogramaConNosotrosComunidad · desde 2020
  • Inicio
  • Feed
Actividades
  • Eventos
  • Conversaciones
  • Charlas
  • Podcast
  • Desarrollo
Recursos
  • Cursos
  • Lectura
  • Videos
  • Especialidades
  • Herramientas
  • Proyectos
  • Entrevistas
Comunidad
  • Historia
  • Miembros
  • Logros
  • Galería
  • Setups
  • Partners
  • Changelog
SoporteFeedback

~/entrevistas/live-coding

enunciados + leetcode

[simulador][guías][live coding]

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.

# 1. tecnología

[ ]Frontend · React.jsweb, hooks, Next.js[ ]Frontend · iOSSwift, SwiftUI, UIKit[ ]Frontend · AndroidKotlin, Jetpack Compose[ ]Frontend · React NativeExpo, iOS y Android[ ]Backend · Node.jsExpress, NestJS[ ]Backend · PythonDjango, FastAPI[ ]Backend · JavaSpring Boot[ ]Backend · .NETC#, ASP.NET Core[ ]AI engineeringconstruir agentes de IA[ ]Agentic engineeringdesarrollar con agentes[x]Quality engineeringtesting manual y automatizado

# 2. seniority

[ ]Junior[x]Semi-senior[ ]Senior

# ejercicios (resolvelos por tu cuenta, con el tiempo que darían en la entrevista)

01Flujo E2E de login y checkoutQue diseñes una suite E2E mantenible, rápida y determinística, controlando red, sesión y datos.60 min

Una tienda tiene este flujo: login en /login, listado en /products con tarjetas data-testid="product-card" que contienen un botón "Agregar", un carrito en /cart con data-testid="cart-total" y un checkout en /checkout con campos de dirección y un botón "Confirmar compra". La confirmación muestra data-testid="order-id". La API de productos es GET /api/products y la de órdenes es POST /api/orders.

Automatizá con Cypress o Playwright el flujo completo de comprar dos productos y verificar que la orden se crea con el total correcto. Agregá un segundo test donde POST /api/orders responde 500 (interceptado) y verificá que la UI muestra un mensaje de error sin perder el carrito.

# requisitos

  • -Hacer el login por API o con sesión guardada (cy.session o storageState) y no por la UI en cada test.
  • -Usar fixtures para los datos de productos y la dirección.
  • -Esperar las requests relevantes con cy.intercept y alias, o page.waitForResponse, en lugar de sleeps.
  • -Verificar el body de la request a /api/orders además de lo que muestra la UI.
  • -Encapsular las acciones de cada página en Page Objects o helpers reutilizables.
  • -Dejar el estado limpio para que los tests se puedan correr en paralelo.

# si te sobra tiempo, te van a preguntar

  • -¿Qué parte de este flujo cubrirías con tests de API en vez de E2E y por qué?
  • -¿Cómo generarías datos de prueba únicos para evitar colisiones entre corridas paralelas?
  • -¿Cómo lo correrías en CI y qué artefactos guardarías cuando falla?
02Tests de API para un endpoint de usuariosQue pruebes APIs de forma completa: contrato, códigos de error, efectos y autorización.45 min

El endpoint POST /api/users recibe { "name": string, "email": string, "role": "admin" | "viewer" }, requiere el header Authorization: Bearer <token> y responde 201 con { "id": string, "name", "email", "role", "createdAt" }. Responde 400 si falta un campo o el email es inválido, 401 sin token, 403 si el token no es de un admin y 409 si el email ya existe. GET /api/users/:id devuelve el usuario creado o 404.

Escribí la suite de tests de API con la herramienta que prefieras (Playwright request, Cypress cy.request, Supertest, Postman con Newman o REST Assured). Si no tenés el servicio, podés levantar un mock con json-server o MSW que cumpla el contrato.

# requisitos

  • -Cubrir cada código de respuesta documentado con al menos un test.
  • -Validar el schema de la respuesta 201, no solo el status.
  • -Verificar el efecto: después de crear, el GET devuelve el mismo usuario.
  • -Generar emails únicos por corrida y limpiar los datos creados.
  • -Manejar los tokens de admin y viewer sin hardcodearlos en los tests.

# si te sobra tiempo, te van a preguntar

  • -¿Qué casos de seguridad agregarías, como que un viewer no pueda crear un admin?
  • -¿Cómo detectarías que el contrato de la API cambió sin que nadie avise?
  • -¿Qué diferencia hay entre estos tests y un contract test con Pact?
03Arreglar un test flakyQue diagnostiques las causas reales de un test inestable (timing, selectores y datos) y no las tapes con sleeps o reintentos.30 min

Este test de Playwright falla cerca de una de cada cinco corridas en CI: await page.goto("/orders"); await page.click("text=Filtrar"); await page.waitForTimeout(1000); const rows = await page.$$(".table tr"); expect(rows.length).toBe(5);. La tabla se carga desde GET /api/orders?status=open, que tarda entre 300 ms y 2 s, y mientras carga muestra un spinner. La suite comparte una base de datos con otros tests que también crean órdenes.

Identificá todas las causas posibles de flakiness y reescribí el test para que sea estable. Si usás Cypress, adaptá el mismo escenario.

# requisitos

  • -Eliminar waitForTimeout y esperar la respuesta de la API o el estado de la UI.
  • -Usar locators con aserciones que reintentan, como expect(locator).toHaveCount(5), en lugar de $$ con conteo inmediato.
  • -Reemplazar el selector por texto y clase por uno más robusto (rol accesible o data-testid).
  • -Resolver la dependencia de datos compartidos: crear los datos propios del test o interceptar la respuesta.
  • -Explicar cada causa encontrada y cómo la ataca el cambio.

# si te sobra tiempo, te van a preguntar

  • -¿Cómo confirmarías que el test quedó estable antes de mergearlo?
  • -¿Qué política de reintentos en CI te parece razonable y cuándo esconde problemas reales?
  • -¿Cómo harías visible en el equipo cuáles tests son flaky?

# leetcode recomendado (Quality engineering · Semi-senior)

EasyContains DuplicateUso básico de sets, muy común para validar unicidad de datos en scripts de automatización.
EasyValid PalindromeCombina normalización de strings y dos punteros, un clásico en screens de SDET.
EasyRoman to IntegerParseo con reglas y excepciones, bueno para practicar derivar casos de prueba desde una especificación.
EasyMove ZeroesManipulación de arrays in place manteniendo el orden, frecuente en entrevistas de automatización.
MediumGroup AnagramsAgrupar con claves calculadas en un hash map, útil para clasificar resultados o logs en herramientas de testing.
MediumLongest Substring Without Repeating CharactersEl sliding window más pedido; es el Medium de strings que más aparece en screens de SDET.
$ progreso --live-codingQuality engineering · Semi-senior

ejercicios0/3

leetcode0/6

$ cat guias/live-coding

Cómo encarar un live coding: el método para resolver en voz alta, complejidad, los patrones más frecuentes y cómo practicar.

leer la guía de live coding