¿Qué respuesta senior darías si te preguntan “TypeScript evita fallos”?

Detrás de "¿Qué respuesta senior darías si te preguntan “TypeScript evita fallos”?" suele haber una tensión real en TypeScript entre escenarios reales y comunicación.

En un nivel intermedio interesa ver si colocas bien los límites de "Qué respuesta senior darías si te preguntan “TypeScript evita fallos”", justificas por qué eliges ese patrón y explicas cómo lo mantendrías legible para el equipo.

Qué evalúa el entrevistador

• Si distingues qué parte de "Qué respuesta senior darías si te preguntan “TypeScript evita fallos”" pertenece a escenarios reales y cuál debería resolverse en comunicación.
• Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
• Si usas el sistema de tipos para capturar invariantes y reducir ambigüedad en lugar de acumular tipos ceremoniales.

Respuesta sólida

• Empieza por la forma del dato y por los invariantes que no quieres volver a revisar en cada llamada.
• Usa tipos que ayuden a modelar estados válidos e inválidos en vez de esconderlos tras uniones demasiado amplias o casts oportunistas.
• Completa la respuesta con el puente entre tipado y runtime: validación de entrada, narrowing o conversión explícita cuando haga falta.

Compromisos y errores comunes

• Llenar el código de casts o tipos demasiado permisivos anula justo la garantía que intentabas conseguir.
• Modelar estados imposibles como si fueran normales desplaza el error a producción o a la lógica de presentación.

Ejemplo de código

No se trata de memorizar esta implementación, sino de enseñar cómo ordenar el flujo de escenarios reales en TypeScript sin mezclar responsabilidades ni perder de vista comunicación.

type LoadingState<T> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; message: string };

function isSuccess<T>(state: LoadingState<T>): state is { status: "success"; data: T } {
  return state.status === "success";
}

const state: LoadingState<number> = { status: "success", data: 42 };
if (isSuccess(state)) console.log(state.data);

En entrevista yo usaría un ejemplo de este tamaño para "Qué respuesta senior darías si te preguntan “TypeScript evita fallos”": suficiente para demostrar criterio y lo bastante pequeño como para discutir riesgos y variantes sin perderse.

Ejemplo o caso real

La forma seria de aterrizar "Qué respuesta senior darías si te preguntan “TypeScript evita fallos”" es escoger un caso con usuarios reales, un criterio de éxito visible y una superficie de rollback pequeña. Eso obliga a hablar de impacto, no de dogmas, y evita convertir escenarios reales en arquitectura ornamental.

Frase corta de entrevista

Si una decisión de TypeScript no mejora claridad, coste de cambio o fiabilidad, probablemente aún no merece existir.