100 TypeScript Interview Questions and Answers

These 100 TypeScript interview questions move from everyday types to narrowing, generics, project configuration, and practical design decisions. Each answer gives a concise explanation and, where useful, a small example or the reasoning an interviewer is looking for. TypeScript adds type syntax and static checking to JavaScript; its types help catch some mistakes before execution, but they do not replace runtime validation or prove that a program is bug-free.

TypeScript fundamentals

1. What is TypeScript?

TypeScript is a language that builds on JavaScript with syntax for types. Its checker analyzes code before it runs, and its type information supports editor features such as completion and diagnostics. For example, const count: number = 3; declares a numeric value. The interviewer is checking that you understand TypeScript as a development-time type system, not a runtime validator. The TypeScript 5.9 release announcement is dated August 1, 2025; that dated release note is not evidence of which version is current in October 2026.

2. How does TypeScript relate to JavaScript?

TypeScript is designed around JavaScript: JavaScript syntax is generally valid TypeScript, and TypeScript code is typically transformed to JavaScript for execution. A type annotation such as let name: string informs checking; it does not make the JavaScript runtime enforce that value’s type. The interviewer wants you to distinguish the source language and checking step from the runtime that executes JavaScript.

3. What is the difference between a type annotation and type inference?

An annotation states the intended type explicitly; inference means the checker derives a type from context or an initializer. In let age: number = 30, the annotation is explicit. In let city = "Oslo", the initializer lets TypeScript infer a string type. An annotation can document or constrain a contract, while inference avoids redundant declarations. The interviewer is testing whether you know both are checked at compile time.

4. What are primitive types in TypeScript?

Common primitive types include string, number, boolean, bigint, and symbol; JavaScript also has null and undefined. For example, const enabled: boolean = true. Use the lowercase type names for primitive values; wrapper types such as String refer to different objects and are usually not the intended annotation. The interviewer is checking basic syntax and runtime awareness.

5. What are literal types?

A literal type describes a specific value rather than every value of a broad primitive type. For example, let mode: "light" | "dark" allows only those two strings. A const initializer often preserves a literal type, whereas a mutable let variable may be inferred more broadly. Literal types are useful for finite options and protocol values; the interviewer is looking for precise modeling rather than a broad string.

6. How do arrays and tuples differ?

An array usually holds zero or more values of one element type, such as number[]. A tuple describes a fixed positional structure, such as const point: [number, number] = [4, 7]. Tuples can also include optional or rest elements in suitable designs. The interviewer wants you to choose based on the data contract: a list of numbers versus a pair whose positions have meaning.

7. How do you describe an object type?

Use an object type, interface, or type alias to state required properties: type User = { id: number; name: string };. An object of that type must provide compatible members. TypeScript primarily checks structural compatibility, so a matching object need not have been created from a class named User. The interviewer is testing whether you model the shape a consumer needs.

8. What does an optional property mean?

A question mark marks a property as optional: type Options = { timeout?: number };. Code using it must account for the possibility that the property is absent, for example with options.timeout ?? 1000. With exactOptionalPropertyTypes, assigning explicit undefined to an optional property is treated differently from omitting it unless undefined is included in its type. The interviewer is checking that “optional” is not mistaken for “always present but maybe undefined.”

9. How do null and undefined work in TypeScript?

They are distinct values with distinct types. When strictNullChecks is enabled, a value typed string cannot be assigned null or undefined without an explicit union such as string | null. A guard like if (value !== null) removes null from the type in that branch. The interviewer is looking for safe handling of missing values and awareness of the compiler option.

10. What is the difference between any and unknown?

any permits operations without checking, so it can let mistakes pass through. unknown can hold any value, but code must narrow or validate it before using it as a specific type. For example, after const raw: unknown = JSON.parse(text), check its shape before accessing properties. Prefer unknown at uncertain boundaries; the interviewer is testing whether you preserve safety rather than opting out of checking.

Functions and object modeling

11. How do you type a function’s parameters and return value?

Annotate parameters and, when it clarifies the contract, the return type: function add(a: number, b: number): number { return a + b; }. The checker verifies calls and the returned expression against those types. TypeScript can infer many return types, but an explicit return type can make a public API easier to review. The interviewer is checking that you can express and enforce a function contract.

12. How do optional parameters differ from default parameters?

An optional parameter may be omitted at the call site; its value is potentially undefined. A default parameter substitutes a value when the argument is omitted or undefined. For example, function greet(name = "friend") accepts an omitted argument and uses the default. The interviewer is testing whether you know how omission and runtime defaulting behave, rather than treating a question mark as a default value.

13. What is a function type?

A function type describes accepted arguments and the result, for example type Mapper = (value: string) => number. A compatible function can be assigned to a variable of that type: const length: Mapper = s => s.length. The interviewer wants you to show that callbacks and function-valued properties can be modeled explicitly, including their input and output relationship.

14. What are function overloads?

Overloads give callers several supported call signatures while an implementation handles them. For example, declare function parse(x: string): number; and function parse(x: number): number;, then provide one implementation accepting the union. Callers see the overload signatures, not the implementation signature as an extra public case. The interviewer is checking whether you can model call patterns more precisely than one overly broad signature.

15. How should callback parameters be typed?

Type the callback where it is declared or supplied so the caller receives contextual parameter types. For example, items.map((item: Item) => item.id) makes the callback input an Item; a well-typed items array often lets TypeScript infer it without the annotation. The interviewer is looking for correct data flow and avoiding unnecessary or unsafe callback casts.

16. What is a call signature?

A call signature describes an object that can be invoked, and may also describe its properties: type Formatter = { (value: string): string; prefix: string };. A value of that type must be callable and have a string prefix. The interviewer is checking that you know functions are values that can also carry properties, not only standalone declarations.

17. What is an index signature?

An index signature describes the type of values accessed through keys of a given type: type Scores = { [name: string]: number };. It is useful for dictionary-like objects, but it does not express a finite set of known keys as precisely as named properties or a mapped type. The interviewer wants you to choose it for genuinely open-ended keys and consider whether a more specific model is possible.

18. What does readonly do?

A readonly property cannot be reassigned through that typed reference: type Point = { readonly x: number };. This is a compile-time restriction, not runtime freezing, and it does not automatically make nested objects immutable. The interviewer is checking that you distinguish a type-level write restriction from deep immutability or runtime enforcement.

19. What is an excess-property check?

When a fresh object literal is assigned to a target type, TypeScript can report unexpected properties: const p: { x: number } = { x: 1, y: 2 } may receive an excess-property diagnostic. Assigning that literal first to a variable can change the check: structural compatibility generally permits a source value with additional members if required members match. The interviewer is testing your understanding of a targeted diagnostic, not a rule that objects must have exactly identical shapes.

20. How do interfaces differ from type aliases?

Both can describe object shapes and both participate in structural compatibility. Interfaces support declaration merging and are commonly used for extendable object contracts; type aliases can name unions, tuples, primitives, and other type expressions. For example, interface User { id: number } and type Result = User | Error. Neither is universally better: the choice depends on the construct and API design. The interviewer is looking for a feature-based comparison.

Unions, intersections, and narrowing

21. What is a union type?

A union says a value may be one of several alternatives: let id: string | number. Until the code narrows it, only operations valid for both constituents are safe. A test such as typeof id === "string" permits string operations in that branch. The interviewer is checking whether you understand that a union represents alternatives, not simultaneous membership in all alternatives.

22. What is an intersection type?

An intersection combines requirements: type Named = { name: string } & { id: number } requires both properties. An intersection is not an either/or choice; it can also become impossible if its constituent requirements conflict. The interviewer is checking that you distinguish “must satisfy both” from a union’s “may be either.”

23. What is type narrowing?

Narrowing uses a runtime check and control-flow analysis to refine a broader declared type at a particular point. Given function show(value: string | number) { if (typeof value === "string") { value.toUpperCase(); } }, the branch treats value as a string. The interviewer wants you to explain the check and resulting type, not just name the syntax.

24. How does typeof narrow a type?

For JavaScript runtime type checks, typeof can refine unions containing primitive types. In if (typeof value === "number"), a string | number value is a number inside that branch. JavaScript’s typeof null result is a historical quirk, so it does not by itself establish that a value is a non-null object. The interviewer is testing both narrowing and knowledge of the runtime check’s limits.

25. How does the in operator narrow types?

The in operator checks whether a property key exists on an object and can narrow a union whose members differ by that property. For example, if one member has swim() and another has fly(), if ("swim" in animal) identifies the branch with swim. The interviewer is checking that the property test matches the modeled alternatives and that the value is object-like before using it.

26. How does instanceof narrow a value?

instanceof checks a runtime prototype-chain relationship and narrows class-based unions accordingly: if (value instanceof Date) value.toISOString(). It is useful for values constructed in a compatible runtime realm, but it is not a general test for arbitrary object shape. The interviewer is looking for a runtime-aware choice of guard.

27. How do equality checks narrow types?

Comparisons can eliminate incompatible union members. If status has type "ready" | "waiting", then if (status === "ready") narrows it to the literal "ready" in that branch. Comparisons between two values can also expose their common possibilities. The interviewer is checking control-flow reasoning rather than relying on casts.

28. What is a discriminated union?

It is a union whose members share a literal-valued property that identifies each case: type Result = { kind: "ok"; value: string } | { kind: "error"; message: string };. A switch (result.kind) safely exposes the fields for the selected case. The interviewer is testing whether you can model related states so invalid combinations are harder to express.

29. What is a user-defined type predicate?

A predicate function declares that a boolean result establishes a type, using a return annotation such as value is Fish: function isFish(x: Fish | Bird): x is Fish { return "swim" in x; }. The compiler trusts the predicate’s declaration, so its implementation must genuinely justify the claim. The interviewer is checking both the syntax and the responsibility not to lie to the checker.

30. How do you make a union switch exhaustive?

After handling every case, assign the remaining value to never: default: const impossible: never = action; return impossible;. If a new union member is added and not handled, that assignment can produce a diagnostic. The interviewer wants to see a method for making future changes visible rather than silently falling through.

Type composition and reusable types

31. What is a generic type?

A generic parameter lets a type or function preserve information supplied by its caller. For example, function identity<T>(value: T): T { return value; } returns the same type it receives. Unlike any, T relates input and output. The interviewer is checking whether you use generics to preserve a real type relationship, not merely to make syntax look reusable.

32. How does generic type inference work?

TypeScript often infers type arguments from function arguments and context: const result = identity("hello") infers a string type for T. You can provide an explicit argument, as in identity<string>("hello"), when inference is insufficient or clarity warrants it. The interviewer is testing whether you understand where type parameters come from and when explicit arguments help.

33. What is a generic constraint?

A constraint limits which types a type parameter may represent: function getLength<T extends { length: number }>(x: T) { return x.length; }. The body may use the guaranteed length member, while callers must supply a compatible value. The interviewer is checking how to preserve a specific input type while requiring just the capabilities the implementation needs.

34. How do you constrain a generic key to an object’s keys?

Use K extends keyof T so the key must be valid for the object: function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] { return obj[key]; }. For { name: "Ada" }, an arbitrary string such as "age" is rejected as a key. The interviewer is checking the relationship between the chosen key and the property’s returned type.

35. What does keyof do?

keyof T produces a type representing the permitted property keys of T. For type User = { id: number; name: string }, keyof User is "id" | "name". It is useful for safe property access and mapped types. The interviewer is looking for an explanation of how it derives keys rather than treating it as a runtime operation.

36. What is an indexed access type?

An indexed access retrieves a property type from another type: type Name = User["name"] yields the type of that property. Combined with generics, T[K] preserves the value type associated with a selected key. The interviewer is checking whether you can reuse a type’s existing definition instead of duplicating it.

37. What is a mapped type?

A mapped type transforms properties from an existing type: type ReadonlyCopy<T> = { readonly [K in keyof T]: T[K] };. It iterates over the keys in the type system and constructs a related type; it does not transform an object at runtime. The interviewer is testing type-level reuse and the boundary between compile-time types and executable code.

38. What is a conditional type?

A conditional type selects a type based on assignability: type Label<T> = T extends string ? "text" : "other";. When applied to a generic type parameter, a conditional type may distribute over a union. The interviewer is checking whether you understand that this is type-level branching, distinct from an if statement executed by JavaScript.

39. Which utility types are commonly used?

Built-in utility types transform existing types. For example, Partial<User> makes properties optional, Pick<User, "id"> selects keys, Omit<User, "password"> removes keys, and Record<Keys, Value> describes a key-to-value mapping. The interviewer is checking that you can compose types from a source of truth rather than maintain duplicate declarations.

40. What is a generic default?

A type parameter may specify a default used when callers do not provide an argument or inference does not choose one: interface Box<T = string> { value: T }. The default does not prevent callers from selecting another type. The interviewer is testing whether you can design convenient generic APIs without hiding their configurable behavior.

Type-system choices and diagnostics

41. When should you choose any rather than unknown?

Use any only when intentionally opting out of checking is justified, for example during a tightly scoped migration or at a boundary that cannot yet be modeled. Use unknown when a value is uncertain but must be inspected before use. const raw: unknown = input forces validation or narrowing; const raw: any does not. The interviewer is looking for a safety-conscious tradeoff, not a claim that any is always forbidden.

42. What is the difference between an annotation and an assertion?

An annotation asks the checker to verify a value against a declared type: const n: number = value must be compatible. An assertion tells the checker to treat an expression as a type the author claims is valid: value as number. Assertions are erased and do not convert or validate the runtime value. The interviewer is testing whether you use checking and runtime validation instead of disguising uncertainty with a cast.

43. What is structural typing?

Structural compatibility is based mainly on members and their types. A value with the required compatible properties can generally be assigned even if it was not declared with the target’s name or inheritance. For example, an object containing { x: 1, y: 2 } can satisfy a type requiring x: number. The interviewer is checking that you do not mistake TypeScript compatibility for nominal class identity.

44. Is TypeScript’s type system completely sound?

No. TypeScript’s documentation explicitly describes places where the system is intentionally unsound, reflecting practical compatibility and JavaScript constraints. Types reduce classes of mistakes but cannot prove all runtime behavior safe; assertions, external values, and mutable data can all complicate assumptions. The interviewer is looking for a balanced account rather than promising that a successful type check guarantees correctness.

45. Why can a wider type reject an operation that works at runtime?

The declared type describes what the checker can establish, not necessarily the specific value that happens to arrive. If value is declared string | number, calling value.toUpperCase() is rejected until a check establishes it is a string. Narrow first with typeof value === "string". The interviewer is testing whether you respond to a diagnostic by proving the case instead of suppressing it.

46. What does never mean?

never represents values that cannot occur, such as the result of a function that always throws or an unreachable remainder after exhaustive narrowing. For example, function fail(): never { throw new Error("failed"); }. It is distinct from void, which describes a function that does not provide a useful return value. The interviewer is checking whether you can use impossible states in type reasoning.

47. What does void mean for a function?

A return type of void indicates that callers should not rely on a returned value: function log(message: string): void { console.log(message); }. It does not mean the same thing as never, because a void-returning function can finish normally. The interviewer is checking that you distinguish “no useful result” from “cannot complete.”

48. What does as const do?

A const assertion preserves literal types and marks object properties and array elements readonly in the resulting type: const action = { type: "start" } as const gives type the literal type "start". It does not freeze the value at runtime. The interviewer is testing precise literal modeling and whether you understand that assertion syntax does not itself enforce runtime immutability.

49. What is a type assertion to any or a double assertion?

Assertions can override ordinary checking, and chaining through unknown can force a conversion the checker would otherwise reject: value as unknown as Target. This does not make the runtime value satisfy Target; it suppresses a type-level objection. Use it only when an external invariant is established elsewhere and document that reason. The interviewer is looking for caution around escape hatches.

50. How should you explain a compiler diagnostic?

Start with the declared type and the operation or assignment the checker cannot justify; then identify a guard, corrected type, or contract change that makes the relationship explicit. For example, for a possibly absent user.email, test for its presence before calling a string method. The interviewer is testing systematic diagnosis, not speed at silencing an error with any or a non-null assertion.

Classes, modules, and declarations

51. What does implements do on a class?

implements checks at compile time that a class instance conforms to an interface or compatible type: class Dog implements Animal { name = "Rex" }. It does not add members, create runtime inheritance, or validate future values. The interviewer is checking that you separate a conformance check from the behavior of extends.

52. What is the difference between a class’s instance side and static side?

The instance side describes members available on constructed objects; the static side describes members on the class constructor itself. For example, class User { static kind = "human"; name = "Ada" } has User.kind on the static side and new User().name on instances. The interviewer is checking that you do not assume an interface implemented by instances automatically checks static members.

53. How do access modifiers work?

public, protected, and private control access according to TypeScript’s class type rules; public is the default. TypeScript’s private modifier is a type-checking restriction, while JavaScript’s #field syntax provides runtime private fields. For example, private token: string is not interchangeable with a runtime security boundary. The interviewer is testing compile-time versus runtime semantics.

54. What is a declaration file?

A declaration file, commonly ending in .d.ts, describes types for JavaScript code or a library without supplying its implementation. A declaration might say declare function greet(name: string): void;. The declaration must accurately match runtime behavior, because the checker relies on it. The interviewer is checking how type information can describe code that is not authored as TypeScript.

55. How do imports and exports work in TypeScript?

Imports and exports express module boundaries, for example export type User = { id: number }; and import type { User } from "./user";. Type-only imports and exports communicate that a symbol is used only for typing and can affect emitted JavaScript according to compiler settings. The interviewer is checking module organization and awareness that type information and runtime values are not identical.

56. What is module detection?

Module detection determines whether a file is treated as a module or as a script, which affects scope and global declarations. An import or export normally marks a file as a module; compiler configuration can also affect detection. The TypeScript 5.9 announcement describes changes and options relevant to its release, but module behavior should be answered for the project’s actual compiler and settings. The interviewer is testing configuration-aware reasoning, not a one-size-fits-all claim.

57. What is tsconfig.json?

tsconfig.json configures a TypeScript project, including which files are included and compiler options such as strictness, target, and module behavior. A setting like "strict": true enables a family of stricter checks. The correct configuration depends on the application, runtime, build pipeline, and compiler version. The interviewer is checking whether you treat configuration as part of the program’s behavior.

58. What does the TypeScript compiler do?

The compiler can type-check a project and emit JavaScript and related outputs according to configuration. A project may instead use another transpiler or bundler for emission while running TypeScript’s checker separately. The interviewer wants you to distinguish checking, transformation, bundling, and execution rather than claiming every TypeScript project uses one identical pipeline.

59. Does TypeScript run in the browser or Node.js by itself?

Browsers and Node.js execute JavaScript, not TypeScript’s erased type annotations. A development or build tool must transform TypeScript syntax as appropriate, or a runtime with TypeScript support must be configured. Types themselves generally do not perform runtime validation. The interviewer is checking whether you can explain the actual execution path in a chosen environment.

60. What are target and module compiler options?

target controls the JavaScript language level targeted by emission, while module controls module-system output and related behavior. Their appropriate values depend on the runtime, bundler, and package setup; they are not interchangeable. TypeScript 5.9’s August 1, 2025 announcement includes support for --module node20, but that release-specific fact does not establish a recommendation for every project or the latest version in October 2026. The interviewer is testing whether you connect settings to the actual host environment.

Practical typing and API design

61. How would you model a safe API response?

Represent known success and failure cases with a discriminated union, such as type ApiResult = { ok: true; data: User } | { ok: false; error: string };. Then branch on ok before accessing case-specific fields. If the response comes from an external service, validate its runtime shape before treating it as ApiResult. The interviewer is checking whether you model states and keep trust boundaries explicit.

62. Do TypeScript types validate JSON from an API?

No. A declaration such as const user = JSON.parse(text) as User only tells the checker to trust the assertion; it does not inspect the JSON. Treat parsed or otherwise untrusted data as unknown, validate its shape at runtime, and only then use a trusted application type. The interviewer is testing whether you know where static checking ends.

63. How would you type a reusable function without losing its input type?

Use a generic parameter that connects the input and output: function first<T>(items: T[]): T | undefined { return items[0]; }. Calling it with number[] yields number | undefined, not any. The interviewer is checking that your abstraction preserves information and honestly represents an empty-array case.

64. How do you type an event handler for several event kinds?

Model event variants with a discriminant, for example type Event = { type: "click"; x: number } | { type: "key"; key: string };, then switch on event.type. Each case exposes only its valid fields. The interviewer is looking for explicit state modeling and safe control-flow narrowing rather than optional fields for every possible property.

65. How should you type a dictionary with known and unknown keys?

If keys are genuinely open-ended, use an index signature or Record<string, Value>; if only a finite set is valid, use a literal union with Record<Key, Value>. For example, type Flags = Record<"beta" | "search", boolean> requires those named keys. The interviewer is testing whether you distinguish a free-form map from a closed domain.

66. How do you model a value that may be absent from a lookup?

Represent absence in the return type, for example function findUser(id: string): User | undefined. Callers must check the result before using a user-only property. The exact behavior of indexed access can depend on settings such as noUncheckedIndexedAccess. The interviewer is looking for honest modeling of missing data and awareness of relevant compiler options.

67. What does strict mode change?

The strict compiler option enables a family of stricter type checks, including checks around nullability and function types. It is a project configuration choice and can expose issues when enabled on an existing codebase. The interviewer is checking that you can explain its broad effect without claiming it eliminates every unsafe behavior.

68. What is a non-null assertion?

The postfix ! tells the checker to treat a value as non-nullish: element!.focus(). It emits no runtime check, so it can fail if the value is actually absent. Prefer a guard or a design that establishes presence. The interviewer is testing whether you know that the operator suppresses uncertainty instead of resolving it.

69. How do you type a promise-returning function?

Use Promise<T> for the resolved value type: async function loadUser(): Promise<User> { return user; }. An async function returns a promise even when its body returns a plain value. The interviewer is checking that you distinguish the eventual result type from the immediate return type.

70. What is the difference between enum and a literal union?

An enum can provide a runtime object as well as a type, depending on its form and compilation; a literal union such as type Direction = "up" | "down" is a type-level set of allowed values. Choose based on whether runtime enum behavior is needed, emitted-code expectations, and project conventions. The interviewer is looking for tradeoffs, not a universal winner.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

More advanced type relationships

71. What is a generic interface?

A generic interface parameterizes a reusable shape: interface Response<T> { data: T; receivedAt: Date }. Response<User> and Response<Product> share the structure while preserving distinct data types. The interviewer is checking whether you can express a family of related types without erasing the member’s specific type.

72. How can you type a function that accepts only one property from an object?

Use a key type parameter constrained by keyof, then access through an indexed type: function read<T, K extends keyof T>(obj: T, key: K): T[K]. The result tracks the chosen key—for a numeric property, the result is numeric. The interviewer is checking whether the input key and output type remain connected.

73. What is a distributive conditional type?

A conditional type using a naked type parameter on the left of extends distributes over a union. For example, type ToArray<T> = T extends unknown ? T[] : never applied to string | number produces string[] | number[]. Wrapping the parameter in a tuple changes that behavior. The interviewer is testing a precise type-level detail and its effect on unions.

74. What is ReturnType?

ReturnType<F> extracts the return type of a function type F. For example, type Output = ReturnType<typeof makeUser> follows the function’s declared or inferred result. It is useful when a derived type should stay aligned with an existing implementation. The interviewer is checking whether you can reuse type information instead of duplicating it.

75. What is Parameters?

Parameters<F> extracts a function’s parameter types as a tuple: type Args = Parameters<typeof send>. This can help build wrappers or forwarding functions while retaining the original function’s call shape. The interviewer is testing familiarity with type utilities and their practical API-composition use.

76. What does Partial<T> do, and what can go wrong?

Partial<T> makes each property of T optional, which is convenient for patch-like inputs: type UserUpdate = Partial<User>. It may be too permissive if some fields must change together or if an empty update is meaningless. The interviewer is checking whether you consider the domain invariant as well as the utility’s syntax.

77. How do Pick and Omit differ?

Pick<T, K> retains selected keys, while Omit<T, K> removes selected keys. For example, Pick<User, "id" | "name"> creates a focused view; Omit<User, "secret"> excludes a field from a derived type. The interviewer is checking that derived types are used intentionally and not mistaken for runtime filtering of objects.

78. What is a readonly array or tuple?

A readonly array, written readonly Item[] or ReadonlyArray<Item>, prevents mutation through that type; readonly [number, number] does likewise for a tuple. This is a compile-time restriction and does not freeze the underlying array at runtime. The interviewer is testing whether your API communicates mutation expectations accurately.

79. What is a template literal type?

A template literal type constructs string types from literal types: type EventName = `on${Capitalize<"click" | "focus">}` describes generated string forms. It can connect naming conventions to keys or events, but complex type-level string manipulation can make APIs hard to read. The interviewer is checking both expressive capability and judgment about maintainability.

80. What are declaration merging and interface augmentation?

Some declarations with the same name, including interfaces, can merge their members; module augmentation can add declarations to an existing module’s type surface. This can be useful for plugin ecosystems but can also make a type’s final shape less obvious. The interviewer is checking whether you know how extensibility affects the source of truth and discoverability.

Project settings and version-aware answers

81. Why should an interview answer mention compiler options?

Some behaviors depend on settings, including null checking, optional-property semantics, unchecked indexed access, module resolution, and emitted syntax. Saying “this is always allowed” can be wrong if the project uses different options. For example, discuss strictNullChecks when explaining assignments involving null. The interviewer is testing whether you qualify claims to the codebase’s actual configuration.

82. What is the difference between type checking and transpilation?

Type checking evaluates whether code conforms to the type system; transpilation transforms source syntax to JavaScript. A toolchain may do one or both, and a bundler may additionally combine modules and assets. The interviewer is checking that you can describe the project’s stages separately rather than assuming that emitting JavaScript proves type correctness.

83. What does tsc --noEmit do?

It runs the TypeScript compiler without emitting output files, which is useful when another tool performs transformation but the project still wants TypeScript diagnostics. The effect depends on the selected project configuration and command invocation. The interviewer is checking practical familiarity with separating checking from a build’s emitted artifacts.

84. Why can a TypeScript upgrade reveal new errors?

Compiler releases can change inference or diagnostics, so previously accepted code may need adjustment. The TypeScript 5.9 announcement notes possible type-argument inference changes that can surface new errors. When discussing a real upgrade, identify the actual before-and-after compiler versions and release notes; the 5.9 announcement does not identify the current October 2026 release. The interviewer is testing careful version-specific reasoning.

85. What is import defer in the TypeScript 5.9 release context?

The TypeScript 5.9 announcement dated August 1, 2025 highlights support for import defer. Its practical availability and behavior depend on the compiler release and module/runtime toolchain in use. Do not infer from that announcement alone that every project can use it or that it is available in later environments without checking their documentation. The interviewer is testing whether you anchor a feature claim to a named release and environment.

86. What is the purpose of module: node20?

The TypeScript 5.9 announcement lists support for --module node20 as a release feature. It is a module-setting option relevant to Node.js-oriented projects, but the correct choice depends on the project’s Node version, package configuration, and tooling. The interviewer is checking whether you connect module settings to the host rather than copying one configuration everywhere.

87. What was notable about the TypeScript 5.9 tsc --init change?

The August 1, 2025 TypeScript 5.9 announcement highlights a minimal updated tsc --init. A generated starter configuration is a starting point, not proof that its settings fit a particular application. Review options against the runtime, module system, and build process. The interviewer is testing configuration judgment rather than memorization of a generated file.

88. How should you answer a question about the latest TypeScript version?

State the version and date you can verify, then distinguish that fact from stable language concepts. The TypeScript 5.9 announcement is dated August 1, 2025, and by October 2026 it cannot establish which release is latest. In an interview, check the team’s compiler version and relevant release notes before making a version-sensitive claim. The interviewer is testing source awareness and intellectual honesty.

89. What is module resolution?

Module resolution is how TypeScript maps an import specifier to a source or declaration file under configured rules. The appropriate strategy depends on the runtime and bundler, and settings may need to align with them. A type-checking resolution that differs from execution can produce confusing failures. The interviewer is looking for awareness that import paths are interpreted by a toolchain, not by types alone.

90. Why might a JavaScript package need separate type declarations?

A JavaScript package can provide a .d.ts declaration or have types supplied separately so TypeScript consumers can check calls to its API. Those declarations must correspond to the actual exported runtime behavior. The interviewer is checking whether you understand the contract between a library’s implementation and its published type surface.

Scenario and reasoning questions

91. How would you model loading, success, and failure states?

Use a discriminated union such as type State = { status: "loading" } | { status: "success"; data: User } | { status: "error"; message: string };. This prevents consumers from assuming success data exists during loading. Branch on status and use an exhaustive check if every state must be handled. The interviewer is testing whether your model prevents contradictory combinations.

92. How would you handle an untrusted value before using it as a user object?

Keep it as unknown, perform runtime checks for the required properties and their value types, and only then pass it into code expecting a User. An assertion like input as User does not perform those checks. The interviewer is checking whether you put validation at the boundary where data enters the trusted part of the program.

93. When would you use a type predicate instead of an assertion?

Use a type predicate when a reusable runtime test can justify a type for every caller: function isUser(x: unknown): x is User. Use an assertion only when an invariant is established outside the expression and cannot be represented through ordinary checks. A predicate can be wrong too, so its implementation must verify the promised structure. The interviewer is checking whether the runtime evidence supports the static claim.

94. How would you choose between a union and optional fields?

Use a union when fields belong to distinct states and should appear together, such as a success result with data versus a failure with an error. Use optional fields when a single shape genuinely permits independent absence. A discriminant makes union cases easy to narrow. The interviewer is testing whether your model rules out invalid combinations instead of making every field optional by default.

95. What do you do when a generic API infers an unexpected type?

Inspect the argument types and the positions from which the type parameter is inferred; then add an explicit type argument or adjust the signature if it better reflects the intended relationship. Avoid widening to any just to silence a problem. TypeScript 5.9’s release note specifically cautions that inference changes can surface errors, so for upgrades compare the actual compiler versions. The interviewer is testing diagnosis and version awareness.

96. How would you explain a structural typing surprise to a teammate?

Show the required members of the target type and compare them with the source value. A value with extra properties can remain structurally compatible in ordinary assignment, even though a fresh object literal may trigger an excess-property diagnostic. The interviewer is checking that you can explain the distinction without claiming TypeScript enforces exact object shapes universally.

97. How would you decide whether to use a class or an interface?

A class provides a runtime constructor and implementation; an interface describes a type contract and has no runtime implementation by itself. A class can implement an interface, while unrelated objects can also satisfy its shape structurally. Choose based on whether runtime identity and behavior are needed or only a contract. The interviewer is testing design reasoning rather than preference for one syntax.

98. How should a public library expose types?

Expose stable, intentional types that describe supported inputs and outputs, and ensure declarations match runtime behavior. Prefer useful named contracts over leaking incidental implementation details; use generics where they preserve caller-specific relationships. The interviewer is checking API design, compatibility, and whether type declarations are treated as part of the public contract.

99. What does a successful TypeScript build prove—and what does it not prove?

It proves that the checked program satisfied the configured compiler’s type rules for the files and settings included in that check. It does not prove runtime values match declarations, all paths work, business logic is correct, or every bug is caught. Pair checking with appropriate tests and validation of external input. The interviewer is looking for a realistic account of the type system’s guarantees and limits.

100. How should you prepare for TypeScript interview questions?

Practice explaining a type from its definition through the code paths that narrow or use it. Be ready to write small examples, state what the checker knows at each point, identify configuration or version assumptions, and explain where runtime validation belongs. Treat a question bank as a way to rehearse reasoning, not as evidence that memorizing definitions alone demonstrates production skill. The interviewer is evaluating how you apply the language to constraints and tradeoffs.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.