30 TypeScript Interview Questions: From Basics to Advanced

The readonly modifier is a compile-time construct in TypeScript. Assigning to a readonly property triggers:

Error: TS2540: Cannot assign to 'x' because it is a read-only property.

Key points:

• It does not affect runtime behavior
• No JavaScript error is thrown unless additional runtime immutability (e.g., Object.freeze) is applied
• It's purely for type-checking

📖 Readonly properties (TypeScript Handbook)

extends in generic constraints sets an upper bound: T must be assignable to the specified type.

Example:

function logLength<T extends string>(value: T): void {
  console.log(value.length); // ✅ Safe to access .length
}

logLength("hello"); // ✅ OK
logLength(42); // ❌ Error: number doesn't extend string

Valid types for T:

• string
• 'hello' (literal type)
• string & { length: number }

Invalid: number, boolean, etc.

This enables safe access to shared properties.

📖 Generic Constraints (TypeScript Handbook)

Declaration files (.d.ts) contain only type information — no executable code.

Purpose:

• Enable type checking for libraries without built-in TypeScript support
• Provide autocompletion and IntelliSense in editors
• Describe the shape of JavaScript modules

Key characteristics:

• Not emitted as .js files
• Have no runtime impact
• Used by TypeScript compiler and IDEs

📖 Declaration Files (TypeScript Handbook)

declare is used in ambient declarations to inform TypeScript that a variable exists at runtime without generating JavaScript code.

Common use cases:

• External scripts or global scope variables
• Libraries loaded via <script> tags
• Global constants in .d.ts files

Example:

declare const API_KEY: string;
// TypeScript knows API_KEY exists, but no JS is emitted

Key points:

• Has no runtime effect
• Purely for type-checking
• Commonly seen in .d.ts files

📖 Declaration Files (TypeScript Handbook)

The type annotation string[] means "array whose elements are all of type string".

What happens:

• TypeScript enforces this at compile time
• Calling .push(42) violates the constraint because 42 is not assignable to string
• The error occurs during type checking, not at runtime

Important:

• push() is fully supported on string[]
• The array is mutable (not readonly) by default
• Only the element type is restricted

📖 Array Types (TypeScript Handbook)

Rest parameters must be typed as an array:

// ✅ Correct
function sum(...nums: number[]): number {
  return nums.reduce((a, b) => a + b, 0);
}

// ❌ Incorrect
function sum(...nums: number): number { ... }

Valid options:

• ...nums: number[] (idiomatic, preferred)
• ...nums: Array<number> (equivalent)

Invalid:

• ...nums: number (not an array type)
• [...number[]] (tuple rest syntax, not for standalone rest parameters)

📖 Rest Parameters (TypeScript Handbook)

Key difference: literal types vs primitive types

let a = "hello":

• TypeScript infers the literal type "hello" (with const it stays literal; with let, it widens to string)
• With let, "hello" is widened to string on reassignment analysis

let b: string:

• Type is string (any string value)
• Can be reassigned to any string

let c: "hello":

• Type is the literal type "hello" (only this exact value)
• Can only be "hello", nothing else

Example:

let wide: string = "hello";
wide = "world"; // ✅ OK

let narrow: "hello" = "hello";
narrow = "world"; // ❌ Error: Type '"world"' is not assignable to type '"hello"'

Why it matters:

• Literal types enable precise type constraints
• Essential for discriminated unions
• Powers type-safe enums and configuration objects

📖 Literal Types (TypeScript Handbook)

Although the function correctly checks typeof val === 'number', it returns boolean, not a type predicate.

Correct type guard:

function isNumber(val: any): val is number {
  return typeof val === 'number';
}

Why it matters:

• Without val is number, TypeScript won't narrow val's type in calling code
• The function works at runtime but provides no compile-time type safety

📖 Type Predicates (TypeScript Handbook)

Answer: unknown

unknown is the type-safe counterpart to any:

• Represents a value whose type is truly unknown
• TypeScript requires type narrowing before accessing properties
• Prevents accidental misuse and catches errors at compile time

Example:

const data: unknown = JSON.parse(jsonString);

// ❌ Error: Object is of type 'unknown'
console.log(data.name);

// ✅ OK: Narrow first
if (typeof data === 'object' && data !== null && 'name' in data) {
  console.log((data as { name: string }).name);
}

Why not other options:

• any disables type checking entirely
• Object is too vague and doesn't prevent unsafe access
• Record<string, unknown> is useful after narrowing to an object

📖 Unknown Type (TypeScript Handbook)

Correct syntax:

interface Square {
  side: number;
}

interface ColorSquare extends Square {
  color: string;
}

Key points:

• extends is used to inherit members from one or more base interfaces
• inherits is not a valid TypeScript keyword
• implements is used by classes to satisfy an interface, not for interface extension

Note: While intersection types (&) can achieve similar structural results, they are not interface extension and don't support declaration merging.

📖 Extending Interfaces (TypeScript Handbook)

Partial<Type> constructs a type where all properties of Type are marked as optional.

Example:

interface User {
  name: string;
  age: number;
  email: string;
}

type PartialUser = Partial<User>;
// Equivalent to:
// {
//   name?: string;
//   age?: number;
//   email?: string;
// }

Use cases:

• Creating update or patch objects
• Optional configuration objects
• Partial form data

📖 Partial (TypeScript Handbook)

A barrel file (typically index.ts) re-exports key members from sibling modules.

Before barrel file:

import { A } from './utils/a';
import { B } from './utils/b';
import { C } from './utils/c';

After barrel file (utils/index.ts):

import { A, B, C } from './utils';

Benefits:

• Improves API surface control
• Reduces import path complexity
• Provides cleaner public API

📖 TypeScript Module Patterns

Answer: string

Tuple destructuring preserves element types:

• name is inferred as string
• salary is inferred as number

Example:

let record: [string, number] = ["Alice", 75000];
let [name, salary] = record;

name = true; // ❌ Error: Type 'boolean' is not assignable to type 'string'

Key point: Destructuring does not widen or erase types.

📖 Tuple Types (TypeScript Handbook)

The return type annotation appears after the parameter list and before the function body, separated by a colon.

Correct syntax:

function greet(name: string): string {
  return `Hello ${name}`;
}

// Arrow function
const greet = (name: string): string => `Hello ${name}`;

Key points:

• Enforces that the function returns a value compatible with the declared type
• JSDoc comments can provide hints but do not enforce types like native annotations

📖 Function Types (TypeScript Handbook)

TypeScript uses control flow analysis to narrow union types.

What happens:

• Initial type: string | number
• After typeof value === "string": type narrows to string
• In the else branch: type narrows to number (the remaining member)

Key points:

• TypeScript tracks type information through control flow
• Each branch sees only the narrowed type
• No explicit type assertions required

Other narrowing techniques:

// in operator — object unions
if ("swim" in pet) { /* Fish */ }

// Discriminated unions
type Result =
  | { status: "success"; data: string }
  | { status: "error"; message: string };

if (result.status === "success") {
  result.data; // string
}

// Type predicates
function isString(x: unknown): x is string {
  return typeof x === "string";
}

📖 Narrowing (TypeScript Handbook)

Key difference: call-site requirements

function f(x?: string):

f(); // ✅ Valid - argument is truly optional
f("hello"); // ✅ Valid
f(undefined); // ✅ Valid

function f(x: string | undefined):

f(); // ❌ Error - parameter is required
f("hello"); // ✅ Valid
f(undefined); // ✅ Valid - must explicitly pass undefined

Important notes:

• Both accept undefined as a value
• Only ? changes call-site requirements
• Neither permits null unless explicitly added to the union
• strictNullChecks affects how undefined/null are treated in assignments, not parameter optionality

📖 Optional Parameters (TypeScript Handbook)

TypeScript applies excess property checking to object literals assigned to typed variables.

What happens:

• The literal must not contain properties not present in the target type
• This helps catch typos and unintended properties

Important distinction:

// Object literal - checked strictly
let pt: { x: number; y: number } = { x: 5, y: 15, z: 30 }; // ❌ Error

// Variable assignment - excess properties allowed
let point3D = { x: 5, y: 15, z: 30 };
pt = point3D; // ✅ OK - structural typing

Why: Object literals are checked strictly to catch mistakes, while variables follow structural typing rules.

📖 Excess Property Checks (TypeScript Handbook)

Use typeof for primitive types:

function process(value: string | number) {
  if (typeof value === 'string') {
    console.log(value.toUpperCase()); // ✅ value is string
  } else {
    console.log(value.toFixed(2)); // ✅ value is number
  }
}

Use in for object types:

interface Fish { swim(): void; }
interface Bird { fly(): void; }

function move(animal: Fish | Bird) {
  if ('swim' in animal) {
    animal.swim(); // ✅ animal is Fish
  } else {
    animal.fly(); // ✅ animal is Bird
  }
}

Key difference:

• typeof distinguishes primitive types (string, number, boolean, etc.)
• in distinguishes object types by presence of a property
• Using in on primitives causes a compile-time error

📖 typeof Type Guards (TypeScript Handbook)

Challenge: Many npm packages lack bundled type definitions.

Solutions (in order of preference):

1. DefinitelyTyped (most common):

   npm install --save-dev @types/lodash
   

2. Custom declaration files:

   // my-declarations.d.ts
   declare module 'some-library' {
     export function doSomething(): void;
   }
   

3. Inline type assertions (last resort):

   import lib from 'some-library';
   const typedLib = lib as SomeInterface;
   

What NOT to do:

• Disabling type checking defeats the purpose
• Overusing any or unknown casts undermines type safety
• Rewriting libraries isn't required — TypeScript supports JS interop natively

📖 Declaration Files (TypeScript Handbook)

T[K] is an indexed access type (also called a lookup type).

What it does:

• Evaluates to the type of the property named by K in T
• Because K is constrained to keyof T, this is type-safe and precise

Example:

interface User {
  name: string;
  age: number;
}

function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

const user: User = { name: "Alice", age: 30 };

const name = getProperty(user, 'name'); // type: string
const age = getProperty(user, 'age'); // type: number

Why it's powerful:

• Maintains type relationship between key and value
• Powers utility types like Pick, Record, Omit

📖 Indexed Access Types (TypeScript Handbook)

Result: Compile-time error

const items: readonly string[] = ['a', 'b'];
items.push('c'); // ❌ Error: Property 'push' does not exist on type 'readonly string[]'

Why:

• TypeScript enforces immutability at compile time for readonly string[]
• The .push() method is not available on readonly array types
• No runtime error occurs because the code doesn't compile

Key points:

• readonly is purely a compile-time construct
• It has no runtime effect
• The array is still mutable at runtime if you bypass TypeScript

Alternative: Use ReadonlyArray<string> (equivalent)

📖 Readonly Arrays (TypeScript Handbook)

The unknown type is intentionally non-assignable to concrete types without narrowing.

Why:

• Enforces type safety when dealing with untrusted values
• Prevents accidental misuse

Solutions:

1. Type assertion:

   let bar: string = foo as string;
   

2. Control-flow narrowing:

   if (typeof foo === 'string') {
     let bar: string = foo; // ✅ OK
   }
   

3. Type guard function:

   function isString(val: unknown): val is string {
     return typeof val === 'string';
   }
   
   if (isString(foo)) {
     let bar: string = foo; // ✅ OK
   }
   

Key point: unknown forces you to prove the type before using it.

📖 Unknown Type (TypeScript Release Notes)

In TypeScript, undefined and null are separate types, not assignable to each other or to other types without an explicit union.

Under strictNullChecks:

let name: string = undefined; // ❌ Error
let name: string = null;      // ❌ Error

let a: string | undefined = undefined; // ✅ OK
let b: string | null = null;           // ✅ OK
let c: string | undefined = null;      // ❌ Error — null ≠ undefined

TypeScript-specific behavior:

• Optional properties (email?: string) imply string | undefined, not null
• --strictNullChecks forces you to model absence explicitly in the type system
• Narrowing treats them separately:

function greet(name: string | null | undefined) {
  if (name === undefined) return "Hello, guest";
  if (name === null) return "Hello, anonymous";
  return `Hello, ${name.toUpperCase()}`; // name: string
}

undefined vs null in practice:

• undefined — missing value, uninitialized variable, omitted optional property
• null — intentional absence, often from APIs that return null

Key point: Unlike JavaScript, TypeScript's type checker rejects passing null where only undefined is expected (and vice versa) unless the union includes both.

📖 Null and Undefined (TypeScript Handbook)

Type assertions like as UserInterface provide zero runtime safety.

What happens:

• They merely tell the compiler to treat the value as conforming to the interface
• No actual validation occurs
• Interfaces are purely compile-time constructs

Example of the problem:

interface User {
  name: string;
  age: number;
}

const data = await fetch('/api/user').then(r => r.json());
const user = data as User; // ❌ Unsafe!

console.log(user.name.toUpperCase()); // 💥 Runtime error if name is missing

Safe alternatives:

1. Runtime validation (Zod):

   import { z } from 'zod';
   
   const UserSchema = z.object({
     name: z.string(),
     age: z.number()
   });
   
   const user = UserSchema.parse(data); // ✅ Validates at runtime
   

2. Type guard function:

   function isUser(data: unknown): data is User {
     return (
       typeof data === 'object' &&
       data !== null &&
       'name' in data &&
       'age' in data
     );
   }
   

Key point: Type assertions are for when you know more than the compiler. For untrusted data, use runtime validation.

📖 Type Assertions (TypeScript Handbook)

Use declare module 'x' for:

• Describing the shape of a module
• Libraries lacking type definitions
• Module-scoped namespaces

Example:

// lodash.d.ts
declare module 'lodash' {
  export function chunk<T>(array: T[], size?: number): T[][];
  export function compact<T>(array: (T | null | undefined)[]): T[];
}

// Now you can import it
import { chunk } from 'lodash';

Use declare global for:

• Modifying global scope
• Adding methods to built-in types
• Extending global interfaces

Example:

declare global {
  interface Array<T> {
    customMethod(): void;
  }
  
  namespace NodeJS {
    interface ProcessEnv {
      API_KEY: string;
    }
  }
}

Key difference:

• declare module is for module imports
• declare global is for global scope modifications

📖 Ambient Modules (TypeScript Docs)

Answer: declare const

Why:

• Introduces an ambient declaration
• Asserts existence without emitting JavaScript
• Avoids duplicate definition errors during compilation

Example:

// global.d.ts
declare const API_VERSION: string;
declare function initializeApp(): void;

Why not other options:

1. Plain const:

   const API_VERSION = '1.0'; // ❌ Emits JS, causes duplication
   

2. export:

   export const API_VERSION = '1.0'; // ❌ Creates module-scoped binding, not global
   

3. globalThis assignment:

   globalThis.API_VERSION = '1.0'; // ❌ Runtime-only, no type safety
   

Use cases:

• Global constants in declaration files
• Multi-entrypoint setups
• Legacy script concatenation (--outFile)

📖 Ambient Declarations (TypeScript Handbook)

This conditional type extracts the resolved type from a Promise.

How it works:

• T extends Promise<infer U> — checks if T is assignable to Promise<something>
• infer U tells TypeScript to infer the type parameter and bind it to U
• ? U : T — if T is a Promise, return the inferred type U; otherwise return T unchanged

Examples:

type A = Awaited<Promise<string>>;  // string
type B = Awaited<Promise<number>>;  // number
type C = Awaited<string>;          // string (not a Promise)
type D = Awaited<Promise<Promise<boolean>>>; // boolean (with TS 4.5+ recursive Awaited)

More examples with infer:

// Extract function return type
type ReturnType<T> = T extends (...args: never[]) => infer R ? R : never;

// Extract array element type
type ElementType<T> = T extends (infer E)[] ? E : T;

// Extract constructor instance type
type InstanceType<T> = T extends new (...args: never[]) => infer R ? R : never;

Key points:

• infer can only be used in the extends clause of conditional types
• It creates a type variable that TypeScript infers from the pattern
• Essential for advanced type-level programming and built-in utility types

📖 Conditional Types (TypeScript Handbook)

Built-in type guards enable control flow analysis.

What happens:

• Inside the if block: data is narrowed to string
• After the if block: TypeScript narrows it to the remaining union member — number

Visual representation:

function process(data: string | number): string {
  // data: string | number
  
  if (typeof data === 'string') {
    // data: string (narrowed)
    return data.toUpperCase();
  }
  
  // data: number (narrowed to remaining type)
  return data.toString();
}

Key points:

• This is not implicit widening or inference
• It's precise, branch-local narrowing
• Based on exhaustive checking of the union
• Works with typeof, instanceof, in, and custom type guards

Limitation: Control flow analysis doesn't persist across function calls or complex control structures.

📖 Control Flow Analysis (TypeScript Handbook)

This mapped type creates getter methods with transformed property names.

How it works:

• [K in keyof T] — iterates over all keys of T; K is each key in turn
• as \get${Capitalize<string & K>}`` — key remapping (TypeScript 4.1+)
  • Transforms each key name
  • Capitalize is a built-in template literal type
  • string & K ensures K is treated as a string (not number or symbol)
• : () => T[K] — each property becomes a function returning the original property type

Step-by-step for Person:

// K = "name"  → key becomes "getName",  value: () => string
// K = "age"   → key becomes "getAge",   value: () => number

type PersonGetters = {
  getName: () => string;
  getAge: () => number;
};

Other key remapping examples:

// Remove keys by filtering with never
type RemoveKindField<T> = {
  [K in keyof T as Exclude<K, "kind">]: T[K];
};

// Prefix all keys
type Prefixed<T> = {
  [K in keyof T as `prefix_${string & K}`]: T[K];
};

// Remap to optional
type PartialByKeys<T, K extends keyof T> = Omit<T, K> & {
  [P in K as P]?: T[P];
};

Key points:

• Key remapping enables powerful type transformations
• Works with template literal types
• Can filter, rename, or compute new keys
• Foundation for advanced utility types beyond Partial, Pick, and Omit

📖 Key Remapping in Mapped Types (TypeScript Handbook)

The rest parameter ...args: [number, string?, boolean] is typed as a fixed-length tuple.

Valid calls:

foo(1); // ✅ OK - [number]
foo(1, "hello"); // ✅ OK - [number, string]
foo(1, "hello", true); // ✅ OK - [number, string, boolean]
foo(1, undefined, true); // ✅ OK - optional parameter

Invalid call:

foo(1, "hello", true, "extra"); // ❌ Error - too many arguments

Why:

• TypeScript treats it as equivalent to (arg0: number, arg1?: string, arg2: boolean) => void
• Passing four arguments violates arity
• Rest parameters with tuple types do not accept extra elements

To accept variable length:

// Use variadic tuple with rest element
function bar(...args: [number, ...string[]]): void {}
bar(1, "a", "b", "c"); // ✅ OK

📖 Tuples with Rest Elements (TypeScript Release Notes)