Concept questionMedium~7 min

Interview question

Why would you prefer `unknown` over `any` for data entering a TypeScript application?

Use unknown safely at TypeScript boundaries

Explains why external data needs runtime validation even when the application uses TypeScript.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

any disables type checking for the value and lets unsafe operations spread through the code. unknown says that a value exists but its shape is not trusted yet, so I have to narrow or validate it before reading properties. For a small value I can use type guards. For an API payload I usually parse it with a runtime schema and convert it into the application's trusted type.

Full answer below

Practice focus

TypeScript trust boundaries, unknown, any, type narrowing, runtime validation, API contracts, and safe error handling.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
TypeScript protects code only after data has been given a trustworthy shape. API responses, browser storage, URL values, and third-party messages arrive at runtime and can violate compile-time assumptions.
any disables type checking for the value and lets unsafe operations spread through the code. unknown says that a value exists but its shape is not trusted yet, so I have to narrow or validate it before reading properties. For a small value I can use type guards. For an API payload I usually parse it with a runtime schema and convert it into the application's trusted type.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A TypeScript annotation or as SomeType assertion does not validate JSON because types are erased at runtime. I keep the untrusted value at the transport boundary, validate required fields and useful constraints, then return either a typed result or a structured parse error. That prevents malformed data from reaching components as if it were valid. It also gives the UI a deliberate failure state instead of a later undefined-property crash.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would centralize parsing around API clients, storage adapters, and message handlers so individual components do not repeat partial checks. The parser should tolerate compatible additive fields while rejecting missing or invalid fields the feature relies on. I would log the endpoint, contract version, and safe validation details without recording sensitive payloads. Contract tests can compare representative backend responses with the frontend schema, but the runtime check remains necessary because deployments, cached data, extensions, and external systems can still drift.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Casting JSON with as and treating the cast as validation.
Using any in an API client and spreading it through component props.
Validating only that an object is non-null.
Showing raw parse details or sensitive payloads to users.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Malformed data fails far away from the boundary.
A backend field change produces undefined values throughout the UI.
Every component invents its own partial payload checks.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is a type guard enough?
How would you report a schema mismatch?
What can a contract test prove that runtime parsing cannot?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Feature Contract

Opening drill

Concept questionMedium~7 min

Interview question

Why would you prefer `unknown` over `any` for data entering a TypeScript application?

Use unknown safely at TypeScript boundaries

Explains why external data needs runtime validation even when the application uses TypeScript.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

TypeScript trust boundaries, unknown, any, type narrowing, runtime validation, API contracts, and safe error handling.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
TypeScript protects code only after data has been given a trustworthy shape. API responses, browser storage, URL values, and third-party messages arrive at runtime and can violate compile-time assumptions.
any disables type checking for the value and lets unsafe operations spread through the code. unknown says that a value exists but its shape is not trusted yet, so I have to narrow or validate it before reading properties. For a small value I can use type guards. For an API payload I usually parse it with a runtime schema and convert it into the application's trusted type.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A TypeScript annotation or as SomeType assertion does not validate JSON because types are erased at runtime. I keep the untrusted value at the transport boundary, validate required fields and useful constraints, then return either a typed result or a structured parse error. That prevents malformed data from reaching components as if it were valid. It also gives the UI a deliberate failure state instead of a later undefined-property crash.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would centralize parsing around API clients, storage adapters, and message handlers so individual components do not repeat partial checks. The parser should tolerate compatible additive fields while rejecting missing or invalid fields the feature relies on. I would log the endpoint, contract version, and safe validation details without recording sensitive payloads. Contract tests can compare representative backend responses with the frontend schema, but the runtime check remains necessary because deployments, cached data, extensions, and external systems can still drift.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Casting JSON with as and treating the cast as validation.
Using any in an API client and spreading it through component props.
Validating only that an object is non-null.
Showing raw parse details or sensitive payloads to users.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Malformed data fails far away from the boundary.
A backend field change produces undefined values throughout the UI.
Every component invents its own partial payload checks.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is a type guard enough?
How would you report a schema mismatch?
What can a contract test prove that runtime parsing cannot?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Feature Contract

Why would you prefer `unknown` over `any` for data entering a TypeScript application?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Why would you prefer `unknown` over `any` for data entering a TypeScript application?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper