Las preguntas de entrevista de TypeScript que más hacen las empresas en 2026, con respuestas claras y ejemplos de código reales. De nivel básico a senior.
Jesús Blanco
Autor
TypeScript se convirtió en el lenguaje con más contribuidores activos de GitHub en agosto de 2025, con 2.6 millones de devs colaborando mensualmente. Hoy en día no es una ventaja competitiva tenerlo en el CV, es un requisito en la mayoría de empresas de producto tecnológico.
Si tienes una entrevista técnica próximamente, esta guía cubre las preguntas que realmente hacen los equipos de contratación, desde las más básicas hasta las que distinguen a un candidato senior de uno junior. Cada respuesta incluye el contexto que los entrevistadores esperan escuchar, no solo la definición del manual.
Las preguntas están organizadas en tres niveles:
Al final encontraras una sección de errores comunes que los entrevistadores observan activamente, y las FAQs mas buscadas sobre entrevistas de TypeScript.
TypeScript es un superconjunto de JavaScript desarrollado por Microsoft que agrega tipado estatico opcional al lenguaje. Todo codigo JavaScript valido es tambien TypeScript valido, lo que permite adoptarlo gradualmente en proyectos existentes.
La diferencia clave es cuándo se detectan los errores. JavaScript los muestra en tiempo de ejecucion, cuando el usuario ya está usando el producto. TypeScript los detecta en tiempo de compilacion, mientras el desarrollador escribe el codigo.
// JavaScript: este error aparece solo cuando ejecutas el codigo
function sumar(a, b) {
return a + b;
}
sumar("5", 10); // Resultado: "510" en lugar de 15. Sin advertencia.
// TypeScript: el error aparece antes de ejecutar
function sumar(a: number, b: number): number {
return a + b;
}
sumar("5", 10); // Error en el editor: Argument of type 'string' is not assignable to parameter of type 'number'
Lo que el entrevistador quiere escuchar: que entiendas la diferencia entre errores en compilacion vs runtime, y que puedas dar un ejemplo concreto de por que eso importa en proyectos grandes.
El tipado estatico significa que los tipos de las variables se verifican antes de ejecutar el programa. En equipos de mas de dos personas, esto tiene un impacto directo en la productividad.
Cuando defines los tipos de las funciones y objetos, tu editor puede mostrarte exactamente que propiedades tiene un objeto, que argumentos espera una funcion y que devuelve. Esto reduce la necesidad de leer documentacion o buscar el codigo fuente para entender como usar algo.
// Sin tipos: tienes que revisar donde se crea "usuario" para saber que tiene
function mostrarPerfil(usuario) {
console.log(usuario.nombre); // Existe esta propiedad?
}
// Con tipos: el editor te lo dice directamente
interface Usuario {
id: number;
nombre: string;
email: string;
rol: "admin" | "editor" | "viewer";
}
function mostrarPerfil(usuario: Usuario) {
console.log(usuario.nombre); // El editor muestra todas las propiedades disponibles
}
interface y type?Esta es una de las preguntas mas frecuentes en entrevistas de TypeScript para todos los niveles. La respuesta corta: ambas sirven para describir la forma de un objeto, pero con diferencias importantes.
Las interface son extensibles y pueden declararse multiples veces para agregar propiedades. Los type son mas flexibles porque pueden representar cualquier tipo, no solo objetos.
// Interface: se puede extender y re-declarar
interface Vehiculo {
marca: string;
modelo: string;
}
interface Vehiculo {
year: number; // Valido: TypeScript fusiona ambas declaraciones
}
interface Carro extends Vehiculo {
puertas: number;
}
// Type: no se puede re-declarar, pero es mas flexible
type ID = string | number; // Tipos union, imposible con interface
type Punto = { x: number; y: number };
type Punto3D = Punto & { z: number }; // Intersection type
Regla practica que los entrevistadores aprecian escuchar: usa interface para objetos que otros pueden extender (como APIs publicas de librerias) y type para todo lo demas, especialmente cuando necesitas union types o tipos calculados.
any, unknown y never?Estos tres tipos confunden mucho a los juniors. Aqui la diferencia concreta:
any desactiva el sistema de tipos completamente. Es la salida de emergencia que no deberias usar en codigo de produccion porque elimina todas las ventajas de TypeScript.unknown es la alternativa segura a any. Puedes asignarle cualquier valor, pero TypeScript te obliga a verificar el tipo antes de usarlo. Es lo correcto cuando recibes datos de una fuente externa como una API.never representa algo que nunca deberia ocurrir. Aparece en funciones que siempre lanzan errores o en ramas de codigo que son imposibles de alcanzar.
// any: peligroso, sin verificacion de tipos
let dato: any = "hola";
dato.metodoQueNoExiste(); // TypeScript no avisa. El error aparece en produccion.
// unknown: seguro, te obliga a verificar
let respuestaApi: unknown = fetch("/api/datos");
respuestaApi.toUpperCase(); // Error: Object is of type 'unknown'
if (typeof respuestaApi === "string") {
respuestaApi.toUpperCase(); // Ahora si funciona
}
// never: para casos imposibles
function procesarRol(rol: "admin" | "editor") {
if (rol === "admin") return "Panel de admin";
if (rol === "editor") return "Panel de editor";
const casoImposible: never = rol; // TypeScript verifica que cubrimos todos los casos
return casoImposible;
}
TypeScript puede deducir el tipo de una variable sin que lo declares explicitamente. Esto reduce el codigo repetitivo sin perder seguridad de tipos.
// No necesitas escribir el tipo, TypeScript lo deduce
let nombre = "Carlos"; // TypeScript infiere: string
let edad = 28; // TypeScript infiere: number
let activo = true; // TypeScript infiere: boolean
const numeros = [1, 2, 3]; // TypeScript infiere: number[]
// En funciones, TypeScript infiere el tipo de retorno
function duplicar(n: number) {
return n * 2; // TypeScript infiere que el retorno es number
}
Cuándo declarar explicitamente: cuando una funcion es parte de una API publica, cuando el tipo inferido no es suficientemente especifico, o cuando quieres documentar la intencion de una variable.
Los genericos permiten escribir funciones y clases que funcionan con multiples tipos sin perder la seguridad de tipos. Son uno de los temas mas evaluados en entrevistas de nivel intermedio y senior.
// Sin genericos: tienes que escribir una funcion por tipo, o usar any
function primerElemento(arr: number[]): number {
return arr[0];
}
// Funciona solo con numbers. Para strings necesitas otra funcion.
// Con genericos: una sola funcion para todos los tipos
function primerElemento(arr: T[]): T | undefined {
return arr[0];
}
const numero = primerElemento([1, 2, 3]); // TypeScript infiere: number | undefined
const texto = primerElemento(["a", "b", "c"]); // TypeScript infiere: string | undefined
// Genericos con restricciones
function obtenerPropiedad(objeto: T, clave: K): T[K] {
return objeto[clave];
}
const usuario = { nombre: "Ana", edad: 30 };
const nombre = obtenerPropiedad(usuario, "nombre"); // TypeScript sabe que es string
const edad = obtenerPropiedad(usuario, "edad"); // TypeScript sabe que es number
obtenerPropiedad(usuario, "email"); // Error: "email" no existe en el objeto
TypeScript incluye tipos de utilidad predefinidos que transforman tipos existentes. Son extremadamente comunes en codebases reales y los entrevistadores los preguntan para verificar experiencia practica.
interface Producto {
id: number;
nombre: string;
precio: number;
descripcion: string;
}
// Partial: hace todas las propiedades opcionales
// Util para funciones de actualizacion parcial
function actualizarProducto(id: number, cambios: Partial) {
// Puedes pasar solo las propiedades que quieres actualizar
}
// Required: hace todas las propiedades obligatorias
type ProductoCompleto = Required; // Ninguna puede ser undefined
// Pick: selecciona solo las propiedades que necesitas
type ResumenProducto = Pick;
// Omit: excluye propiedades especificas
type ProductoSinId = Omit; // Util para formularios de creacion
// Readonly: previene modificacion
type ProductoCongelado = Readonly;
// Record: crea un tipo de objeto con claves y valores especificos
type InventarioPorCategoria = Record;
// ReturnType: extrae el tipo de retorno de una funcion
function obtenerConfig() {
return { apiUrl: "https://api.fencode.dev", timeout: 5000 };
}
type Config = ReturnType; // { apiUrl: string; timeout: number }
Type narrowing es el proceso por el cual TypeScript reduce el tipo posible de una variable dentro de un bloque de codigo basandose en verificaciones.
type Respuesta = string | number | null;
function procesarRespuesta(valor: Respuesta) {
// En este punto TypeScript sabe que puede ser string, number o null
if (valor === null) {
console.log("Sin datos");
return;
}
// Aqui TypeScript sabe que valor es string | number (excluyo null)
if (typeof valor === "string") {
console.log(valor.toUpperCase()); // TypeScript sabe que es string
return;
}
// Aqui TypeScript sabe que valor es number
console.log(valor.toFixed(2));
}
// Discriminated unions: patron muy comun en entrevistas
type Exito = { tipo: "exito"; datos: string[] };
type Error = { tipo: "error"; mensaje: string };
type Resultado = Exito | Error;
function manejarResultado(resultado: Resultado) {
if (resultado.tipo === "exito") {
console.log(resultado.datos); // TypeScript sabe que es Exito
} else {
console.log(resultado.mensaje); // TypeScript sabe que es Error
}
}
Los decorators son funciones especiales que modifican el comportamiento de clases, metodos, propiedades o parametros. Son ampliamente usados en frameworks como Angular, NestJS y en sistemas de inyeccion de dependencias.
// Decorator de clase: se ejecuta cuando se define la clase
function Loggeable(constructor: Function) {
console.log(`Clase creada: ${constructor.name}`);
}
@Loggeable
class ServicioUsuarios {
obtenerTodos() {
return [];
}
}
// Output al cargar: "Clase creada: ServicioUsuarios"
// Decorator de metodo: muy comun en NestJS para rutas HTTP
function Deprecated(target: any, key: string, descriptor: PropertyDescriptor) {
const metodoOriginal = descriptor.value;
descriptor.value = function (...args: any[]) {
console.warn(`Advertencia: ${key} esta deprecado`);
return metodoOriginal.apply(this, args);
};
return descriptor;
}
class ApiController {
@Deprecated
obtenerDatosV1() {
return "datos v1";
}
}
null y undefined en TypeScript?Este es un area donde mucha gente comete errores en produccion. TypeScript tiene el flag strictNullChecks que cuando esta activo (recomendado) trata null y undefined como tipos separados.
// Con strictNullChecks activo en tsconfig.json
// MAL: puede fallar si usuario es null
function mostrarNombre(usuario: { nombre: string } | null) {
console.log(usuario.nombre); // Error: Object is possibly 'null'
}
// BIEN: verifica antes de acceder
function mostrarNombre(usuario: { nombre: string } | null) {
if (usuario === null) return "Anonimo";
console.log(usuario.nombre); // TypeScript sabe que no es null aqui
}
// Optional chaining: acceso seguro sin verificaciones expliciitas
const ciudad = usuario?.direccion?.ciudad; // undefined si cualquier parte es null/undefined
// Nullish coalescing: valor por defecto solo cuando es null/undefined
const nombre = usuario?.nombre ?? "Usuario Anonimo";
// Diferente a || que tambien reemplaza "", 0, false
Los conditional types permiten crear tipos que cambian segun condiciones, similar a un operador ternario pero para el sistema de tipos.
// Sintaxis: T extends U ? X : Y
type EsString = T extends string ? true : false;
type Prueba1 = EsString; // true
type Prueba2 = EsString; // false
type Prueba3 = EsString; // true (string literal extiende string)
// Caso de uso real: extraer el tipo de un array
type ElementoDeArray = T extends (infer Elemento)[] ? Elemento : never;
type MiArray = string[];
type Elemento = ElementoDeArray; // string
// Distribucion automatica sobre unions
type NoNullable = T extends null | undefined ? never : T;
type MiTipo = string | number | null | undefined;
type MiTipoLimpio = NoNullable; // string | number
Los mapped types crean nuevos tipos transformando cada propiedad de un tipo existente. Son la base de como funcionan Partial, Readonly y otros utility types internamente.
// Como TypeScript implementa Partial internamente
type MiPartial = {
[K in keyof T]?: T[K]; // Para cada propiedad K en T, hazla opcional
};
// Como TypeScript implementa Readonly internamente
type MiReadonly = {
readonly [K in keyof T]: T[K];
};
// Caso de uso practico: hacer todas las propiedades nullable
type Nullable = {
[K in keyof T]: T[K] | null;
};
interface Formulario {
nombre: string;
email: string;
telefono: string;
}
type FormularioInicial = Nullable;
// { nombre: string | null; email: string | null; telefono: string | null }
// Remapping de claves: cambiar los nombres de las propiedades
type Getters = {
[K in keyof T as `get${Capitalize}`]: () => T[K];
};
type GettersUsuario = Getters;
// { getNombre: () => string; getEdad: () => number }
Introducidos en TypeScript 4.1, permiten construir tipos de string usando interpolacion, similar a los template literals de JavaScript pero en el sistema de tipos.
type Direccion = "norte" | "sur" | "este" | "oeste";
type Movimiento = `mover-${Direccion}`;
// "mover-norte" | "mover-sur" | "mover-este" | "mover-oeste"
// Caso de uso real: tipado de eventos
type Entidad = "usuario" | "producto" | "orden";
type Accion = "crear" | "actualizar" | "eliminar";
type EventoSistema = `${Entidad}:${Accion}`;
// "usuario:crear" | "usuario:actualizar" | "usuario:eliminar" | "producto:crear" | ...
function emitirEvento(evento: EventoSistema, datos: unknown) {
console.log(evento, datos);
}
emitirEvento("usuario:crear", { nombre: "Ana" }); // Valido
emitirEvento("usuario:borrar", { nombre: "Ana" }); // Error: "borrar" no esta en Accion
// Combinacion con Mapped Types para APIs type-safe
type RutasApi = {
[K in EventoSistema]: (datos: unknown) => Promise;
};
Esta es una pregunta de diseño que hacen equipos senior para evaluar como piensas sobre type safety en sistemas reales.
// Patron comun para tipar respuestas de API
type RespuestaApi =
| { exito: true; datos: T; error: null }
| { exito: false; datos: null; error: string };
// Tipos para los endpoints especificos
interface Usuario {
id: string;
nombre: string;
email: string;
}
interface Paginacion {
items: T[];
total: number;
pagina: number;
porPagina: number;
}
// Funcion type-safe para llamadas a la API
async function llamarApi(
url: string,
opciones?: RequestInit
): Promise<RespuestaApi> {
try {
const respuesta = await fetch(url, opciones);
if (!respuesta.ok) {
return { exito: false, datos: null, error: respuesta.statusText };
}
const datos = await respuesta.json() as T;
return { exito: true, datos, error: null };
} catch (error) {
return {
exito: false,
datos: null,
error: error instanceof Error ? error.message : "Error desconocido",
};
}
}
// Uso
async function obtenerUsuarios() {
const resultado = await llamarApi<Paginacion>("/api/usuarios");
if (resultado.exito) {
resultado.datos.items.forEach((u) => console.log(u.nombre)); // Type-safe
} else {
console.error(resultado.error);
}
}
Usar any sin justificacion. Es la señal mas clara de que alguien no entiende el valor de TypeScript. Si necesitas flexibilidad, usa unknown y narrowing.
Confundir interface y type para casos donde uno es claramente mejor. No es que uno sea malo, es que hay contextos donde cada uno es la herramienta correcta.
No usar strictNullChecks. Un codebase sin esta opcion activa tiene una falsa sensacion de seguridad. En entrevistas, mencionar que siempre activas strict: true en tsconfig.json genera buena impresion.
Escribir tipos redundantes que TypeScript ya infiere. const nombre: string = "Ana" es redundante. El entrevistador sabe que no confias en el compilador o que no tienes experiencia real con el lenguaje.
No conocer los utility types basicos. Si en una entrevista escribes a mano lo que Partial, Pick u Omit hacen, el entrevistador sabe que no tienes experiencia en codebases reales de TypeScript.
Preparar una entrevista de TypeScript no es memorizar definiciones. Es entender por que el sistema de tipos existe, como usarlo para prevenir errores reales y como comunicar esas decisiones con claridad.
Los puntos que mas peso tienen en una entrevista no son los mas complejos. Son los basicos bien explicados, el conocimiento de los utility types en contextos reales y la capacidad de diseñar tipos que hagan el codigo mas facil de mantener.
Si quieres profundizar en como TypeScript se usa en proyectos reales con Next.js y APIs modernas, revisa nuestros articulos sobre MCP con TypeScript y AI agents desde cero.
Resolvemos las dudas específicas sobre este tema.
