Full Stack Developer Interview Question

What is the difference between any and unknown in TypeScript, and when do you reach for each?

What the interviewer is probing, how to structure your answer, and a spoken example you can adapt.

Quick answer

any switches off type checking for that value, so every property access and call compiles even when it is wrong. unknown accepts any value coming in but forces you to narrow it with a typeof check, a type guard or a schema parse before you can use it. Reach for unknown at trust boundaries like fetch responses and JSON.parse. Reach for any almost never.

Why interviewers ask this

This separates people who use the type system from people who fight it. The interviewer is checking whether you think about trust boundaries, whether you know that TypeScript types evaporate at runtime, and whether you validate data arriving from a network or a database rather than asserting a shape and hoping. It also surfaces how you handle legacy code, because the honest answer usually involves a migration story rather than purity.

How to structure your answer

  • Define both in one sentence each.
  • Say that types are erased at runtime, so validation is separate.
  • Name the boundaries where unknown belongs.
  • Give the narrow case where any is still acceptable.

Example answer

Spoken example, first person

My rule is that any is a bug I have not found yet. If I write any, I have told the compiler to stop helping and the failure surfaces at runtime in a user's browser instead. unknown is the honest version: it says I do not know what this is, and the compiler makes me prove the shape before I touch it. In practice that means anything crossing a trust boundary starts as unknown. A fetch response, a webhook body, whatever comes out of JSON.parse or localStorage. At a fintech I worked at we hand wrote our API response types and they drifted from the backend within about two months, so a field that became nullable started crashing a table render in production. We moved to parsing with zod at the boundary and inferring the TypeScript types from the schema, and that whole class of bug disappeared. The only place I still allow any is inside a tightly scoped generic helper, and even there unknown plus a guard usually does the job.

Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.

See how it works

Follow-up questions to expect

  • How do you keep those schemas in sync with the backend?
  • What is the difference between a type assertion and a type guard here?
  • How would you introduce this into a codebase already full of any?

Related full stack developer questions

Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.

Predict my questions

Rehearse the hard questions before they are asked

Practise with a live copilot, then walk in ready. A $29 Session Pass gets you through the interview with no subscription and no lock-in.

Get GhostPilot