InterviewPrep.World

Appearance

Sponsor

TypeScript Interviews: Types Versus Runtime Validation ​

By InterviewPrep.World · Published October 19, 2026

Learn how TypeScript types differ from runtime validation and how to explain safe API boundaries, narrowing, and domain models. This guide focuses on explaining decisions clearly and testing your understanding with a concrete scenario.

Separate compiler knowledge from external reality ​

TypeScript helps check relationships between values during development, but its type annotations do not validate an incoming network response. A declared User type cannot make a missing identifier appear in JSON. Begin interview answers by separating trusted values created inside a typed program from untrusted values arriving through APIs, storage, forms, or messages. The boundary between those groups is where validation belongs. Treating a type assertion as proof of correctness simply asks the compiler to stop questioning an assumption; it does not inspect the underlying value.

Narrow unknown values deliberately ​

Imagine an API that should return an object with a string identifier and a display name. Accept the parsed response as unknown, check that it is a non-null object, and inspect the required fields before using them. A small type guard can perform this work for a simple shape. A schema library can help with larger nested structures and useful validation errors. Explain how you handle optional fields, unexpected enum values, and malformed arrays. The important design choice is a clear validation boundary, not the particular syntax used to express it.

Use domain types to prevent invalid combinations ​

A request represented by optional data, optional error, and a loading boolean admits many combinations that make little sense. A discriminated union can instead represent loading, success with data, and failure with an error. Switch on the discriminant to make each branch handle the values actually available there. This is especially useful for payment states, permissions, and multi-step forms. Keep the model proportionate to the problem: a complex generic abstraction can obscure a simple business rule. Prefer names that describe the domain and examples that demonstrate which mistakes become impossible.

Explain the migration and maintenance tradeoffs ​

Turning on strict checks in an existing codebase often exposes hidden assumptions about null values and incomplete objects. Migrate in manageable areas and prioritize boundaries with the greatest operational impact. Avoid replacing every error with any, because that preserves the original uncertainty while creating the appearance of safety. Pair compile-time checks with runtime tests for behavior, and keep validation schemas aligned with the actual service contract. When an interviewer changes the response shape, show where the change is detected and how callers learn about it without relying on a production exception.

Practice and review ​

Open the typescript interview questions practice section and choose a question connected to the ideas above. Before reading its answer, write down your assumptions and attempt an explanation in your own words. Use a small example that another person can follow without needing your project history. Identify the point where your explanation depends on a fact you have not verified, and turn that uncertainty into a focused follow-up task.

Next, change one constraint in your example and explain which part of the solution must change. Ask a practice partner to challenge your reasoning, or record a short walkthrough and listen for missing steps. Keep a brief error log with the original misunderstanding, the correction, and a new example that demonstrates the correction. Revisit that example after a few days. This checks whether you can apply the idea independently rather than recognize a familiar answer.

Continue preparing ​