TypeScript Developer Interview Questions

Summary

TypeScript is a statically typed superset of JavaScript that adds a type system and compiles (by erasing types) to plain JavaScript. It catches type errors at compile time, improves editor tooling and documents intent in large codebases.

Longer Answer

Any valid JavaScript is (almost always) valid TypeScript. The type checker (tsc) analyses code without running it; types are erased in the output, so there's no runtime type checking. Benefits include safer refactors, autocompletion, self-documenting APIs and catching undefined is not a function bugs before production. Tools like esbuild, SWC and Node's type stripping can remove types without checking them, so teams run tsc --noEmit separately in CI.

Key Points

• Superset of JavaScript
• Static checking, types erased at compile time
• No runtime type validation
• Better tooling and refactoring

Summary

any disables type checking for a value; unknown is the type-safe top type: anything can be assigned to it, but you must narrow it before use; never is the bottom type for values that never occur (functions that throw, exhaustive checks).

Longer Answer

Prefer unknown for untrusted input (JSON, catch variables with useUnknownInCatchVariables) and narrow with typeof, instanceof or schema validation. any spreads silently through code and should be rare (lint with no-explicit-any). never is useful in exhaustive switch statements: assigning the remaining value to never makes the compiler error when a new union member is added.

Code Example

function parse(json: string): unknown {
  return JSON.parse(json);
}

const data = parse('{"name":"Ana"}');
// data.name;  // Error: 'data' is of type 'unknown'
if (typeof data === "object" && data !== null && "name" in data) {
  console.log((data as { name: string }).name);
}

function assertNever(x: never): never {
  throw new Error(`Unexpected: ${JSON.stringify(x)}`);
}

Key Points

• any: opt out of checking (contagious)
• unknown: must narrow before use
• never: impossible values, exhaustiveness
• Prefer unknown for external data

Comparison / Tradeoffs

Summary

Both can describe object shapes and be extended. Interfaces support declaration merging and extends, which reads well for object/class contracts; type aliases can name any type, including unions, tuples, primitives, mapped and conditional types.

Longer Answer

Interfaces with the same name in the same scope merge, which is used to augment library types (e.g., adding fields to Window or Express's Request). Type aliases can't be reopened. For object shapes, either is fine; many teams use interface for public object contracts and type for unions and computed types. Interface extends errors on conflicting properties, while intersections (&) may silently produce never properties.

Code Example

interface User { id: string; name: string }
interface User { email: string }        // merged: { id, name, email }

type Status = "active" | "banned";      // only possible with type alias
type WithTimestamps<T> = T & { createdAt: Date; updatedAt: Date };

Key Points

• Interfaces: declaration merging, extends
• Types: unions, tuples, mapped/conditional types
• Both work for object shapes
• Use merging to augment library types

Summary

TypeScript checks compatibility by shape (structure), not by declared names: a value is assignable to a type if it has all the required members with compatible types, regardless of which class or interface created it.

Longer Answer

This differs from nominal typing in Java or C#. Two unrelated interfaces with the same members are interchangeable. Excess property checks only apply to fresh object literals. When you need nominal-like behavior (e.g., not mixing UserId and OrderId strings), use branded types.

Code Example

interface Point { x: number; y: number }
class Vector { constructor(public x: number, public y: number) {} }

const p: Point = new Vector(1, 2); // OK: same shape

type UserId = string & { readonly __brand: "UserId" };
type OrderId = string & { readonly __brand: "OrderId" };
declare function getUser(id: UserId): void;
// getUser("abc" as OrderId); // Error: brands differ

Key Points

• Compatibility by shape
• Unrelated types with same shape are interchangeable
• Excess property checks on object literals
• Brands simulate nominal typing

Summary

Narrowing refines a broad type to a more specific one within a code branch, based on control-flow analysis of checks like typeof, instanceof, in, equality, truthiness, discriminant properties, and user-defined type guards (x is T) or assertion functions (asserts x is T).

Longer Answer

The compiler tracks types through if/switch/early returns. Since TypeScript 5.5, the compiler can infer type predicates from simple functions like x => x !== null, so array.filter(...) narrows correctly. Assertion functions throw if the condition fails and narrow afterwards.

Code Example

type Shape = { kind: "circle"; r: number } | { kind: "rect"; w: number; h: number };

function area(s: Shape): number {
  switch (s.kind) {
    case "circle": return Math.PI * s.r ** 2;   // s narrowed to circle
    case "rect":   return s.w * s.h;
  }
}

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

const ids = [1, null, 3].filter((x) => x !== null); // number[] (TS 5.5+)

Key Points

• typeof, instanceof, in, equality
• Discriminated unions with switch
• Custom guards: (x): x is T
• Assertion functions: asserts x is T
• TS 5.5 infers type predicates

Summary

A discriminated (tagged) union is a union of object types sharing a literal property (the discriminant, e.g., type or status). Checking that property narrows to the exact variant, and exhaustiveness checks ensure every case is handled.

Longer Answer

They model state machines and API results precisely, making invalid states unrepresentable (e.g., { status: 'success'; data } vs { status: 'error'; error } instead of optional data? and error?). Combined with never-based exhaustiveness checks, adding a variant forces updates everywhere.

Code Example

type Result<T> =
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; error: Error };

function render(r: Result<string[]>) {
  switch (r.status) {
    case "loading": return "Loading…";
    case "success": return r.data.join(", ");
    case "error":   return r.error.message;
    default: {
      const _exhaustive: never = r;
      return _exhaustive;
    }
  }
}

Key Points

• Shared literal tag field
• Narrowing per variant
• Exhaustiveness via never
• Make invalid states unrepresentable

Summary

Generics are type parameters (<T>) that let functions, classes and types work over many types while preserving type relationships. Constraints (<T extends Something>) restrict what T can be so you can safely use its members.

Longer Answer

Example: function first<T>(arr: T[]): T | undefined returns the same element type it receives. keyof constraints relate parameters: function get<T, K extends keyof T>(obj: T, key: K): T[K]. Defaults (<T = string>) and inference from arguments make generic APIs ergonomic. Avoid unnecessary generics: if T is used only once, a plain type is clearer.

Code Example

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

const user = { id: 1, name: "Ana" };
const n = getProp(user, "name");   // string
// getProp(user, "age");           // Error: '"age"' not in keyof user

function longest<T extends { length: number }>(a: T, b: T): T {
  return a.length >= b.length ? a : b;
}

Key Points

• Type parameters preserve relationships
• extends constraints
• K extends keyof T → T[K]
• Inference from arguments
• Don't over-genericize

Summary

Common ones: Partial<T>, Required<T>, Readonly<T>, Pick<T, K>, Omit<T, K>, Record<K, V>, Exclude<U, X>, Extract<U, X>, NonNullable<T>, ReturnType<F>, Parameters<F>, Awaited<T> and NoInfer<T> (5.4).

Longer Answer

They're built with mapped and conditional types. Example uses: Partial<User> for PATCH payloads, Omit<User, 'password'> for public DTOs, Record<Status, string> for exhaustive lookup tables, ReturnType<typeof createStore> to derive types from implementations, and Awaited<ReturnType<typeof fetchUser>> for async results.

Code Example

interface User { id: string; name: string; email: string; password: string }

type PublicUser = Omit<User, "password">;
type UserPatch = Partial<Pick<User, "name" | "email">>;
type StatusLabels = Record<"active" | "banned", string>;

async function fetchUser(id: string): Promise<PublicUser> { /* ... */ return null!; }
type Fetched = Awaited<ReturnType<typeof fetchUser>>; // PublicUser

Key Points

• Partial/Required/Readonly modify properties
• Pick/Omit select keys
• Record for maps with known keys
• ReturnType/Parameters/Awaited derive types

Summary

Mapped types create new types by iterating over keys: { [K in keyof T]: ... }. Modifiers ?, readonly, -? and -readonly add or remove optionality and readonly-ness, and as clauses remap or filter keys.

Longer Answer

Key remapping with template literal types enables things like generating getter names. Filtering keys uses as with a conditional resolving to never.

Code Example

type MyPartial<T> = { [K in keyof T]?: T[K] };
type Mutable<T> = { -readonly [K in keyof T]: T[K] };

type Getters<T> = {
  [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
};
type UserGetters = Getters<{ name: string; age: number }>;
// { getName: () => string; getAge: () => number }

type OnlyStrings<T> = { [K in keyof T as T[K] extends string ? K : never]: T[K] };

Key Points

• [K in keyof T] iteration
• ?/readonly modifiers and - removal
• as for key remapping/filtering

Summary

Conditional types (T extends U ? X : Y) choose a type based on assignability. infer declares a type variable inside the extends clause to capture part of a type, e.g. a function's return type or a promise's resolved value.

Longer Answer

When T is a naked type parameter, conditional types distribute over unions: ToArray<string | number> becomes string[] | number[]. Wrap in brackets ([T] extends [U]) to prevent distribution. Many built-in utilities (ReturnType, Awaited, Exclude) are conditional types.

Code Example

type MyReturnType<F> = F extends (...args: any[]) => infer R ? R : never;
type ElementType<T> = T extends readonly (infer E)[] ? E : T;
type UnwrapPromise<T> = T extends Promise<infer V> ? UnwrapPromise<V> : T;

type A = MyReturnType<() => number>;    // number
type B = ElementType<string[]>;          // string
type C = UnwrapPromise<Promise<Promise<boolean>>>; // boolean

Key Points

• T extends U ? X : Y
• infer R captures sub-types
• Distributive over naked unions
• [T] extends [U] disables distribution

Summary

satisfies (TypeScript 4.9) checks that an expression conforms to a type without changing the expression's inferred type, so you get validation and keep precise literal types. An annotation (const x: T = ...) widens the variable to T.

Longer Answer

Typical use: configuration objects where you want to ensure all keys are valid and values have the right shape, but still want autocomplete on the specific keys and literal values.

Code Example

type Route = { path: string; auth: boolean };

const routes = {
  home: { path: "/", auth: false },
  admin: { path: "/admin", auth: true },
} satisfies Record<string, Route>;

routes.admin.path;      // OK, and key "admin" is known
// routes.missing;      // Error: property doesn't exist

const annotated: Record<string, Route> = routes;
annotated.anything;     // no error: keys widened to string

Key Points

• Validates without widening
• Keeps literal/specific inferred types
• Great for config and lookup objects
• Annotations widen to the declared type

Summary

as const makes TypeScript infer the narrowest possible type: literal types instead of string/number, readonly properties, and readonly tuples instead of arrays.

Longer Answer

It's commonly used to derive union types from runtime arrays or objects, giving a single source of truth: const ROLES = ['admin', 'user'] as const; type Role = typeof ROLES[number];. Combine with satisfies for validated, literal configs.

Code Example

const ROLES = ["admin", "editor", "viewer"] as const;
type Role = (typeof ROLES)[number]; // "admin" | "editor" | "viewer"

const config = { retries: 3, mode: "strict" } as const;
// config.mode = "loose"; // Error: readonly

Key Points

• Literal types instead of widened ones
• Deep readonly
• Readonly tuples
• Derive unions from runtime values

Summary

Many teams prefer string literal unions (optionally derived from an as const object) over enums: unions are erased at compile time, work with structural typing and plain strings, and are supported by type-stripping tools. Enums generate runtime objects and have quirks (numeric enums accept any number in older versions; const enum breaks with isolated modules).

Longer Answer

Enums are still fine for some codebases, especially string enums with explicit values. Node's built-in type stripping and erasableSyntaxOnly (TS 5.8) reject enums because they aren't erasable syntax, which pushes modern code toward unions or as const objects.

Code Example

// Preferred alternative to enum
const Status = { Active: "active", Banned: "banned" } as const;
type Status = (typeof Status)[keyof typeof Status]; // "active" | "banned"

function setStatus(s: Status) {}
setStatus(Status.Active);
setStatus("banned");

Key Points

• Unions: zero runtime cost
• as const objects give runtime values + types
• Enums emit JS objects
• const enum issues with isolatedModules
• Type stripping doesn't support enums

Summary

strict: true enables strictNullChecks, noImplicitAny, strictFunctionTypes, strictBindCallApply, strictPropertyInitialization, useUnknownInCatchVariables, alwaysStrict and noImplicitThis. Extra recommended flags: noUncheckedIndexedAccess, exactOptionalPropertyTypes, noImplicitOverride and noFallthroughCasesInSwitch.

Longer Answer

strictNullChecks is the most valuable: it forces handling null/undefined. noUncheckedIndexedAccess makes arr[i] and record[key] return T | undefined, catching out-of-bounds bugs. When migrating a large JS codebase, enable strict flags incrementally.

Key Points

• strict: true bundle
• strictNullChecks is the biggest win
• noUncheckedIndexedAccess for index safety
• Adopt incrementally in migrations

Summary

Overloads declare multiple call signatures for one implementation, letting the return type depend on the argument types. The implementation signature must be compatible with all overloads and isn't visible to callers.

Longer Answer

Use overloads when the output type depends on input in ways a union can't express (e.g., parse(x: string): Date; parse(x: number): Date[]). Often a generic or conditional return type is simpler. Overload order matters: TypeScript picks the first matching signature.

Code Example

function createElement(tag: "a"): HTMLAnchorElement;
function createElement(tag: "canvas"): HTMLCanvasElement;
function createElement(tag: string): HTMLElement;
function createElement(tag: string): HTMLElement {
  return document.createElement(tag);
}

const c = createElement("canvas"); // HTMLCanvasElement

Key Points

• Multiple call signatures, one implementation
• Implementation signature hidden
• Order matters
• Consider generics/conditional types first

Summary

TypeScript types vanish at runtime, so data from APIs, forms, env vars or JSON.parse isn't actually checked. Schema libraries (Zod, Valibot, ArkType) validate data at runtime and infer static types from the same schema, giving one source of truth.

Longer Answer

Validate at trust boundaries: incoming requests, external API responses, environment variables and local storage. Use safeParse to handle errors without exceptions. Casting (as User) only silences the compiler; it doesn't make data correct.

Code Example

import { z } from "zod";

const UserSchema = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  role: z.enum(["admin", "user"]),
});
type User = z.infer<typeof UserSchema>;

const res = await fetch("/api/me");
const parsed = UserSchema.safeParse(await res.json());
if (!parsed.success) throw new Error("Bad payload");
const user: User = parsed.data;

Key Points

• Types are erased at runtime
• Validate at system boundaries
• z.infer<typeof schema> for types
• as casts don't validate

Summary

keyof T produces a union of T's property keys; typeof value (in a type position) gets the type of a runtime value; indexed access T[K] looks up the type of a property (or T[number] for array elements).

Longer Answer

Together they derive types from values: type Config = typeof config; type Key = keyof Config; type Value = Config[Key]. This keeps types in sync with runtime objects.

Key Points

• keyof T → union of keys
• typeof x → type of a value
• T[K] and T[number] lookups
• Derive types from values

Summary

value as T tells the compiler to treat a value as T, and value! asserts it isn't null/undefined. Neither does anything at runtime; if you're wrong, you get runtime errors the compiler could have caught.

Longer Answer

Prefer narrowing, type guards or validation. Assertions are acceptable when you genuinely know more than the compiler (e.g., DOM elements guaranteed by the template), but as unknown as T double-casts are a code smell. ESLint rules can restrict them.

Key Points

• Compile-time only, no runtime effect
• Prefer narrowing/validation
• ! hides possible undefined
• Avoid as unknown as T

Summary

Intersection types (A & B) combine types so the value must satisfy all of them. Interface extends also combines but reports conflicts eagerly, whereas conflicting intersection members can silently become never.

Longer Answer

Intersections are useful for mixins, adding props (T & { id: string }) and branding. Interfaces with extends usually give better error messages and compiler performance for large object hierarchies.

Key Points

• A & B must satisfy both
• Conflicts may produce never silently
• extends errors on conflicts
• Interfaces often faster to check

Summary

A union type (A | B) describes a value that can be one of several types. You can only use members common to all variants until you narrow the value with checks.

Longer Answer

Unions model real-world variability: string | number IDs, 'asc' | 'desc' options, or API results. Narrow with typeof, discriminants or guards before using variant-specific members.

Key Points

• A | B = one of several types
• Only shared members usable before narrowing
• Literal unions replace magic strings