Top 45 TypeScript Interview Questions

TypeScript is a typed superset of JavaScript created by Microsoft: every valid JavaScript file is also valid TypeScript, and TypeScript adds optional static types, interfaces, and compile-time checks on top. The TypeScript compiler (tsc) type-checks the code and then strips the types away, emitting plain JavaScript that runs anywhere JavaScript already runs. A common mistake is thinking TypeScript is a separate language that needs its own runtime - it has no runtime of its own at all, it only exists at build/compile time.

// person.ts
function greet(name: string): string {
  return `Hello, ${name}`;
}
// compiles down to plain JavaScript with no type annotations left

Type inference is TypeScript's ability to determine a variable's type automatically from its initial value, without an explicit annotation - for example, `let count = 0` is inferred as `number`. A common mistake is over-annotating every single variable out of habit, which adds noise; inference is reliable for local variables with initializers, and explicit annotations matter most at function boundaries where there is nothing to infer from.

let name = 'Ada'; // inferred as string
let scores = [1, 2, 3]; // inferred as number[]

`any` disables type checking entirely for that value - anything can be assigned to or from it with no compiler complaints. `unknown` also accepts any value, but the compiler refuses to let you call methods or access properties on it until you first narrow it to a more specific type via `typeof`, `instanceof`, or a custom type guard. A common mistake is defaulting to `any` for convenience, which quietly reintroduces the exact bugs TypeScript is meant to catch - unknown is the safer choice whenever the real type genuinely is not known ahead of time.

let value: unknown = 'hello';
// value.toUpperCase(); // Error until narrowed
if (typeof value === 'string') {
  value.toUpperCase(); // OK now
}

never represents a value that can never occur - a function that always throws an exception, or that loops forever and never returns control to its caller, has a return type of never. This differs from void, which does return (just without a meaningful value). A common mistake is confusing never with void; never is also useful in exhaustiveness checks, where an unreachable default branch of a switch is typed never to catch any missed union member at compile time.

function fail(message: string): never {
  throw new Error(message);
}

A tuple, such as `[string, number]`, fixes both the length and the type at each specific position, while an array type like `string[]` allows any number of elements, all of the same type. A common mistake is treating a tuple like a loosely-typed array and pushing extra elements onto it without realizing the compiler still enforces the original fixed shape at the declared positions. Tuples are ideal for small, fixed-shape structures like coordinate pairs or key/value pairs.

let point: [number, number] = [10, 20];
// point = [10, 20, 30]; // Error: too many elements

A numeric enum auto-increments values starting from 0 unless given explicit values, and supports reverse lookup from value to name. A string enum requires every member to have its own explicit string value and has no reverse lookup. A union of string literal types (e.g. `"PENDING" | "SHIPPED"`) generates no runtime object at all - it is purely a compile-time construct. A common mistake is defaulting to enum out of habit; many teams now prefer literal unions since they have zero runtime footprint and work more naturally with plain strings from JSON.

enum Status { Pending, Shipped } // numeric
enum Color { Red = 'RED', Blue = 'BLUE' } // string
type Role = 'admin' | 'editor'; // literal union, no runtime object

A const enum is fully inlined at every usage site during compilation, rather than generating a real runtime lookup object - every reference to a member is replaced with its literal value. This produces smaller and faster output, but it also means the enum cannot be iterated over at runtime and has no reverse lookup, since the object never actually exists in the compiled JavaScript. A common mistake is using a const enum across project boundaries with certain bundler/isolated-module configurations, where inlining behavior can be restricted or disallowed.

Both can describe the shape of an object, and for plain object shapes they are largely interchangeable. Interfaces can be extended with `extends` and merged via declaration merging (multiple interface declarations with the same name combine automatically), while type aliases can additionally name things interfaces cannot express directly, like unions, tuples, or primitive aliases. A common mistake is assuming one is strictly better than the other - most style guides recommend interface for object shapes that may be extended, and type for unions or more complex compositions.

interface User { id: number; name: string }
type Id = string | number; // only possible with type

It means objects satisfying that interface may omit the property entirely, and wherever it is read, its type includes `undefined` in addition to the declared type. A common mistake is forgetting to guard against the missing case before using the value, which under strict mode causes a compile error precisely because the type honestly reflects that the property might not be present.

interface Profile { name: string; age?: number }
const p: Profile = { name: 'Ada' }; // age omitted, that's fine

It allows a property to be assigned once (typically at object creation) but prevents reassignment afterward, enforced entirely at compile time - `readonly` has no effect on the emitted JavaScript, so it offers no runtime protection on its own. A common mistake is expecting readonly to deeply freeze an object; it only prevents reassigning the property itself, not mutating a nested object or array that property points to.

interface Point { readonly x: number }
const p: Point = { x: 5 };
// p.x = 10; // Error: cannot assign to readonly property

`interface B extends A` inherits every member from A and adds its own, and the compiler enforces that B satisfies both shapes together. Type aliases achieve a similar composition using intersections (`type B = A & { extra: string }`), which works for any type, not just interfaces. A common mistake is trying to extend two interfaces with conflicting property types, which produces a compile error - the practical behavior in that case is similar to how conflicting members in an intersection collapse to an unusable (often never) type for that property.

interface Animal { name: string }
interface Dog extends Animal { breed: string }
const d: Dog = { name: 'Rex', breed: 'Labrador' };

Declaration merging is the ability to declare the same interface name more than once, with TypeScript automatically combining all the declarations into a single merged interface containing every member from each declaration. Only interfaces support this - declaring the same type alias name twice is a compile error. A common mistake is relying on merging for regular application code, where it usually signals a naming collision bug; its main legitimate use is augmenting types from third-party libraries or global objects.

interface Window { myGlobal: string; }
// elsewhere:
interface Window { anotherGlobal: number; }
// Window now has both myGlobal and anotherGlobal

Yes - an interface can declare a call signature, such as `interface Comparator { (a: number, b: number): number }`, which describes a callable value rather than an object with named properties. A type alias can express the same thing more concisely as `type Comparator = (a: number, b: number) => number`. A common mistake is assuming interfaces are limited to object property shapes; they can describe function and constructor signatures too, though the type-alias arrow-function syntax is generally considered more readable for pure function types.

type Comparator = (a: number, b: number) => number;
const byValue: Comparator = (a, b) => a - b;

Each parameter gets an annotation after its name (`name: string`), and the return type follows the closing parenthesis of the parameter list (`): number`). TypeScript can often infer the return type from the function body, but writing it explicitly on public/exported functions documents intent and prevents an internal change from silently widening the contract for every caller. A common mistake is over-relying on inference for widely-used functions, where an explicit return type acts as a useful guardrail.

function add(a: number, b: number): number {
  return a + b;
}

An optional parameter (`age?: number`) may be omitted by the caller, and its type includes undefined when read inside the function. A default parameter (`age: number = 18`) may also be omitted, but instead of becoming undefined it takes on the given default value, so its type stays as declared without needing to include undefined. A common mistake is assuming they behave identically - checking `if (age)` behaves differently depending on which one you are dealing with, especially around falsy values like 0.

function greet(name: string, greeting: string = 'Hello'): string {
  return `${greeting}, ${name}`;
}
console.log(greet('Ada')); // 'Hello, Ada'