Top 60 TypeScript Interview Questions (2026)

TypeScript is a statically typed superset of JavaScript from Microsoft. You write JavaScript plus optional type annotations, the compiler checks them, and it emits plain JavaScript that runs anywhere.

You use it to catch type errors while you write instead of at runtime, and to get better editor tooling: autocomplete, inline docs, and safe refactoring across a large codebase. On small scripts the payoff is thin; on long-lived apps it's large.

TypeScript adds a static type layer on top of JavaScript and a compile step; JavaScript runs directly with no types. Every JavaScript file is already valid TypeScript, so the difference is what the compiler checks before your code ever runs.

At runtime they're the same: TypeScript compiles to JavaScript and the types disappear. So TypeScript's help is entirely at build time, in the editor and the compiler, not while the program executes.

The primitives are string, number, boolean, null, undefined, bigint, and symbol, plus the special types any, unknown, void, and never. You also have arrays (number[]), tuples, objects, and enums built on top.

TypeScript often infers these, so you don't annotate everything. You annotate function parameters, return types when they aren't obvious, and anything the compiler can't figure out on its own.

Type inference is the compiler working out a type you didn't write. let count = 0 is inferred as number, so you don't need let count: number = 0.

Inference keeps typed code from feeling verbose. The rule of thumb: let the compiler infer local variables and return types when they're obvious, and annotate function parameters and public boundaries where inference can't reach.

any switches type checking off for a value: you can call anything on it, assign anything to it, and the compiler stops complaining. It's an escape hatch for untyped code or quick migration.

It's discouraged because it's contagious and silent: an any spreads through everything it touches and hides the exact bugs TypeScript exists to catch. Reach for unknown instead when you truly don't know a type, because unknown forces you to check before using it.

Both accept any value, but they differ on what you can do next. With any, you can do anything with no checks. With unknown, you can't use the value until you narrow it to a specific type with a guard.

unknown is the type-safe replacement for any: it keeps the flexibility of accepting anything while forcing you to prove the type before you touch it.

Both name object shapes and can extend other types. The practical differences: interface supports declaration merging (declare it twice and the members combine), while a type alias can name anything, including unions, tuples, and primitives, which interfaces can't.

A common team rule is interfaces for object and class shapes that might get extended, and type for unions, intersections, and anything that isn't a plain object. For most everyday object shapes, either works.

A union type says a value is one of several types: string | number means it can be a string or a number. You build them with the vertical bar, and they're everywhere in real code (an id that might be a string or a number, a status that's one of a few strings).

Before you use a union safely, you narrow it: check which member you actually have with typeof, a property check, or a discriminant, and the compiler lets you use the narrowed type.

An intersection type combines several types into one that has all their members: A & B is a value that satisfies both A and B at once. Where a union is 'one of these', an intersection is 'all of these together'.

You use it to merge shapes, for example combining a base entity with timestamp fields, so the result must have every property from both sides.

A literal type is a type whose only value is one specific literal: the type "admin" allows only the string "admin", and 200 allows only the number 200. On their own they're rarely useful, but in a union they model a fixed set of allowed values.

This is how you get enum-like safety with plain strings: type Role = "admin" | "editor" | "viewer" rejects any other string at compile time.

An array holds any number of elements of one type: number[] or Array<number>. A tuple is a fixed-length array where each position has its own type: [string, number] is exactly a string then a number.

Use arrays for homogeneous lists that grow, and tuples for fixed records where position carries meaning, like a coordinate or a React useState pair.

An enum names a set of related constants: enum Status { Active, Inactive } gives you Status.Active. Numeric enums auto-number from 0; string enums assign explicit string values, which read better in logs and storage.

Enums exist at runtime as real objects, unlike most TypeScript types. Many teams prefer a union of string literals or an as-const object instead, because those add nothing to the compiled output. Knowing that trade-off is worth mentioning.

You annotate each parameter and, when it isn't obvious, the return type: function add(a: number, b: number): number. Optional parameters get a ?, and you can give defaults. The compiler checks callers pass the right types and use the return correctly.

You can also type a function as a value with a function-type signature, which is how you type callbacks and higher-order functions.

A ? after a property name or parameter makes it optional: { name: string; nickname?: string } means nickname may be missing. The compiler then types it as string | undefined, so you must handle the undefined case before using it.

Optional parameters must come after required ones. Default values are related but different: a default supplies a value when the argument is missing, so the parameter isn't undefined inside the function.

A type assertion tells the compiler to treat a value as a specific type using the as keyword: value as string. It has no runtime effect and does no conversion; it only overrides what the compiler inferred.

Use it sparingly, when you genuinely know more than the compiler (a DOM element you're sure is an input, JSON you've just validated). Overusing it is a way to silence real errors, so an assertion should feel like a rare, deliberate choice.

void is the return type of a function that returns nothing useful (a logger, an event handler). never is the type of something that never produces a value at all: a function that always throws or runs forever, or a branch that can't be reached.

The key contrast: void means 'returns, but with no meaningful value'; never means 'does not return'. never is also what an exhaustive switch narrows the default case to, which is how you get compile-time exhaustiveness checks.

readonly marks a property so it can only be set once, at construction, and never reassigned after. The compiler flags any later write. It's a compile-time guarantee only; nothing stops mutation at runtime.

There's also ReadonlyArray<T> (and readonly T[]) for arrays you don't want mutated, which removes push, pop, and index assignment from the type.

You run the compiler, tsc, which reads your .ts files and emits .js. tsconfig.json is the project's config file: it sets the target JavaScript version, module system, strictness flags, output folder, and which files to include.

In real projects a bundler (Vite, esbuild, webpack) or a runtime like ts-node usually handles compilation, but the settings still come from tsconfig.json. Knowing that strict lives here, and turning it on, is the single most impactful config choice.

TypeScript checks type compatibility by shape, not by name. If an object has all the properties a type requires, it's assignable to that type, even if it was never declared to implement it. This is structural typing.

It's why an object literal with the right fields fits an interface without any implements keyword, and why two differently named types with identical shapes are interchangeable. It differs from nominal typing in languages like Java, where the name has to match.

These three look similar and behave very differently. object means any non-primitive (arrays, functions, objects) but not string or number. The empty type {} means any value that isn't null or undefined, including primitives, which surprises people. unknown means any value at all, but you can't use it until you narrow it.

The takeaway: {} is not 'an empty object', it's 'anything non-nullish', so it's a poor choice when you mean a real object. Reach for object for non-primitives, a specific shape for known data, and unknown when the value is genuinely open.

Generics let you write a function, class, or type that works over many types while keeping the type relationship intact. A type parameter like <T> is a placeholder the caller fills in, so identity<T>(x: T): T returns exactly the type it received.

They replace any where you'd otherwise lose type safety. Without generics, a reusable container or utility either locks to one type or falls back to any and drops all checking. Generics keep both reuse and safety.

A constraint limits what a type parameter can be, using extends: <T extends { length: number }> means T must have a length property. Inside the function you can then safely use that property, which a bare T wouldn't allow.

Constraints are how you write generics that do something with the value instead of just passing it through. They keep the function reusable while guaranteeing the members you need exist.

Narrowing is the compiler refining a broad type to a more specific one based on the checks you write. Inside if (typeof x === "string"), the compiler knows x is a string in that block. This is control flow analysis: it tracks what must be true along each path.

The everyday narrowing tools are typeof for primitives, instanceof for classes, the in operator for properties, truthiness checks, and equality with a discriminant. Good narrowing is what lets you use unions safely without assertions.

A type guard is a function whose return type is a type predicate, value is Type. When it returns true, the compiler narrows the argument to that type for the rest of the block. It's how you package a reusable narrowing check.

Use it when the built-in checks (typeof, instanceof, in) aren't enough, for example validating that an unknown value matches a specific interface before you trust it.

A discriminated union is a union of object types that all share a common literal field, the discriminant, like kind: "circle" versus kind: "square". Switching on that field narrows to the exact member, so each branch has the right properties.

It's the go-to pattern for modeling state that can be one of several shapes: a request that's loading, loaded, or errored, or a shape that's a circle or a rectangle. Paired with a never default, it gives compile-time exhaustiveness.

The everyday set: Partial<T> (all properties optional), Required<T> (all required), Readonly<T> (all readonly), Pick<T, K> (keep some keys), Omit<T, K> (drop some keys), Record<K, V> (build a map type), and Exclude / Extract for filtering unions.

They save you from hand-writing derived shapes and keep them in sync with the source type. If User changes, Partial<User> and Omit<User, "id"> change with it, which is the whole point.

Both derive a new object type from an existing one by selecting keys. Pick<T, K> keeps only the keys you list; Omit<T, K> keeps everything except the keys you list. They're opposites, and you choose whichever names fewer keys.

They're common at boundaries: a create-user payload might Omit the server-generated id, and a summary view might Pick just the display fields.

keyof takes an object type and produces a union of its property names as literal types. keyof { a: 1; b: 2 } is "a" | "b". It turns the shape of a type into a set of valid keys you can constrain against.

It's the foundation for typed property access: a function that reads a key off an object can constrain the key parameter to keyof T, so the compiler rejects any key the object doesn't have.

In a type position, typeof takes a value and gives you its type. typeof config produces the type the compiler inferred for the config object, so you can reuse it without re-declaring the shape by hand.

This is different from JavaScript's runtime typeof, which returns a string. The type-level typeof is how you derive types from existing values, often combined with keyof and as const.

A mapped type builds a new type by transforming each property of an existing one, using the [K in keyof T] syntax. It's how the built-in utilities like Partial and Readonly are defined: iterate the keys, apply a modifier or a new value type.

You reach for a custom mapped type when the built-ins don't fit, for example making every property nullable, or turning a type of values into a type of getters.

A conditional type chooses between two types based on a relationship, using the T extends U ? X : Y form. It's a type-level if statement: if T is assignable to U, the type is X, otherwise Y.

They power the filtering utilities (Exclude, Extract, NonNullable) and let library authors compute a return type from an argument type. With infer inside the condition, you can also extract a piece of a type, like the element type of an array.

An index signature types an object whose keys you don't know in advance: { [key: string]: number } describes an object with any number of string keys, all mapping to numbers. It's how you type dictionaries and lookup maps.

The trade-off is that every access is typed as the value type, so the compiler can't warn you about a missing key. For a fixed set of keys, Record or a plain interface is safer; use an index signature only when keys are genuinely open-ended.

With strictNullChecks on, null and undefined are their own types and aren't assignable to other types unless you say so. A string can't secretly be null; if it might be, its type is string | null and the compiler forces you to handle the null case.

This is one of TypeScript's biggest bug-catching wins: it eliminates a whole class of 'cannot read property of undefined' crashes by making you narrow before you access. It's part of the strict flag family, and turning it on is worth mentioning as a first move in any project.

Optional chaining (?.) short-circuits a property access, method call, or index when the value before it is null or undefined, returning undefined instead of throwing. Nullish coalescing (??) supplies a fallback only when the left side is null or undefined.

The pair reads much cleaner than nested null checks. The subtlety with ?? is that it treats 0 and empty string as valid values, unlike ||, which falls through on any falsy value. That difference is a common interview follow-up.

You annotate class fields and methods like anywhere else, and TypeScript adds access modifiers: public (default), private (only inside the class), and protected (the class and subclasses). private is compile-time; the runtime # private fields enforce it at runtime too.

TypeScript also has a parameter-property shorthand: mark a constructor parameter public or private and it becomes a field automatically, which cuts boilerplate.

A class uses implements to promise it satisfies an interface's shape: class Repo implements Storage. The compiler then checks the class has every member the interface requires, with matching types.

This is a compile-time contract only; because TypeScript is structurally typed, code elsewhere accepts any object of the right shape whether or not it used implements. So implements is mainly a safety net that catches a missing method early, at the class definition.

An abstract class can't be instantiated directly; it's a base that defines some concrete methods and some abstract ones that subclasses must implement. Unlike an interface, it can carry implementation and state, not just a shape.

The rule of thumb: an interface describes a contract with no code, and a type can too; an abstract class is for sharing real implementation across subclasses while still forcing them to fill in specific methods.

TypeScript uses ES module syntax: export what a file exposes, import it elsewhere. A file with any import or export is a module with its own scope; a file with none is treated as a global script. Named exports and a default export both work, with named exports preferred for refactor-friendly tooling.

TypeScript adds import type for imports used only as types, which the compiler can drop from the output entirely. Knowing that keeps type-only imports from accidentally causing runtime side effects.

A declaration file describes the types of code without any implementation, using .d.ts. It's how you add TypeScript types to a plain JavaScript library, or how a compiled library ships types alongside its .js so consumers get checking and autocomplete.

For popular JavaScript libraries without built-in types, the community DefinitelyTyped project publishes @types packages you install. When you build a library, the compiler can emit .d.ts files automatically with the declaration flag.

You install TypeScript, generate a tsconfig, turn on strict mode, and wire up a build or run step. In practice most people scaffold with a tool (Vite, a framework CLI) that does this, but being able to describe the manual steps shows you understand what those tools automate.

The step that matters most is strict: true in tsconfig, because it turns on the checks that make TypeScript worth using. Skipping it leaves you with typed JavaScript that still lets nulls and implicit anys through.

Types are erased during compilation: the emitted JavaScript has no interfaces, no generics, no type annotations. So you can't check typeof someInterface, and you can't branch on a generic parameter at runtime, because none of that exists once the code runs.

The practical consequence: anything crossing a runtime boundary (API responses, user input, JSON) needs real runtime validation, with a library like Zod or a hand-written guard, not just a type annotation. Types describe what should be true; they don't enforce it against the outside world.

Variance is how subtyping on parts relates to subtyping on the whole. TypeScript is covariant on most positions (an array of Dog is usable where an array of Animal is expected) and contravariant on function parameters under strict function types (a function taking Animal is assignable where one taking Dog is expected, because it handles more).

The practical gotcha is that arrays and method parameters are treated bivariantly for convenience, which is technically unsound. Naming that trade-off, and that strictFunctionTypes tightens plain function-type parameters, is the senior-level answer.

infer declares a type variable inside a conditional type's extends clause and captures a piece of the type being matched. T extends Promise<infer U> ? U : T pulls the resolved type out of a Promise. It's pattern matching on types.

It's the mechanism behind built-ins like ReturnType and Parameters, and behind any library that derives a type from another. Being able to write ReturnType from scratch with infer is a common production signal.

Template literal types build string literal types by interpolating other types, using template-string syntax at the type level: type Event = `on${Capitalize<string>}`. They let you compute precise string types instead of falling back to plain string.

They shine for typed string patterns: route paths, CSS units, event names, or a builder that turns keys into getter names. Combined with mapped types and key remapping, they enable surprisingly exact APIs.

as const tells the compiler to infer the narrowest, most literal, deeply readonly type for a value. An array becomes a readonly tuple of literals instead of a widened mutable array, and object properties become readonly literal types.

It's the lightweight alternative to enums and the way to derive a union from a value: as const on an array of strings, then typeof arr[number], gives you the string-literal union with zero runtime cost.

You add a default branch that assigns the value to a never variable. If you've handled every member of a discriminated union, the value is narrowed to never there and it compiles. Add a new member without handling it, and the assignment fails, so the compiler points you at the missing case.

This turns 'I forgot to handle the new status' from a runtime bug into a compile error, which is one of the strongest reasons to model state as discriminated unions.

A decorator is a function attached with @ to a class, method, accessor, property, or parameter, letting you observe or modify it at definition time. Frameworks like Angular and NestJS use them heavily for dependency injection, routing, and validation metadata.

The honest note: decorators went through an experimental phase (the experimentalDecorators flag) and the standardized version landed later, with some behavioral differences. Knowing there are two decorator eras, and which one a codebase uses, is what separates surface familiarity from real experience.

Declaration merging is TypeScript combining multiple declarations with the same name into one. Two interfaces with the same name merge their members; a namespace can merge with a class or function to add static-style members. It's why you can augment an existing interface.

Its main real-world use is module augmentation: adding a property to an existing library's type (extending Express's Request, or Window) from your own code without touching the library. That capability is unique to interfaces, one reason they're not fully replaceable by type aliases.

You add a runtime validation layer at every boundary where data enters from outside your control: API responses, form input, environment variables, message queues. A schema library like Zod, Valibot, or io-ts both validates at runtime and infers the static type, so the type and the check stay in one source of truth.

The anti-pattern to name is asserting the shape with as: response as User tells the compiler to trust malformed data, and the crash surfaces deep in the code instead of at the edge. Validate, then trust.

You chain keyof and indexed access types across type parameters, constraining each key to the keys of the value at the previous level. Each parameter narrows the next, so the compiler rejects any invalid path and infers the exact return type.

This is the kind of question that checks whether you can compose the type system's primitives (generics, keyof, indexed access, constraints) into something practical, not just recite them individually.

TypeScript trades some soundness for practicality. Known unsound spots: type assertions and any bypass checking entirely, array bounds aren't checked (arr[10] is typed as the element type even when it's undefined at runtime), bivariant method parameters, and object mutation through aliases can violate a narrowed type.

The senior point is that this is a design choice, not a bug: full soundness would reject too much real JavaScript. Knowing the holes tells you where to add runtime checks and where to distrust the green checkmark.

It makes indexed access include undefined in the result type. Without it, arr[i] on a number[] is typed number even though an out-of-range index gives undefined at runtime. With it, arr[i] is number | undefined, so the compiler forces you to handle the missing case.

It closes one of the array-bounds soundness holes. It adds friction (more narrowing at access sites), so teams weigh it, but for correctness-sensitive code it catches real bugs the default misses.

Incrementally, not all at once. Turn on allowJs so JS and TS coexist, rename files module by module, loose settings, and tighten flags (noImplicitAny, then strict) as you go comes first. Type the boundaries first (public APIs, data models) because that's where types pay off fastest, and lean on @types packages for dependencies.

The failure mode to name is a big-bang rewrite that produces thousands of errors and stalls. Gradual migration with CI enforcing no-new-untyped-code is how real teams do it; the compiler's per-file opt-in exists for exactly this.

Generics express a relationship that holds across many types with one signature: the return type is a function of the input type. Overloads list several distinct concrete signatures for the same function name, which fits when the input-output pairings don't follow a single rule.

Prefer generics when one type variable captures the pattern; reach for overloads when the valid argument combinations are a small fixed set that a generic can't express cleanly. Overloads also read better in editor tooltips for those fixed cases.

satisfies checks that a value conforms to a type without widening the value's inferred type. You get validation against the type plus the precise literal inference, which a plain type annotation would flatten and which as would unsafely override.

The difference from as is safety: as forces a type onto a value and can hide errors, while satisfies verifies the value fits and keeps the narrow inferred type. It's the right tool for config objects where you want both the check and the exact keys.

An async function's return type is Promise<T>, where T is the resolved value; you annotate the resolved type and the Promise wrapper is implied. Awaiting a Promise<T> gives you a T. For error handling you type nothing special, because rejections aren't in the type; a Promise doesn't carry its rejection type.

That last point is the interview depth: TypeScript can't type what a Promise rejects with, so error handling relies on runtime checks. Some teams model fallible operations as a result union (a discriminated union of ok and error) to make failure visible in the type.

A branded type simulates nominal typing on top of TypeScript's structural system by intersecting a base type with a unique tag: type UserId = string & { readonly brand: unique symbol }. The tag has no runtime presence; it just makes two structurally identical types (a UserId and a plain string) incompatible.

You use them to stop mixing up values that share a representation but not a meaning: a UserId and an OrderId are both strings, and branding makes passing one where the other is expected a compile error. It's how you buy nominal safety without a nominal type system.

Measure first with the compiler's diagnostics (extendedDiagnostics and generateTrace) to find where time goes, usually type checking, not emit. Common culprits: very large union or conditional types that explode combinatorially, deep recursive types, and a project that recompiles everything instead of using project references and incremental builds.

Fixes in order: enable incremental and project references to build in units, simplify or cap the pathological types, and split a monolithic tsconfig. the check is that you measure before optimizing and know the type checker is usually the cost, not the JavaScript emit.

Both are static type checkers that erase to JavaScript, and both cover similar ground: annotations, generics, unions, inference. TypeScript pulled ahead on ecosystem: broad editor support, the DefinitelyTyped type library, first-class framework integration, and Microsoft's sustained investment, while Flow's tooling and community narrowed.

For The production-ready answer, the honest framing is that the language-feature gap was never the deciding factor; tooling, types-for-dependencies availability, and momentum were. That's a useful lesson about how developer tools actually win.

Clarify the surface first (which endpoints, static or dynamic routes, shared error shape), then model it with generics: a request method parameterized on the response type, a Record or template-literal type mapping routes to their payload and response, and runtime validation (a schema per endpoint) so the inferred types actually match what arrives.

Close on the boundary discipline: the client's return types should come from the same schemas that validate at runtime, so there's one source of truth. Structuring the answer surface, generic signature, route-to-type map, runtime validation is what the question is really scoring, more than any single type trick.