Question 1

What is TypeScript, and why would you use it instead of plain JavaScript?

Accepted Answer

TypeScript is JavaScript with a static type system on top. You write JavaScript plus type annotations, the compiler checks them, and then the types are erased: the output is plain JavaScript, so there is no runtime cost and runtime behavior doesn't change.

Why teams adopt it:

Bugs caught before running: typos in property names, wrong argument types, forgetting that a value can be null or undefined.
Tooling: autocomplete, go-to-definition and safe rename refactors all come from the type information.
Types as documentation: function signatures describe contracts between modules and teams, which matters more as a codebase grows.
Refactoring confidence: change a type and the compiler lists every place that needs updating.

The trade-offs are a build or type-check step, a learning curve, and the fact that types can lie: any, careless assertions and unvalidated API data all bypass the checker, and nothing is enforced at runtime.

Question 2

What is the difference between type and interface? When would you use each?

Accepted Answer

For object shapes they're nearly interchangeable: both can be generic, extended, and implemented by a class. The real differences:

Only interfaces support declaration merging. Two interface User declarations merge into one, which is how you augment Window or a library's types. A duplicate type is an error.
Interfaces compose with extends, which reports conflicting properties. Type aliases compose with &, where a conflict silently becomes never.
Only type can name unions, tuples, primitives, and mapped, conditional or template literal types.
An object type alias gets an implicit index signature, so it's assignable to Record<string, T>; an interface isn't.

My default is interface for object shapes, especially ones others extend or augment, and type for everything else. Consistency within the team matters more than the choice.

Question 3

Explain the difference between any, unknown and never.

Accepted Answer

- any switches type checking off. You can assign it anywhere and call anything on it, and it spreads silently through every expression it touches. It's an escape hatch, mostly for migrations. - unknown is the type-safe "could be anything". Every value is assignable to it, but you can't use it (access properties, call it, assign it to a typed variable) until you narrow it with typeof, instanceof, a type guard or runtime validation. It's the right type for JSON.parse output, catch variables and untrusted input. - never is the empty type: no value has it. It's the return type of functions that always throw or loop forever, the type left over after exhaustive narrowing, and it disappears from unions (string | never is string). So unknown is the top type, never is the bottom type, and any is an opt-out of the type system. Prefer unknown whenever you're tempted to write any.

Question 4

What are generics, and why use them instead of any?

Accepted Answer

A generic is a type parameter: a placeholder for a type that gets filled in each time a function, class or type is used, usually inferred from the arguments. It lets you write reusable code while keeping the relationship between inputs and outputs. With any, a first(arr) helper returns any and every use of the result is unchecked. With first(arr: T[]): T | undefined, calling it on a string[] returns string | undefined, so the type flows through. You use generics constantly: Array, Promise, Map, React's useState. When inference can't work out the type, you pass it explicitly, like useState(null). A good smell test: a type parameter should appear at least twice, linking a parameter to the return type or to another parameter. If it's used only once, a plain type annotation is usually enough.

Question 5

What are union and intersection types, and how do they differ?

Accepted Answer

A union A | B means the value is *one of* the member types. Until you narrow it, you can only use what all members have in common: on string | number you can call toString() but not toUpperCase(). An intersection A & B means the value is *both* at once, so it has every property of A and every property of B. It's mostly used to combine object types, like User & { permissions: string[] }. The naming feels backwards at first: a union accepts *more* values but lets you do less with them, while an intersection accepts fewer values but guarantees more properties. Intersecting incompatible types produces never: string & number is never, and if two object types disagree on a property, that property becomes never (or the whole type does, for conflicting literal discriminants).

Question 6

What is type narrowing, and which narrowing techniques does TypeScript understand?

Accepted Answer

Narrowing is TypeScript's control-flow analysis refining a broad type, usually a union, to a more specific one inside a branch, based on the checks you write. It understands:

typeof x === 'string' for primitives (remember typeof null is 'object').
x instanceof Date for class instances.
'swim' in animal to check that a property exists.
Equality checks: x === null, x !== undefined, or comparing a literal discriminant like shape.kind === 'circle'.
Truthiness: if (x) removes null and undefined, but also 0 and ''.
Array.isArray(x), and your own type predicates (x is Fish) and assertion functions.

Narrowing follows early returns and throws too: after if (!user) return;, user is non-null for the rest of the function. In the last branch of an exhaustive check, what's left is never.

Question 7

Which built-in utility types do you use most often, and what do they do?

Accepted Answer

The everyday ones: - Partial makes every property optional (update payloads, patch functions); Required removes the ? from every property. - Readonly marks every property readonly. - Pick keeps only the keys K; Omit drops them. - Record builds an object type with keys K and values V, like Record. - Exclude and Extract filter the members of a union; NonNullable removes null and undefined. - ReturnType, Parameters and Awaited derive types from functions and promises. They compose well, for example Partial> for an update form. They're all just mapped and conditional types under the hood, so they're easy to reimplement. One gotcha: Partial and Readonly are shallow, they only affect top-level properties.

Question 8

Would you use an enum or a union of string literals? And what is a const enum?

Accepted Answer

A literal union like type Status = 'idle' | 'loading' is pure type: it's erased, costs nothing at runtime, accepts plain strings from JSON, and narrows well. An enum is one of the few TypeScript features that emits runtime code: a real object you can reference or iterate. The quirks: - String enums are nominal: you can't pass 'idle' where Status.Idle is expected, which is awkward with API data. - Numeric enums get a reverse mapping, and still accept any number-typed value. - Enums aren't erasable syntax, so they're rejected under erasableSyntaxOnly, the mode meant for runtimes that simply strip types. A const enum is inlined at each use site and emits no object, but tools that compile one file at a time (Babel, esbuild, SWC) can't inline one imported from another file, so many teams avoid it. My default is a literal union, or an as const object plus a derived union when I also need the values at runtime.

Question 9

TypeScript is described as structurally typed. What does that mean in practice?

Accepted Answer

Type compatibility is decided by shape, not by name or declaration. If a value has at least the members a type requires, with compatible types, it's assignable, even if it was never declared as that type. That matches how JavaScript objects are actually used ("duck typing"), and it contrasts with nominal languages like Java or C#, where a class must explicitly declare that it implements an interface. Consequences: - Two interfaces with the same shape are interchangeable. - A class instance can be passed where an interface is expected without implements. - Extra properties are fine when you pass an existing variable; only fresh object literals get excess property checks. The downside is that you can't tell a UserId from an OrderId if both are just string. That's what branded types are for. (Classes with private or #private members are the exception: they only match their own declaration.)

Question 10

What do type assertions (as) and the non-null assertion (!) do, and why are they risky?

Accepted Answer

A type assertion, value as Type, tells the compiler "trust me, it's this type". It performs no runtime check or conversion; it's simply erased. TypeScript only allows it when the two types overlap enough (one is assignable to the other); otherwise you need a double assertion through unknown, which is a red flag in review. The non-null assertion x! removes null and undefined from the type of x. Both are risky because if you're wrong, nothing complains at compile time and the failure appears at runtime, often far from the cause. They also keep silencing the compiler after the surrounding code changes. Reasonable uses: DOM lookups where you control the markup, like querySelector('#c') as HTMLCanvasElement, and test code. Otherwise prefer narrowing, type guards, satisfies, or runtime validation. (as const is different: it's a const assertion that makes a literal more specific, not less safe.)

Question 11

What is a user-defined type guard, and how is an assertion function different?

Accepted Answer

When a check lives in a helper function, TypeScript doesn't look inside it: a helper that returns boolean doesn't narrow anything at the call site.

A type predicate fixes that. Declaring the return type as pet is Fish tells the compiler "if this returns true, treat the argument as Fish", and in the else branch it removes Fish from the union.

An assertion function is declared asserts value is T (or just asserts condition). It either returns normally or throws, so there's no if: everything after the call is narrowed. It's handy for invariants like assertDefined(user) or validating input at a boundary. One quirk: the function must be referenced through an explicitly typed name, so an arrow function in a const needs a type annotation.

The big caveat: the compiler trusts your implementation. A predicate with a wrong body is just a hidden as, so keep guards small and tested, or derive them from a schema.

Question 12

What is a discriminated union, and how do you make a switch over it exhaustive?

Accepted Answer

A discriminated (tagged) union is a union of object types that all share one property, the discriminant, with a different literal type in each member, like status: 'loading' | 'success' | 'error'. Checking that property narrows the whole object, so in the 'success' branch TypeScript knows data exists.

It's the idiomatic way to model state because it makes impossible states unrepresentable. Compare it with { loading: boolean; data?: T; error?: string }, which allows loading: true together with an error.

For exhaustiveness, assign the value to a never-typed variable in the default branch. If every case is handled, the value really is never there and it compiles. When someone adds a new member to the union, that line fails to compile and points straight at the switch that needs updating. An assertNever(x: never) helper that throws does the same and also guards at runtime.

Question 13

How do you type a React component's props, children, event handlers and hooks?

Accepted Answer

- Props: a type or interface, destructured in the signature: function Button({ label, onClick }: ButtonProps). React.FC no longer adds children implicitly, so either way declare children?: React.ReactNode when you accept children. - Wrapping native elements: intersect with ComponentProps<'button'> (or ComponentPropsWithoutRef) so disabled, type and aria-* all work. - Events: ChangeEvent, MouseEvent, FormEvent from React (not the DOM globals), or type the prop as ChangeEventHandler. Inline handlers are inferred from context. - Hooks: useState infers from the initial value; pass a type when that value is null or [], like useState(null). DOM refs are useRef(null), and ref.current must be null-checked. A discriminated union of actions types useReducer well. - Generic components: function List(props: ListProps) lets renderItem infer the item type.

Question 14

How do generic constraints work? Explain K extends keyof T with an example.

Accepted Answer

An unconstrained type parameter can be anything, so inside the function you can't assume it has any members. extends adds a constraint: with T extends { length: number } you may use .length, and callers still get their exact type back (a number[] stays number[]), not just { length: number }. In a constraint, extends means "is assignable to", not class inheritance.

The classic example is getProp<T, K extends keyof T>(obj: T, key: K): T[K]:

K must be one of T's keys, so a typo like 'emial' is a compile error.
The return type T[K] is an indexed access type, so getProp(user, 'name') returns exactly string.

Constraints can refer to other type parameters, as K refers to T here. Don't confuse a constraint with a default: <T extends string> restricts what's allowed, <T = string> only says what to use when nothing is inferred or passed.

Question 15

What do the keyof and typeof type operators do, and what are indexed access types?

Accepted Answer

- keyof T produces a union of T's property names as literal types: keyof { id: number; name: string } is 'id' | 'name'. With a string index signature you get string | number, because numeric keys are allowed too. - typeof x in a *type* position gives you the type of a value, so you can derive types from existing code instead of duplicating them: type Config = typeof defaultConfig. It's unrelated to the runtime typeof operator, which returns a string; TypeScript tells them apart by position. - An indexed access type T['name'] looks up the type of a property. Indexing with a union gives a union, T[keyof T] gives all value types, and T[number] gives the element type of an array or tuple. They're often combined: keyof typeof obj for an object's keys, and (typeof ROLES)[number] to turn an as const array into a union, so one runtime list is the single source of truth.

Question 16

What does the strict compiler option enable, and why do strictNullChecks and noImplicitAny matter so much?

Accepted Answer

strict is an umbrella flag that turns on a whole family of checks. The two that matter most: - strictNullChecks: null and undefined become their own types instead of being allowed everywhere. Without it, let s: string = null compiles and reading a property of a possibly missing value isn't flagged, which is the classic runtime crash. With it, you have to handle absence with narrowing, ?. or ??. - noImplicitAny: an error whenever TypeScript can't infer a type and would silently fall back to any, such as an unannotated parameter. The family also includes strictFunctionTypes, strictPropertyInitialization (class fields must be initialized), strictBindCallApply, noImplicitThis, useUnknownInCatchVariables and alwaysStrict. Every new project should use strict, and newer compiler versions enable it by default. Checks added to the family later are switched on automatically, so upgrades can surface new errors. When migrating an old codebase, turn the flags on one at a time.

Question 17

What is the difference between an optional property name?: string and name: string | undefined?

Accepted Answer

name?: string means the key may be missing entirely; reading it gives string | undefined. name: string | undefined means the key must be present, but its value may be undefined: {} isn't assignable, { name: undefined } is. Parameters work the same way. f(x?: number) can be called as f(), while f(x: number | undefined) forces callers to write f(undefined) explicitly, which is sometimes exactly what you want. By default an optional property also accepts an explicit undefined. With exactOptionalPropertyTypes enabled, name?: string means "absent or a string": writing { name: undefined } becomes an error unless you declare name?: string | undefined. The distinction matters at runtime because 'name' in obj, Object.keys and object spread all treat a missing key differently from a key holding undefined.

Question 18

How does type inference work in TypeScript, and when should you still write explicit annotations?

Accepted Answer

TypeScript infers types from initializers (let count = 0 is number), from return statements, and from context: a callback passed to items.map or an onClick prop gets its parameter types from where it's used. A const holding a literal keeps the literal type (const mode = 'dark' is 'dark'), while let widens it to string.

Where I still annotate:

Function parameters, which aren't inferred from how they're used (only contextually typed callbacks get them for free).
Return types of exported functions: it documents intent and catches accidentally returning the wrong shape inside the function rather than at every caller.
Empty or null initial values: const ids: string[] = [], useState<User | null>(null).
Object literals meant to match a type, via an annotation or satisfies, to get excess property checks.

Everywhere else I let inference work. Redundant annotations are noise, and can even lose information, like const x: string = 'a' dropping the literal type.

Question 19

What does void mean as a return type, and how is it different from undefined and never?

Accepted Answer

void says "this function's return value isn't meant to be used". A function with no return, or a bare return;, is inferred as void. never is different: the function never returns normally at all, because it always throws or loops forever. undefined as a return type is stricter than void: callers can rely on the value actually being undefined. The subtle part is function types. A type like () => void accepts functions that *do* return something; the result is simply treated as unusable. That's deliberate, so nums.forEach((n) => list.push(n)) type-checks even though push returns a number. But when you annotate a function declaration itself with : void, returning a value is an error. So: void for callbacks and side-effecting functions, never for functions that can't return, and undefined only when callers should depend on getting undefined.

Question 20

What are mapped types? Walk me through how you would implement Partial or Readonly yourself.

Accepted Answer

A mapped type builds an object type by iterating over a union of keys: { [K in keyof T]: T[K] } copies T property by property. From there you transform each property:

Modifiers: adding ? or readonly sets them, -? and -readonly remove them. So Partial<T> is { [K in keyof T]?: T[K] }, Required<T> uses -?, and Readonly<T> prefixes readonly.
Value types: { [K in keyof T]: boolean } gives a "touched" flag per form field.
Key remapping with as: rename keys, for example with template literal types to generate getName-style getters, or map a key to never to drop it, which is how you filter properties by their value type.

Mapping over keyof T of a generic T is called homomorphic: it preserves the original readonly and ? modifiers, and arrays and tuples stay arrays and tuples. Mapped types are shallow unless you recurse.

Question 21

What are conditional types, and what does the infer keyword do?

Accepted Answer

A conditional type T extends U ? X : Y is a type-level ternary: if T is assignable to U the result is X, otherwise Y. While T is still an unresolved type parameter the conditional stays deferred, and it's evaluated once T is known. NonNullable is essentially T extends null | undefined ? never : T. infer declares a type variable inside the extends clause that TypeScript fills in by pattern matching: - T extends Promise ? U : T unwraps a promise. - T extends (...args: any[]) => infer R ? R : never is how ReturnType works. - T extends readonly (infer E)[] ? E : never extracts an array's element type. infer is only allowed in the extends clause of a conditional type, and you can constrain it, as in infer K extends string. Two things to mention: when T is a naked type parameter, conditionals distribute over unions, and a generic function whose return type is a conditional usually needs an assertion in its body, because TypeScript won't narrow T from a runtime check.

Question 22

What does as const do, and when is it useful?

Accepted Answer

as const is a const assertion: it asks TypeScript to infer the narrowest type for a literal expression. - Literals keep their literal types instead of widening ('GET' rather than string). - Object properties become readonly, recursively for nested literals. - Array literals become readonly tuples: ['a', 'b'] as const is readonly ['a', 'b'], not string[]. Typical uses: defining a list of values once and deriving a union from it with (typeof ROLES)[number]; lookup tables and config objects whose literal values should be preserved; returning a tuple from a custom hook (return [value, toggle] as const) so destructuring keeps each position's type; and passing object properties to functions that expect a literal union. It's compile-time only: it doesn't freeze anything at runtime (that's Object.freeze). It can only be applied to literal expressions, not to an arbitrary variable, and it combines nicely with satisfies to validate the shape while keeping the literals.

Question 23

What does the satisfies operator do, and how is it different from a type annotation or as?

Accepted Answer

expr satisfies Type checks that the expression is assignable to Type without changing its inferred type. - A type annotation (const x: Type = ...) also checks, but the variable's type *becomes* Type, so you lose the specifics: with Record<string, Route> you no longer know which keys exist, and with a union-typed property you have to narrow it again on every use. - as Type barely checks at all (only that the types overlap) and also replaces the type, so it can hide mistakes. - satisfies gives you the full check, including missing keys and excess property errors, while keeping the precise inferred type for autocomplete and narrowing. It shines for config objects, route tables, theme palettes and lookup maps. Combining it with a const assertion, { ... } as const satisfies Config, validates the shape and keeps readonly literal values.

Question 24

What are literal types, and what is type widening?

Accepted Answer

A literal type is a single specific value used as a type: 'GET', 42, true. On its own that's rarely useful, but unions of literals model a fixed set of options: type Method = 'GET' | 'POST', type Dice = 1 | 2 | 3 | 4 | 5 | 6. (boolean itself is just true | false.) Widening is how inference decides between the literal and its base type. const x = 'GET' can never change, so its type is 'GET'. let x = 'GET' can be reassigned, so it widens to string. Object properties and array elements are mutable too, so const req = { method: 'GET' } infers method: string, even though req is a const. That's why passing req.method to a function that expects 'GET' | 'POST' fails, a very common surprise. The fixes: annotate the object with the right type, use as const, or use satisfies.

Question 25

What is a tuple type, and how is it different from an array type?

Accepted Answer

An array type T[] has any length and one element type. A tuple has a known length (or a known structure) and a type per position: [string, number]. Tuples model positional results, like React's useState returning [state, setState] or Object.entries returning [string, T][]. Tuple features: - Labels like [x: number, y: number], which only improve readability and editor hints. - Optional elements [string, number?] and rest elements [string, ...number[]]. - readonly [number, number] to forbid mutation, and T['length'] is a literal type such as 2. Gotchas: a tuple is a plain array at runtime, and a mutable tuple still has push, which TypeScript won't track, so prefer readonly tuples. Also, an array literal like [1, 'a'] infers (string | number)[], not a tuple, unless there's a contextual tuple type, a return type annotation, or as const.

Question 26

What are function overloads, and when would you use them instead of a union parameter or a generic?

Accepted Answer

Overloads give one function several call signatures. You write the overload signatures without bodies, followed by a single implementation signature that is compatible with all of them. Callers only see the overloads, never the implementation signature, and TypeScript picks the first overload that matches from top to bottom, so order them from most specific to least.

They're useful when the return type depends on the argument types in a way a union can't express: parse(input: string): Row but parse(input: string[]): Row[]. The DOM's createElement and addEventListener typings use this idea too.

The costs: the implementation is only checked against its own broad signature, so it can return the wrong thing for a particular overload without an error. And a caller holding a string | number can't call it unless some overload accepts the union.

So I reach for a union parameter first, then a generic, and use overloads only when the input-to-output mapping really needs them.

Question 27

Explain public, private, protected and readonly in classes. How is TypeScript's private different from a #private field?

Accepted Answer

- public is the default: accessible anywhere. - protected: accessible inside the class and its subclasses. - private: accessible only inside the declaring class. - readonly: can only be assigned in its declaration or in the constructor. Parameter properties like constructor(private readonly repo: Repo) declare and assign a field in one step. The key difference: TypeScript's private is compile-time only. After the types are erased it's an ordinary property, so it's reachable with bracket notation (obj['secret'] even type-checks) or a cast, and it shows up in JSON.stringify and Object.keys. A #secret field is a JavaScript feature enforced by the runtime: truly inaccessible from outside the class body, not enumerable, and invisible even to subclasses. Use # when privacy must really hold, for example in a library. TypeScript's modifiers are fine for documenting intent within an app, and protected has no # equivalent.

Question 28

What is an abstract class, and when would you choose one over an interface?

Accepted Answer

An abstract class can't be instantiated directly (new Shape() is an error). It's a base class that can hold real implementation, such as fields, a constructor and concrete methods, plus abstract members that every subclass must implement. An interface is purely a type contract: no implementation, and nothing left at runtime. I'd pick an abstract class when: - Subclasses should share code or state, like a template method where a concrete describe() calls an abstract area(). - I need a runtime value, for instanceof checks or as a dependency-injection token (Angular uses abstract classes this way). I'd pick an interface when I only need a contract. A class can implements many interfaces but extends only one class, and plain objects can satisfy an interface without any class at all. They combine well: an interface for the public contract and an abstract class as an optional partial implementation.

Question 29

What is a .d.ts declaration file, and what is DefinitelyTyped?

Accepted Answer

A .d.ts file contains only type information: signatures, interfaces and declare statements, with no implementation. It describes JavaScript that exists somewhere else, so TypeScript can type-check code that uses it. When you publish a library, declaration: true makes the compiler generate .d.ts files next to the compiled JavaScript so consumers get types. For JavaScript packages that don't ship their own types, the community maintains them in the DefinitelyTyped repository, published to npm under the @types scope: @types/lodash, @types/node, @types/react. When you import such a package, the compiler finds its @types package; which *global* type packages (like Node or test-runner globals) are loaded is controlled by the types compiler option. You write your own declarations for untyped modules, for globals injected by a bundler or a script tag, and for non-code imports like *.svg or *.css. skipLibCheck skips checking .d.ts files, which speeds up builds.

Question 30

What does readonly do, and how does it differ from const and Object.freeze?

Accepted Answer

const is JavaScript: the variable binding can't be reassigned, but the object it points to can still be mutated. readonly is a TypeScript property modifier: the property can't be reassigned after initialization. readonly string[] (or ReadonlyArray) removes mutating methods like push and splice from the type, and Readonly marks every property readonly. Caveats worth mentioning: - It's compile-time only: nothing stops mutation at runtime. - It's shallow: nested objects stay mutable unless they're readonly too. - An object with readonly properties is still assignable to a type with the same properties writable, so it's not a hard guarantee. Readonly arrays are stricter: readonly number[] isn't assignable to number[]. Object.freeze is the runtime counterpart (also shallow), and TypeScript types its result as Readonly. I use readonly on props, state and array parameters I don't intend to mutate.

Question 31

What is the difference between Exclude and Omit? And what do Extract and NonNullable do?

Accepted Answer

They work on different kinds of types: - Exclude works on a union: it removes the members assignable to X. Exclude<'a' | 'b' | 'c', 'a'> is 'b' | 'c'. - Omit works on an object type: it removes properties. Omit is User without password. It's built from the other one: Pick>. - Extract is the opposite of Exclude: it keeps the members assignable to X, which is handy for pulling one member out of a discriminated union. - NonNullable removes null and undefined. Two Omit gotchas worth knowing. Its keys aren't checked against T, so a typo like Omit compiles silently, while Pick would reject it. And it isn't distributive: on a union of object types it keeps only the common keys, so you need T extends unknown ? Omit : never to omit from each member.

Question 32

How do ReturnType, Parameters and Awaited help you derive types from existing code?

Accepted Answer

They derive types from functions and promises instead of duplicating definitions, so the types stay in sync when the function changes.

ReturnType<typeof fn> gives the return type. You need typeof because these utilities take a type, and fn is a value.
Parameters<typeof fn> gives the parameter list as a tuple, so Parameters<typeof fn>[0] is the first argument's type.
Awaited<T> unwraps promises recursively: Awaited<Promise<Promise<number>>> is number. Awaited<ReturnType<typeof fetchUser>> is the resolved value of an async function.
For classes there are ConstructorParameters and InstanceType.

Real uses: typing the result of a library function whose types aren't exported, Redux's RootState = ReturnType<typeof store.getState>, and wrappers like (...args: Parameters<typeof fn>) => ....

One caveat: on an overloaded function, ReturnType and Parameters only see the last overload signature.

Question 33

Do TypeScript types exist at runtime? Why can't you write x instanceof User when User is an interface?

Accepted Answer

No. Types are erased during compilation: interfaces, type aliases, annotations, generics and assertions all disappear, and what runs is plain JavaScript. So an interface isn't a value. x instanceof User doesn't compile ("only refers to a type, but is being used as a value here"), and there's no way to list an interface's keys at runtime. Generics are erased too, so inside a generic function you can't write new T() or check what T is. What does exist at runtime are the features that emit code: classes (so instanceof works with them), enums, and namespaces that contain values. The practical consequence: a function typed (user: User) can still receive garbage from an API, localStorage or JSON.parse. Checks have to be written in real JavaScript: typeof, in, Array.isArray, custom type guards, or a schema library like zod that validates at runtime and gives you the static type from the same schema.

Question 34

How do you type functions in TypeScript, including optional, default and rest parameters and function types?

Accepted Answer

- Parameters are annotated; the return type is usually inferred but worth writing on exported functions: function add(a: number, b: number): number. - Optional parameters b?: number must come after required ones. Default parameters b = 10 get their type from the default and are optional for callers. - Rest parameters: ...nums: number[], or a tuple type for a fixed structure. - Function type expressions describe callbacks: type Handler = (event: MouseEvent) => void. When a function also has properties, use a call signature in an object type: { (x: number): string; displayName: string }. - A function assigned to a typed variable or passed as a callback gets contextually typed parameters, so const h: Handler = (e) => ... needs no annotation on e. - You can declare a fake first this parameter, function (this: HTMLElement), which is erased from the output. Also, a function with *fewer* parameters is assignable to a function type with more, which is why arr.map((x) => ...) works without accepting index and array.

Question 35

What is an index signature, and what does the noUncheckedIndexedAccess option change?

Accepted Answer

An index signature types an object used as a dictionary whose keys aren't known in advance: { [name: string]: number }, which is equivalent to Record<string, number>. Keys can be string, number, symbol or template literal patterns such as data-${string}, and any named properties must be compatible with the signature's value type.

The catch: by default, scores['bob'] is typed number even though the key may not exist, so you get undefined at runtime with no warning. The same applies to arrays: list[10] is typed number.

noUncheckedIndexedAccess adds | undefined to every index access, forcing a check before use. It isn't part of strict, so you opt in explicitly. It's a bit noisy with index-based loops, which is a good excuse for for...of.

Alternatives: a Map, whose get already returns V | undefined. And note Record<'light' | 'dark', string> with literal keys is not an index signature: it's a fixed set of required properties.

Question 36

Which tsconfig.json options do you consider essential, and what do they control?

Accepted Answer

The ones I always look at: - strict, ideally plus noUncheckedIndexedAccess. - target: which JavaScript syntax the compiler emits. lib: which built-in type declarations exist, like DOM or ES2022 (derived from target if you don't set it). - module and moduleResolution: how imports are emitted and resolved. bundler suits Vite or webpack apps; nodenext suits code run by Node, and respects package.json exports and type. - noEmit when a bundler or esbuild/SWC does the transpiling and tsc only type-checks. Then isolatedModules or verbatimModuleSyntax ensures each file can be compiled on its own. - jsx: react-jsx for React. - paths for import aliases. It only affects type-checking and resolution, the bundler needs the same aliases. - skipLibCheck for faster builds; declaration, outDir and sourceMap for libraries. - include/exclude, extends for shared base configs, and references for project references in monorepos.

Question 37

How do you type data coming from an API? Is const user = (await res.json()) as User good enough?

Accepted Answer

Not really. res.json() returns Promise, and the as only tells the compiler to trust you. If the backend changes a field, returns an error payload, sends null or sends dates as strings, TypeScript can't know, and the crash happens later, far from the fetch. Types are erased, so the only way to *know* the shape is to validate at runtime, at the boundary. Options, from lightest to strongest: - Treat the payload as unknown and narrow it with hand-written type guards. Fine for small shapes. - Use a schema library such as zod: define the schema once, parse (or safeParse) at the boundary, and derive the static type with z.infer, so the type and the validation can't drift apart. - Generate types from an OpenAPI or GraphQL schema. That keeps compile-time types matched to the contract, but still doesn't check what actually arrives unless paired with validation. A generic fetchJson(url): Promise helper is just a cast in disguise unless it also takes a validator.

Question 38

What is a distributive conditional type, and how do you prevent distribution?

Accepted Answer

When a conditional type checks a naked type parameter, as in T extends U ? X : Y, and T is instantiated with a union, the conditional is applied to each member separately and the results are unioned. So with ToArray = T extends unknown ? T[] : never, ToArray is string[] | number[], not (string | number)[]. That's exactly what makes Exclude = T extends U ? never : T work: members that map to never vanish from the union. To turn distribution off, wrap both sides in a one-element tuple: [T] extends [U] ? X : Y. Now the union is checked as a whole. Gotchas: - never is the empty union, so a distributive conditional given never returns never without evaluating either branch. A correct IsNever needs [T] extends [never]. - boolean is true | false, so it distributes too. - Distribution only happens for a type parameter, not for a union written directly in the extends check.

Question 39

What are template literal types? Give a practical use case.

Accepted Answer

Template literal types use template string syntax at the type level to build string literal types. When a placeholder holds a union, the result contains every combination: two sizes times two colors gives four class names. Placeholders can also be string or number to describe a pattern, like #${string} for hex colors or ${number}px for pixel values. The intrinsic helpers Uppercase, Lowercase, Capitalize and Uncapitalize transform them.

Practical uses:

Event handler names, such as mapping 'click' to onClick with key remapping in a mapped type.
Design-system class names or CSS values that must follow a pattern.
Parsing strings with infer, for example extracting id from a route like '/users/:id' to type route params.

The caveat is size: combinations multiply quickly, and big cross products slow the checker down; past a certain union size the compiler gives up with an error.

Question 40

What is declaration merging, and how do you use module augmentation to extend a third-party library's types?

Accepted Answer

Declaration merging means the compiler combines several declarations with the same name into one. Interfaces merge their members; namespaces merge with other namespaces and with classes, functions and enums (for example, to attach static properties to a function); enums merge with each other. Type aliases never merge. Module augmentation uses this to extend types you don't own. In a file that is itself a module (it has an import or export), you write declare module 'library-name' { ... } and re-declare the library's interface with extra members, which merge into the original. Everyday examples: adding requiresAuth to Vue Router's RouteMeta, adding user to Express's request type, or typing Vite's ImportMetaEnv. For globals, declare global { interface Window { ... } } does the same thing. The limits: you can only add to or merge with existing declarations, not replace them or add new top-level declarations to the module, and a repeated property must keep the same type.

Question 41

What are excess property checks, and why does passing the same object through a variable sometimes avoid the error?

Accepted Answer

Structural typing normally allows extra properties. The exception is a fresh object literal, one written directly where a type is expected: TypeScript reports any property the target type doesn't declare. draw({ colour: 'red' }) fails for an Options type with color?, which catches typos that would otherwise pass silently because every property is optional.

Once the literal is stored in an unannotated variable and passed later, it's no longer fresh, so ordinary structural rules apply and extra properties are fine. That's why the "same" object can compile through a variable and fail inline. It's a targeted heuristic, not exact types, which TypeScript doesn't have.

A related rule is weak type detection: if every property of the target is optional, an object sharing no properties with it is rejected even through a variable.

To pass extra properties on purpose you can annotate the variable, add an index signature to the target, or spread the object, but usually the error is pointing at a real bug.

Question 42

What is the difference between the types object, Object and {}?

Accepted Answer

- {} does not mean "empty object". It means any value except null and undefined: strings, numbers and booleans all qualify, because property access works on them. In fact unknown behaves like {} | null | undefined. - Object (capital O) is the type of Object.prototype's members. It behaves almost the same as {}, primitives included, and linters flag it as a mistake. - object (lowercase) means any non-primitive: plain objects, arrays, functions, class instances. It rejects string, number, boolean, symbol, bigint, null and undefined. What to use instead: - A truly empty object: Record. - "Some object with unknown contents": Record or object. - "Any non-nullish value" as a generic constraint: T extends {}. The mistake interviewers look for is writing {} or Object to mean "an object" and then being surprised that 'hello' is accepted.

Question 43

What is the type of the error in a catch block, and how should you handle it?

Accepted Answer

JavaScript can throw anything, not just Error instances: strings, numbers, plain objects, even undefined. So TypeScript can't know what you'll catch. It used to be any; with useUnknownInCatchVariables, which is part of strict, the catch variable is unknown and must be narrowed before use. You can't annotate it with a specific type: catch (e: Error) is a compile error, only any or unknown are allowed, because TypeScript can't guarantee what was thrown. The idioms: - if (err instanceof Error) to access message and stack, with a fallback like String(err) for anything else. - A small getErrorMessage(err: unknown) helper used everywhere. - Custom error subclasses plus instanceof for specific handling. Watch out for promises: the reason in .catch((reason) => ...) is typed any by the standard library, so annotate it as unknown yourself.

Question 44

What is import type, and why do options like isolatedModules and verbatimModuleSyntax care about it?

Accepted Answer

import type { User } from './user' imports only type information. It's always removed from the output and can't be used as a value. The inline form, import { type User, createUser } from './user', marks individual names. Why it matters: tsc knows which imports are only used as types and drops them. But tools that transpile one file at a time (esbuild, SWC, Babel, and the bundlers built on them) can't look into ./user to see whether User is a type or a value. They might keep an import of something that doesn't exist at runtime, or drop an import that was needed for its side effects. - isolatedModules makes tsc report code that single-file transpilers can't handle safely, such as re-exporting a type without export type. - verbatimModuleSyntax makes the rule simple and predictable: imports without type are kept exactly as written, imports with type are dropped. So every type-only import must be marked. The result is output you can predict from the source, whatever tool compiles it.

Question 45

What is the difference between // @ts-ignore and // @ts-expect-error, and when is either acceptable?

Accepted Answer

Both comments suppress type errors on the next line.

@ts-ignore suppresses silently, whether or not there is an error.
@ts-expect-error suppresses too, but is itself reported as an error ("Unused '@ts-expect-error' directive") when the next line has no error.

That makes @ts-expect-error self-cleaning: when a library update or refactor fixes the underlying problem, the compiler tells you to remove the comment instead of leaving a stale suppression that might hide a future bug. Add a reason after it, like a link to the upstream issue.

Acceptable uses are narrow: tests that deliberately pass invalid input, or working around a known bug in third-party types. Both are blunt instruments that hide every error on that line, not just the one you meant. Related directives: // @ts-nocheck disables checking for a whole file (handy mid-migration) and // @ts-check enables checking in a JavaScript file. Normally, fix the types or narrow instead.

Question 46

How would you migrate a large JavaScript codebase to TypeScript?

Accepted Answer

Incrementally, never as a big-bang rewrite.

Set up side by side: add a tsconfig.json with allowJs so JavaScript and TypeScript compile together, and noEmit if the bundler does the transpiling. Add a type-check step to CI early.
Get value before renaming: checkJs or a per-file // @ts-check plus JSDoc types gives checking in plain .js files.
Convert leaves first: utilities, the API client and shared models are imported everywhere, so typing them makes types flow outward to their callers.
Dependencies: install @types/* packages and write small .d.ts shims for untyped ones.
Tighten gradually: start loose, then enable noImplicitAny, then strictNullChecks, then full strict, fixing errors per directory.
Prevent regressions: lint rules against explicit any, and track the remaining count of any and @ts-expect-error as a metric.

Prioritize boundaries, such as API responses, component props and shared domain types, because that's where types pay off most. Temporary any is fine as long as it's visible and shrinking.

Question 47

What are default type parameters, and how do they interact with type inference?

Accepted Answer

A default type parameter works like a default function argument: with interface ApiResponse<T = unknown>, writing plain ApiResponse means ApiResponse<unknown>. The rules mirror optional parameters: defaulted type parameters come after required ones, a default must satisfy the parameter's constraint, and it can refer to earlier parameters, as in <A, B = A>.

With function calls, inference wins: a default is only used when there's nothing to infer from.

The subtle part is explicit type arguments, which are all-or-nothing. TypeScript has no partial inference. If you write pair<number>(1, 'x') for pair<A, B = A>, B isn't inferred from 'x': it takes its default, number, and the call fails. And for a function with two parameters and no defaults, passing only one type argument is an error ("Expected 2 type arguments").

Defaults are common in library types, such as event emitters with a default event map or generic components with a default item type.

Question 48

What are branded (nominal) types, and why would you use them?

Accepted Answer

Because TypeScript is structural, type UserId = string is only an alias: any string, including an order id, can be passed where a UserId is expected. A brand adds a property that exists only in the type system: type UserId = string & { readonly __brand: 'UserId' }. A plain string no longer satisfies it, and UserId and OrderId aren't interchangeable. At runtime it's still an ordinary string with zero overhead, and a UserId can still be used anywhere a string is expected. Branded values are created in one place, a "smart constructor" or validation function, which is the only spot that needs an as. From then on the type proves the value went through that check. Good uses: IDs, validated values (Email, NonEmptyString), units (Meters vs Feet) and sanitized HTML. Some teams use a unique symbol as the brand key so it can't clash, and schema libraries support it directly, such as zod's .brand().

Question 49

Explain covariance and contravariance in TypeScript. What is method parameter bivariance?

Accepted Answer

Variance describes how subtyping between two types carries over to types built from them. Say Dog is a subtype of Animal:

Covariant (same direction): return types and readonly properties. () => Dog is assignable to () => Animal.
Contravariant (reversed): function parameters. (a: Animal) => void is assignable to (d: Dog) => void, because a function that handles any animal can handle a dog, but not the other way round. strictFunctionTypes, part of strict, enforces this for function types.
Bivariant: parameters of methods, declared with method syntax like handle(a: Animal): void, are still checked in both directions, mainly so generic types like Array<T> keep relating covariantly. That's unsound, so declare callbacks with property syntax, handle: (a: Animal) => void, to get strict checking.

Arrays are another deliberate hole: Dog[] is assignable to Animal[] even though they're mutable, so you could push a Cat through the Animal[] alias. You can document variance explicitly with in and out modifiers on type parameters, such as interface Producer<out T>.

Question 50

How do you write recursive types, for example a JSON type or a DeepPartial?

Accepted Answer

A type alias or interface can refer to itself, as long as the reference sits inside a structure such as an object property, an array or a generic, rather than being an immediate cycle. Common examples:

Trees: interface TreeNode { value: string; children: TreeNode[] }.
A Json union where arrays and objects contain Json again.
Recursive mapped types like DeepPartial or DeepReadonly, which apply themselves to each nested property.

Recursive conditional types work too, for example flattening nested arrays or parsing strings with template literal types.

Things to get right:

Decide what to do with functions, Date, Map and so on. A naive DeepPartial maps over a function's properties instead of leaving it alone.
The compiler has a recursion depth limit; hitting it gives "Type instantiation is excessively deep and possibly infinite". Tail-recursive conditional types get a higher limit.
Deep recursion on big types slows the checker and the editor, so keep recursive helpers simple.

TypeScript

Notes in this chapter

TypeScript Generics, Explained Through Interview Questions

type vs interface: When It Actually Matters

Build TypeScript's Utility Types From Scratch

Top 56 TypeScript interview questions most asked first