./live-coding

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.

# 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

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

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

01Casos de prueba para un formulario de registroQue apliques técnicas de diseño de pruebas de forma sistemática y no solo por intuición.30 min

Un formulario de registro tiene estos campos: nombre (obligatorio, entre 2 y 50 caracteres, solo letras y espacios), email (obligatorio, formato válido, único en el sistema), edad (obligatoria, entero entre 18 y 99) y contraseña (entre 8 y 64 caracteres, al menos una mayúscula y un número). El botón "Crear cuenta" se habilita solo si todos los campos son válidos.

Diseñá los casos de prueba usando partición de equivalencia y análisis de valores límite. Presentalos en una tabla con id, campo, técnica aplicada, dato de entrada, resultado esperado y prioridad.

# requisitos

-Identificar las clases válidas e inválidas de cada campo.
-Cubrir los valores límite de edad (17, 18, 99, 100) y de longitud de nombre y contraseña.
-Incluir al menos un caso de email duplicado y uno de formato inválido.
-Incluir casos del botón: deshabilitado con un campo inválido y habilitado con todos válidos.
-Asignar prioridad a cada caso y justificar cuáles correrías primero si tuvieras poco tiempo.

# si te sobra tiempo, te van a preguntar

-¿Qué casos agregarías pensando en seguridad, por ejemplo inyección o espacios al principio y al final?
-¿Cuáles de estos casos automatizarías primero y en qué nivel (unitario, API o UI)?
-¿Qué preguntas le harías al PO sobre requisitos que quedaron ambiguos?

02Bug report a partir de un escenarioQue comuniques un defecto de forma clara, reproducible y accionable para el equipo de desarrollo.30 min

Mientras probás un e-commerce en staging (versión 2.14.0, Chrome 128 en macOS), agregás dos remeras de 10.000 pesos cada una al carrito, aplicás el cupón VERANO20 y el total muestra 16.000. Después cambiás la cantidad de una remera a 3 y el total pasa a 40.000, sin descuento, aunque el cupón sigue apareciendo como aplicado. Si recargás la página, el total vuelve a mostrar el descuento correcto.

Escribí el bug report completo como lo cargarías en Jira o en la herramienta que uses.

# requisitos

-Título corto y específico que describa el síntoma, no la causa supuesta.
-Pasos para reproducir numerados, con datos concretos.
-Resultado actual y resultado esperado, con el cálculo del total esperado.
-Entorno, versión, severidad y prioridad, justificando por qué difieren si es el caso.
-Mencionar qué evidencia adjuntarías (captura, video, request de red) y qué variaciones probaste para acotar el bug.

# si te sobra tiempo, te van a preguntar

-¿Qué otras pruebas harías para saber si el problema es del frontend o del backend?
-¿Cómo cambiarías la severidad si esto pasara en producción durante una promoción?

03Automatizar un login con Cypress o PlaywrightQue escribas tests de UI estables desde el principio, con buenos selectores y sin esperas arbitrarias.45 min

La página /login tiene un input de email con data-testid="email", uno de contraseña con data-testid="password", un botón data-testid="submit" y un contenedor data-testid="error" que aparece con el texto "Credenciales inválidas" ante un login fallido. Si el login es exitoso, la app redirige a /dashboard y muestra un saludo data-testid="welcome" con el texto "Hola, Ana". El usuario válido es ana@example.com con contraseña Secreta123.

Escribí con Cypress o Playwright tres tests: login exitoso, contraseña incorrecta y email vacío (el botón queda deshabilitado). Podés practicar contra una página propia o un sitio de práctica que tenga un flujo similar.

# requisitos

-Usar los atributos data-testid como selectores y no clases CSS ni XPath frágiles.
-No usar esperas fijas como cy.wait(2000) o waitForTimeout; apoyarse en las aserciones con reintento del framework.
-Tomar las credenciales de un fixture o variables de entorno, no hardcodeadas en el test.
-Cada test es independiente y puede correr solo o en cualquier orden.
-Verificar tanto la URL como el contenido visible después del login.

# si te sobra tiempo, te van a preguntar

-¿Cómo evitarías repetir el login por la UI en todos los demás tests de la suite?
-¿Qué harías si el equipo de desarrollo no quiere agregar atributos data-testid?
-¿Cómo organizarías estos tests con un Page Object o algo equivalente?

# leetcode recomendado (Quality engineering · Junior)

EasyTwo SumEl problema más pedido en coding screens de SDET; entrena pasar de fuerza bruta a hash map.

EasyValid ParenthesesUso de stack con muchos casos de borde, ideal para mostrar que pensás como tester antes de codear.

EasyValid AnagramConteo de caracteres con hash map, un ejercicio de strings que aparece seguido en entrevistas de QA automation.

EasyReverse StringPractica dos punteros in place, el típico warm-up de manipulación de strings para roles de testing.

EasyFizz BuzzSimple, pero muy pedido para ver cómo estructurás condiciones y qué casos probarías.

EasyPalindrome NumberObliga a pensar en negativos y ceros finales, el tipo de casos de borde que se espera que detecte un QA.

enunciados + leetcode

# 1. tecnología

# 2. seniority

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

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

01Casos de prueba para un formulario de registroQue apliques técnicas de diseño de pruebas de forma sistemática y no solo por intuición.30 min

# requisitos

-Identificar las clases válidas e inválidas de cada campo.
-Cubrir los valores límite de edad (17, 18, 99, 100) y de longitud de nombre y contraseña.
-Incluir al menos un caso de email duplicado y uno de formato inválido.
-Incluir casos del botón: deshabilitado con un campo inválido y habilitado con todos válidos.
-Asignar prioridad a cada caso y justificar cuáles correrías primero si tuvieras poco tiempo.

# si te sobra tiempo, te van a preguntar

-¿Qué casos agregarías pensando en seguridad, por ejemplo inyección o espacios al principio y al final?
-¿Cuáles de estos casos automatizarías primero y en qué nivel (unitario, API o UI)?
-¿Qué preguntas le harías al PO sobre requisitos que quedaron ambiguos?

02Bug report a partir de un escenarioQue comuniques un defecto de forma clara, reproducible y accionable para el equipo de desarrollo.30 min

Escribí el bug report completo como lo cargarías en Jira o en la herramienta que uses.

# requisitos

-Título corto y específico que describa el síntoma, no la causa supuesta.
-Pasos para reproducir numerados, con datos concretos.
-Resultado actual y resultado esperado, con el cálculo del total esperado.
-Entorno, versión, severidad y prioridad, justificando por qué difieren si es el caso.
-Mencionar qué evidencia adjuntarías (captura, video, request de red) y qué variaciones probaste para acotar el bug.

# si te sobra tiempo, te van a preguntar

-¿Qué otras pruebas harías para saber si el problema es del frontend o del backend?
-¿Cómo cambiarías la severidad si esto pasara en producción durante una promoción?

03Automatizar un login con Cypress o PlaywrightQue escribas tests de UI estables desde el principio, con buenos selectores y sin esperas arbitrarias.45 min

# requisitos

-Usar los atributos data-testid como selectores y no clases CSS ni XPath frágiles.
-No usar esperas fijas como cy.wait(2000) o waitForTimeout; apoyarse en las aserciones con reintento del framework.
-Tomar las credenciales de un fixture o variables de entorno, no hardcodeadas en el test.
-Cada test es independiente y puede correr solo o en cualquier orden.
-Verificar tanto la URL como el contenido visible después del login.

# si te sobra tiempo, te van a preguntar

-¿Cómo evitarías repetir el login por la UI en todos los demás tests de la suite?
-¿Qué harías si el equipo de desarrollo no quiere agregar atributos data-testid?
-¿Cómo organizarías estos tests con un Page Object o algo equivalente?

# leetcode recomendado (Quality engineering · Junior)

EasyTwo SumEl problema más pedido en coding screens de SDET; entrena pasar de fuerza bruta a hash map.

EasyValid ParenthesesUso de stack con muchos casos de borde, ideal para mostrar que pensás como tester antes de codear.

EasyValid AnagramConteo de caracteres con hash map, un ejercicio de strings que aparece seguido en entrevistas de QA automation.

EasyReverse StringPractica dos punteros in place, el típico warm-up de manipulación de strings para roles de testing.

EasyFizz BuzzSimple, pero muy pedido para ver cómo estructurás condiciones y qué casos probarías.

EasyPalindrome NumberObliga a pensar en negativos y ceros finales, el tipo de casos de borde que se espera que detecte un QA.