Evaluación Técnica — Nivel 2

5 ejercicios · 75–85 minutos · Etapa final · Incidentes reales, base de datos y comunicación

Antes de empezar

Llegaste a la etapa final. Acá vas a corregir código con bugs, razonar un incidente intermitente, tocar la base de datos de producción y comunicar como lo harías en el día a día.
Corre en entorno controlado: mientras esté activa no se puede copiar/pegar, no hay clic derecho, y si salís de la pestaña queda registrado.
No busques las respuestas afuera. Queremos ver cómo razonás vos ante un problema real.
El primer ejercicio se auto-evalúa en el navegador (botón “Probar”). Podés correrlo las veces que quieras.
El cronómetro arranca al apretar Comenzar y podés enviar antes de que termine.

⚠️ La integridad de la sesión se mide automáticamente (salidas de pestaña, intentos de copiar). No afecta tu nota técnica, pero queda en el informe del evaluador.

85:00 Ejercicio 1 de 5 Integridad — desenfoques 0 · bloqueos 0 · resize 0

Ejercicio 1 de 5 · Bug-fixing (auto-evaluable)

Dos bugs en el cálculo de SLA

Esta función debería devolver cuántos tickets están en riesgo: consumieron ≥ 80% de su SLA pero todavía no lo rompieron (< 100%). Tiene dos bugs (uno salta a la vista, el otro es de borde). Corregilos en el editor y probá.

// SLA en horas según prioridad -> P1:4, P2:8, P3:24, P4:48.
// Si la prioridad no está en la tabla, tratarla como P3 (24h).
// Debe contar los tickets EN RIESGO: consumieron >= 80% del SLA pero < 100%.
// Tiene DOS bugs: encontralos y corregilos.
function ticketsEnRiesgo(tickets) {
  const sla = { P1: 4, P2: 8, P3: 24, P4: 48 };
  let n = 0;
  for (let i = 1; i < tickets.length; i++) {
    const t = tickets[i];
    const limite = sla[t.prioridad];
    const pct = t.horasTranscurridas / limite * 100;
    if (pct >= 80 && pct < 100) n++;
  }
  return n;
}

Pensá en los dos extremos: ¿estás mirando TODOS los tickets de la lista? ¿qué devuelve la tabla para una prioridad que no existe?

Ejercicio 2 de 5 · Análisis de causa raíz

El bug intermitente

Varios usuarios reportan que, al guardar un presupuesto, a veces se pierde el último capítulo. Pasa ~1 de cada 20 veces y se nota más en horas pico. No tenés forma de reproducirlo a voluntad.

Listá tus hipótesis ordenadas por probabilidad y, para cada una, qué revisarías para confirmarla o descartarla.

"1 de cada 20" y "peor en horas pico" no son decorado: orientan hacia ciertas causas y descartan otras.

Ejercicio 3 de 5 · Base de datos en producción

Limpiar duplicados sin romper nada

Un bug ya corregido dejó presupuestos duplicados en producción. Son duplicados reales cuando tienen el mismo client_name y el mismo name, creados con menos de 5 minutos de diferencia. Hay que conservar el más antiguo de cada grupo y borrar el resto.

budgets ( id, client_name, name, created_at )

a) Escribí el DELETE (o la secuencia de SQL) que borra solo esos duplicados conservando el más antiguo.

b) Antes de ejecutar eso en producción, ¿qué hacés? Enumerá tus recaudos en orden.

El punto (b) pesa tanto como el (a): borrar en prod sin red es la diferencia entre un N2 y un N3.

Ejercicio 4 de 5 · Priorización

Cuatro tickets, al mismo tiempo

Entran los cuatro a la vez y estás solo. Ordenalos (1 = primero) y justificá brevemente cada decisión:

A. Un cliente mediano no puede facturar: el módulo de facturación les tira error a todos sus usuarios.
B. El cliente más grande (VIP) está molesto porque un botón cambió de color y "no le gusta".
C. Un usuario reporta que al exportar un reporte los decimales salen mal; mientras tanto puede corregirlos a mano.
D. Un cliente nuevo pide una mejora: "estaría bueno que el listado se pudiera filtrar por fecha".

"Molesto y VIP" no es lo mismo que "urgente". Separar impacto real de volumen de queja es el punto.

Ejercicio 5 de 5 · Comunicación

Escalar hacia adentro y hacia afuera

Confirmaste que el problema de un cliente molesto es un bug real que requiere un fix del equipo de Desarrollo y va a tardar ~48 horas. Escribí los dos mensajes:

a) Al equipo de Desarrollo, para escalar el bug con la información que necesitan para arrancar.

b) Al cliente, avisándole los tiempos sin perderlo.

Revisá tus respuestas antes de enviar. Una vez enviada, no se modifica.

Evaluación pausada

Evaluación Técnica — Nivel 2

Antes de empezar

Dos bugs en el cálculo de SLA

El bug intermitente

Limpiar duplicados sin romper nada

Cuatro tickets, al mismo tiempo

Escalar hacia adentro y hacia afuera

¡Listo! Evaluación enviada

Resumen de la sesión

Respuestas · para el evaluador