TypeScript interview questions

What a strong answer covers

• Define `any` as a type that opts out of all type checking, allowing any operation without compile-time errors.
• Define `unknown` as a type-safe counterpart to `any`, requiring type narrowing before performing operations.
• Explain that `unknown` forces developers to explicitly check or assert the type before use, preventing potential runtime errors.
• Provide scenarios where `any` might be used (e.g., quick migration, third-party libraries without types) and `unknown` is preferred (e.g., API responses, user input).

Where people lose the point

• ×Failing to mention that `unknown` requires type narrowing.
• ×Suggesting `any` is always a good default when types are uncertain.
• ×Not highlighting the safety benefits of `unknown` over `any`.

What a strong answer covers

• Explain that `interface` is primarily for defining object shapes and class contracts, supporting declaration merging.
• Explain that `type` aliases can name any type, including primitives, unions, intersections, and object shapes, but do not support declaration merging.
• Discuss `extends` and `implements` keywords: interfaces can extend other interfaces and be implemented by classes; type aliases can use intersection types for similar extension.
• Provide common use cases: interfaces for library/API definitions and class contracts, type aliases for complex union/intersection types or naming primitives.

Where people lose the point

• ×Incorrectly stating that type aliases can be implemented by classes directly.
• ×Forgetting to mention declaration merging as a unique feature of interfaces.
• ×Not providing clear scenarios for when to prefer one over the other.

What a strong answer covers

• Define generics as a way to write components that work with a variety of types while maintaining type safety.
• Provide a simple generic function example, such as an `identity` function or a function that returns an array element.
• Explain how the type parameter (`<T>`) allows the function to operate on different types without losing type information.
• Discuss how generics prevent the need for `any` (improving type safety) and avoid duplicating code for different types (improving reusability).

Where people lose the point

• ×Providing a non-generic function or one that uses `any`.
• ×Failing to clearly explain *how* generics achieve both reusability and type safety.
• ×Not demonstrating the type inference aspect of generics.

What a strong answer covers

• Define union types (`|`) as allowing a value to be one of several types, e.g., `string | number`.
• Provide a practical example for union types, such as a function parameter that accepts different data types.
• Define intersection types (`&`) as combining multiple types into a single type that has all the properties of the combined types.
• Provide a practical example for intersection types, such as merging properties from different interfaces into a new type.

Where people lose the point

• ×Confusing the behavior of union and intersection types.
• ×Providing examples that don't clearly illustrate the practical use cases.
• ×Not explaining the 'OR' vs 'AND' logic behind them.

What a strong answer covers

• Define type guards as runtime checks that narrow down the type of a variable within a certain scope.
• Explain their purpose: to safely work with union types by ensuring the exact type before accessing specific properties or methods.
• Mention common built-in type guards like `typeof`, `instanceof`, and the `in` operator.
• Provide an example of a user-defined type guard using a type predicate (e.g., `value is Type`).

Where people lose the point

• ×Confusing type guards with type assertions.
• ×Failing to explain *why* type guards are necessary (i.e., for union types).
• ×Providing an incorrect or non-functional user-defined type guard example.

What a strong answer covers

• Define `.d.ts` files as files that contain only type declarations, without any implementation code.
• Explain their purpose: to provide type information for existing JavaScript code or libraries, allowing TypeScript projects to use them with type safety.
• Discuss how they enable TypeScript's compiler and IDEs to understand the shape of JavaScript modules, functions, and objects.
• Highlight their importance for interoperability, tooling support (autocompletion, error checking), and maintaining type safety when integrating with untyped JavaScript.

Where people lose the point

• ×Suggesting `.d.ts` files contain executable JavaScript code.
• ×Not emphasizing their role in providing type information for *JavaScript* code.
• ×Failing to mention the benefits for tooling and developer experience.

What a strong answer covers

• Explain that `strict` mode is a configuration option (`"strict": true` in `tsconfig.json`) that enables a suite of stricter type-checking options.
• List some key options enabled by `strict`: `noImplicitAny`, `strictNullChecks`, `strictFunctionTypes`, `strictPropertyInitialization`, `noImplicitThis`, `alwaysStrict`.
• Discuss the benefits: catching more potential errors at compile time, improving code robustness, enhancing maintainability, and promoting better coding practices.
• Emphasize that it leads to more predictable and safer code, reducing runtime bugs, especially in larger codebases.

Where people lose the point

• ×Only mentioning one or two strict options without explaining the overall benefit.
• ×Downplaying the importance of `strictNullChecks`.
• ×Not connecting strict mode to improved code quality and fewer runtime errors.

What a strong answer covers

• Define mapped types as a way to create new types by transforming properties of an existing type, iterating over its keys.
• Explain the syntax, typically using `[P in keyof T]` to iterate over property keys.
• Provide an example of a custom mapped type, such as `Mutable<T>` (removes `readonly`) or `Nullable<T>` (makes all properties nullable).
• Describe a practical use case for the provided example, demonstrating how it dynamically generates a new type based on an input type.

Where people lose the point

• ×Confusing mapped types with utility types without explaining the underlying mechanism.
• ×Providing an example that is not a true mapped type or is syntactically incorrect.
• ×Failing to explain *how* the mapped type transforms the properties.

What a strong answer covers

• Define conditional types as types that select one of two possible types based on a condition, using the form `T extends U ? X : Y`.
• Explain how they allow for type-level logic, enabling types to be determined dynamically based on other types.
• Provide an example, such as `Exclude<T, U>` (a built-in utility type that uses conditional types) or a custom type that extracts properties based on their type.
• Discuss use cases like filtering properties, extracting return types of functions, or creating complex type transformations in libraries.

Where people lose the point

• ×Not clearly explaining the `extends` keyword's role in the condition.
• ×Providing an example that doesn't clearly demonstrate the conditional logic.
• ×Failing to connect conditional types to their power in advanced type manipulation and library authoring.

What a strong answer covers

• Define decorators as special kinds of declarations that can be attached to classes, methods, accessors, properties, or parameters.
• Explain their purpose: to add metadata, modify behavior, or wrap existing code without changing its structure, often used for metaprogramming.
• Mention common use cases: dependency injection frameworks (e.g., Angular), ORMs (e.g., TypeORM), logging, authentication, or validation.
• Provide a simple example of a class decorator (e.g., adding a property) or a method decorator (e.g., logging method calls), explaining its syntax and effect.

Where people lose the point

• ×Confusing decorators with higher-order functions or other design patterns.
• ×Providing an example that is overly complex or syntactically incorrect.
• ×Not explaining that decorators are an experimental feature and require specific `tsconfig.json` settings.

What a strong answer covers

• Define `void` as the return type for functions that do not explicitly return any value, or return `undefined`.
• Provide an example of a function returning `void`, such as a function that performs a side effect.
• Define `never` as the type for values that will never occur, typically used for functions that throw an error or enter an infinite loop.
• Provide an example of a function returning `never`, such as an error-throwing function or an unreachable code path.

Where people lose the point

• ×Stating that `void` means a function returns nothing, rather than `undefined` or no explicit return.
• ×Confusing `never` with `null` or `undefined`.
• ×Not providing clear examples that differentiate their use cases.

What a strong answer covers

• Explain that optional properties are defined using a `?` suffix after the property name (e.g., `name?: string`).
• Discuss the implication that an optional property might be `undefined` at runtime.
• Explain that TypeScript will enforce checks for `undefined` when `strictNullChecks` is enabled, requiring explicit handling (e.g., optional chaining, nullish coalescing, type guards).
• Provide an example of an interface or type alias with an optional property and demonstrate how to safely access it.

Where people lose the point

• ×Forgetting to mention the `?` syntax.
• ×Not discussing the interaction with `strictNullChecks`.
• ×Failing to show how to safely access an optional property.

What a strong answer covers

• Explain type inference as TypeScript's ability to automatically determine the type of a variable, function return, or expression based on its initial value or usage.
• Provide an example of implicit typing (e.g., `let x = 10;` where `x` is inferred as `number`).
• Provide an example of explicit typing (e.g., `let y: string = 'hello';`).
• Discuss when to prefer implicit typing (for simple, obvious cases to reduce verbosity) and explicit typing (for clarity, preventing incorrect inference, or when initializing later).

Where people lose the point

• ×Confusing type inference with `any`.
• ×Not providing clear examples for both implicit and explicit typing.
• ×Failing to explain the trade-offs between verbosity and clarity.

What a strong answer covers

• Define `infer` as a keyword used within the `extends` clause of a conditional type to declare a new type variable.
• Explain its purpose: to 'capture' or 'extract' a type from a type being checked, making that extracted type available for use in the true branch of the conditional type.
• Provide a concrete example, such as `ReturnType<T>` (a built-in utility type) or a custom type that extracts the type of elements from an array.
• Demonstrate how `infer` allows for powerful type transformations by dynamically determining parts of a type.

Where people lose the point

• ×Misunderstanding that `infer` can only be used in the `extends` clause of a conditional type.
• ×Providing an example that doesn't clearly show type extraction.
• ×Failing to explain *why* `infer` is necessary for such extractions.

What a strong answer covers

• Define `enum` as a way to define a set of named constants, making code more readable and maintainable.
• Explain its primary use case: representing a fixed set of related values, such as days of the week, status codes, or user roles.
• Discuss advantages: improved readability, type safety (compiler checks for valid enum members), and self-documenting code.
• Discuss potential drawbacks: enums add runtime overhead (they compile to JavaScript objects), and string enums can be more verbose than union types of string literals.

Where people lose the point

• ×Not mentioning that enums compile to JavaScript objects.
• ×Failing to discuss the alternative of using union types of string literals.
• ×Overstating the performance impact or understating the readability benefits.