Last updated: July 27, 2026
By Robert Ardell, Co-Founder and Strategic Advisor, KORE1
The best TypeScript interview questions test whether a candidate reasons in types under pressure, not whether they can recite that unknown beats any, and each one should come with a clear read on what a strong answer sounds like.
I do not write TypeScript. I have spent twenty years hiring the people who do. Since 2005, our recruiters have sat in on more technical interviews than I could count, across 30-plus U.S. metros, and the pattern I keep seeing has almost nothing to do with which question list the hiring manager pulled off the internet. It has to do with whether anyone in the room knows what a good answer actually sounds like. Nobody teaches that part.
Most TypeScript question roundups are written for the candidate. Study these forty, pass your interview. Fine. This one is written for the person on the other side of the table, the one who has to decide in forty-five minutes whether this engineer will hold up inside a strict, half-million-line codebase or quietly paper over it with any until something breaks at 2 a.m.
Here is my bias, since you should have it before you trust a word. We run a software engineer staffing desk, part of a wider IT staffing services practice, and we get paid only when a client hires someone we found. A guide that told you to wing the interview would send you back to us sooner. It won’t. Plenty of you can run this loop without us, and where that is true, I will say so. I mean it.
How to Use This List, Because Firing All of It at One Person Is a Mistake
A screen is not a quiz. Walk in with thirty questions and a scorecard and you will learn how well someone crams, and nothing about how they think. Six to ten questions, picked for the level you are hiring, with room to chase the answer wherever it wanders. That is the method. Nothing fancier. The rest of this piece is the questions and, more important, how to read the replies.
Match the depth to the seat you are filling. A mid-level product engineer does not need to derive a recursive conditional type on a whiteboard. A staff engineer who cannot explain why your team blocked any in the CI pipeline is a problem no matter how fast they type. Here is roughly where I set the bar by level.
| Level | What you are really probing | One question that separates them |
|---|---|---|
| Junior | Do they understand the types, or copy them from Stack Overflow | “What does turning on strict actually change?” |
| Mid | Can they model real, messy data safely | “Type a function that takes JSON you do not control.” |
| Senior | Do they design types other people have to live inside | “When would you deliberately reach for any?” |
| Staff / Lead | Do they set the rules a whole codebase inherits | “Migrate a 200k-line JS app to TS without freezing the roadmap. Go.” |
Look at the senior question again. The answer you want has the word any in it, said without a flinch. I will come back to why.
The One Thing Every TypeScript Interview Is Actually Measuring
A TypeScript developer is a JavaScript developer who has learned to describe their intentions to a compiler and then let that compiler hold them to it. The skill under every question in this article is the same one. Can they think in types, use the checker as a design tool instead of a nuisance, and tell the difference between the type system helping them and the type system being fought for no good reason?
Everything else is vocabulary. A candidate can memorize the vocabulary in a weekend. Judgment about when to use it takes years, and it is the only thing worth interviewing for. So most of my advice below is not “here is the correct answer.” It is “here is what the correct instinct sounds like.”
Fundamentals That Filter Out the Tutorial Followers
Start here for anyone, at any level. These are cheap to ask and they separate people who have shipped TypeScript from people who have watched a course about it. If a senior candidate stumbles on this section, the resume is doing more talking than the person. Believe the stumble.
What is the difference between any and unknown?
This is the most asked TypeScript question on earth, which is exactly why the answer tells you so much. any switches the type checker off for that value. unknown keeps it on and forces you to prove what the value is before you touch it. Both accept anything coming in. Only unknown makes you do the work going out. That gap is the whole point.
A weak candidate stops at “any turns off type checking.” True, and shallow. The engineer you want keeps going, unprompted, to why it matters: any is contagious, it spreads through every value it touches and silently poisons the types downstream, while unknown quarantines the uncertainty at the boundary where the bad data actually enters. If they mention narrowing an unknown with a type guard before using it, that is a green flag. If they cannot tell you why anyone would prefer the stricter one, that is a real problem for a strict codebase.
| Type | What it does | The answer that impresses |
|---|---|---|
any | Disables the checker. Assignable to and from anything. | “I treat it as tech debt and grep for it in review.” |
unknown | Accepts anything, but you must narrow before use. | “My default for anything crossing a boundary, like a fetch response.” |
never | The type of a value that cannot exist. | “I use it to force exhaustive switch checks at compile time.” |
Interface or type alias, and does the choice matter?
Half the internet will tell you interfaces are for objects and types are for everything else. That is a fine starting answer. The better one is more relaxed. For most object shapes they are interchangeable, interfaces can be reopened and merged through declaration merging, type aliases can express unions and mapped types that interfaces cannot, and past that the choice is mostly team convention. What I am listening for is whether the candidate holds the opinion loosely. Dogma here usually means they learned one rule and never questioned it.
Does TypeScript exist at runtime?
No. And you would be surprised how many people freeze on it. The types are erased during compilation, the browser and Node run plain JavaScript, and nothing you wrote in a type annotation is around to protect you when a real API sends back garbage at midnight. A candidate who deeply understands this will bring up the consequence without being asked. You still have to validate external data at runtime, because the compiler already went home. That instinct is worth more than any syntax trivia in this whole list.
When would you use an enum, and when would you avoid one?
A little bit of a trap, and a good one. Plenty of strong TypeScript teams have quietly stopped using enum because it emits real JavaScript, behaves oddly with tree shaking, and a union of string literals does the same job with zero runtime cost. If a candidate reaches for a union of literals and can say why, they are current. If they only know classic enums, they are not disqualified, just a couple of years behind the conversation. Ask it anyway.
The Type System Under Pressure
Now the mid-to-senior material. This is where you find out if someone can build types, not just consume the ones a library handed them. Ask two or three of these. Not all of them.
Write a generic function with a constraint. Walk me through it.
The classic prompt is a function that reads a property off an object by key, safely. The shape is function getProp<T, K extends keyof T>(obj: T, key: K): T[K]. What I want is not whether they nail the syntax cold, plenty of people blank on keyof under the lights. It is whether they can explain the constraint in plain English: K has to be a real key of T, so you cannot ask for a property that does not exist, and the return type follows the key you passed. If they can teach it back to you clearly, they can teach it to a junior on your team. That is the actual skill.
What is a discriminated union, and how do you make a switch over one exhaustive?
This is my favorite senior question, because it maps directly to real code. A discriminated union is a set of object types that share one literal field, a “kind” or “type” tag, that TypeScript uses to narrow which member you are holding. The follow-up is where it gets interesting. How do you guarantee, at compile time, that you handled every case? The answer you are hoping for is a never assignment in the default branch, so that the day a teammate adds a new variant, the build breaks in exactly the file that forgot about it. An engineer who has felt that pain in production will light up at this question. They have been saved by it. Ask the follow-up.
Explain narrowing. How does TypeScript know a value is a string inside an if block?
Control-flow analysis. The compiler tracks what you have proven about a value as execution moves through the code, so after typeof x === "string", inside that branch, x is a string and the string methods light up. Push a level further for senior folks. Ask them to write a user-defined type guard, a function returning x is Cat, and ask when they would use one instead of a simple typeof or in check. Bonus points if they know TypeScript can now infer some type predicates on its own, added in 5.5, and that they should not reach for a hand-written guard when the compiler will do it for free. Small thing. Real signal.
What do mapped and conditional types buy you?
Careful with this one. It is the question that makes interviewers feel smart and candidates feel small, and it rarely predicts job performance. Most engineers use Partial, Pick, Omit, and Record every week without ever writing a mapped type from scratch, and that is completely fine. Ask it to a candidate hiring into a library or a design-system team, where they will actually author these. Skip it for a product engineer. If you do ask, the green flag is restraint. The best senior engineers I have placed can write a gnarly conditional type and then tell you, unprompted, that they would not, because the next person to read it will hate them. Cleverness that knows when to sit down is the rarest thing on this list. Restraint wins here.
Modern TypeScript, or Who Has Actually Kept Up
The language did not stop moving in 2019. If you are paying senior money, a couple of these will tell you fast whether someone has grown with it or frozen at whatever version their last job shipped. None of this is trivia for its own sake. Each feature solves a problem your team already has.
What does the satisfies operator do, and why did people cheer for it?
satisfies lets you check that a value conforms to a type without widening the value to that type, so you keep the precise, literal inference while still catching mistakes. The usual example is a config object where you want the exact keys and value types preserved for autocomplete, but you also want the compiler to yell if you typo a key. A candidate who uses satisfies comfortably has written real TypeScript in the last couple of years. It landed in 5.0. Small feature. Loud signal.
Have you used the using declaration or explicit resource management?
This one is genuinely current, and I do not expect everyone to have it. TypeScript 5.2 added using, which ties a resource’s cleanup to the scope it lives in, so a database handle or a file gets disposed automatically when the block exits. Most people have not touched it yet. That is fine. What I like is the honest answer: “I have read about it, here is roughly what it does, I have not needed it in anger.” That beats a confident bluff every single time, and how a candidate handles the edge of their own knowledge is one of the most useful things a single question can surface. Honesty travels well.
How do you think about types and AI-assisted coding?
Newer question, and increasingly the one that matters. Per the 2025 Stack Overflow Developer Survey, TypeScript sits among the most-used languages, and a large share of developers now write it with an assistant suggesting types as they go. So the real question is whether they read what the tool wrote. A strong answer sounds like this: the assistant is great at boilerplate types and terrible at knowing when it just stamped any or a subtly wrong union onto something important, so I still review every generated type as if a junior wrote it. So make them read it. An engineer who trusts the autocomplete blindly is going to ship the exact bugs TypeScript exists to prevent.
Beyond Syntax, the Judgment That Predicts the Job
Here is where the internet’s question lists go quiet, and where I have watched the most expensive hiring mistakes get made. Syntax you can teach. Judgment you cannot, not in the time you have. These questions have no crisp right answer, which is the point. Listen for how they reason.
When would you deliberately reach for any?
Told you I would circle back. This is a maturity test dressed up as a syntax question. The junior instinct, drilled in by every tutorial, is that any is always wrong, and they will tell you so proudly. The senior answer is calmer. Sometimes you are wrapping a truly dynamic third-party library with no types, or you are mid-migration and a well-placed any with a // TODO unblocks the team today while you fix the real type this sprint. Bounded and documented, pragmatism beats purity that ships nothing. A candidate who treats any as a moral failing has never had to move a large codebase under a deadline.
An API you do not control sends you JSON. How do you type it safely?
If I could ask a TypeScript candidate one question, it might be this one, because the answer reveals whether they understand that type erasure means the compiler cannot protect you at the network boundary. The weak answer casts the response as SomeType and moves on, which is a lie the compiler happily believes right up until production. The strong answer validates at runtime, usually with a schema library like Zod or Valibot, parsing the unknown payload into a typed value and handling the failure path when the shape is wrong. Named tools. A real boundary. A plan for bad data. That is a hire.
How would you move a large JavaScript codebase to TypeScript?
My favorite question for a lead, because there is no clever type in the answer, only strategy. Watch for the shape of the plan. Turn on the compiler in loose mode first so nothing breaks, allow JS and TS to coexist, convert file by file starting with the code that changes most or hurts most, ratchet up strictness one flag at a time, and keep shipping features the whole way. A candidate who says “we would pause development for a quarter and rewrite it” has just told you they will never actually finish, because no business grants that quarter. The good migrators treat it as gardening, not demolition. Slow. Continuous. No big bang.
Your team keeps hitting a slow tsc build. Where do you look?
A quietly great senior question, because it is the kind of thing that only comes up once you have lived in a real monorepo. Strong answers wander through project references, skipLibCheck, incremental builds, isolating type checking from bundling, and pruning a few monstrous conditional types that make the compiler cry. You are not grading for a specific fix. You are checking whether they have ever owned build health for a team, or only ever run tsc on a tidy little app where speed was never a question. You can hear the difference.
Take-Homes and Live Coding, Briefly
A short opinion, since people always ask. A tiny, typed refactor beats a trivia gauntlet almost every time. Hand a candidate 60 lines of loosely typed code with a bug the types would have caught, and ask them to tighten it and explain what they found. You will learn more in twenty minutes than in an hour of “define covariance.” If you run a take-home, keep it under two hours and pay for it past that, because the senior engineers you actually want have three other offers and no patience for a weekend project. Respect their time and they remember it. So do the ones you pass on.
What Getting This Interview Wrong Actually Costs
I will keep this short, because you already know it in your gut. Software developers are not getting easier to hire. The Bureau of Labor Statistics projects 15 percent growth in software developer roles through 2034, roughly 129,200 openings a year, against a qualified pool that is not expanding at the same pace. A mis-hire on a typed codebase is not just a salary you eat. It is the any debt they leave behind, the reviews they slow down, and the rework the next person inherits. It compounds. If compensation is where your loop keeps stalling, our salary benchmark tool and our TypeScript developer salary guide will get you honest numbers before you make an offer. Across our IT searches, the average role fills in about 17 days once the target is clear. The interview is what makes the target clear.
What Hiring Managers Ask Me Before They Build the Loop
How many TypeScript questions should a technical screen include?
Six to ten, chosen for the level, with time to follow the interesting answers. A longer list tests memory, not thinking. I would rather see four questions explored two layers deep than fifteen skated across, because depth is where the real signal hides and breadth just rewards the candidate who studied the most listicles.
Can I just test JavaScript and assume the TypeScript takes care of itself?
No, and it is a common trap. Strong JavaScript is necessary but not sufficient. A developer can be excellent at closures and async and still spray any across a strict codebase because they never learned to model data in types. Test the JavaScript fundamentals, then test whether they can describe those fundamentals to a compiler.
Is a candidate who reaches for any an automatic no?
Only if they cannot say why. A deliberate, documented any around an untyped library is senior judgment. A reflexive any to make a red squiggle disappear is a habit that will cost you later. The word is not the problem. The reasoning behind it is what you are grading.
Should the take-home be written in TypeScript, or is that overkill?
Yes, use TypeScript, and keep it small. A 60-to-90-line typed refactor tells you more than any algorithm puzzle, because it shows how they model data and read someone else’s types under mild time pressure. Overkill is a four-hour project. A focused, well-scoped exercise respects the good candidates and still filters the weak ones.
What is the fastest way to spot someone leaning on autocomplete instead of understanding?
Ask them to explain a type they wrote, out loud, in plain words. Autocomplete cannot do that. The engineer who truly understands their types can walk you through why the generic is constrained the way it is and what breaks if you loosen it. The one who was pattern-matching goes quiet fast.
How long does it take to hire a strong TypeScript developer?
With a clear target, faster than most teams expect. Across our IT desk the average time-to-hire runs about 17 days once the role is well defined, and the biggest delay is almost never sourcing. It is a hiring team that has not agreed on what a good answer sounds like. Fix that first. If you want help, talk to one of our recruiters and we will build the shortlist while you refine the loop.
Hire for How They Reason About Types, Not How Many They Memorized
Every question in this article is really the same question wearing different clothes. Does this person think in types, and do they know when to stop? The candidate who can explain unknown like a teacher, reach for any without shame when the situation calls for it, and validate the JSON your API had no business sending, will be worth ten who memorized the handbook and understood none of it.
Build the loop around judgment, agree with your team on what a strong answer sounds like before anyone walks in, and you will stop losing good engineers to a scorecard that was measuring the wrong thing. If you would rather not run it alone, we have placed technical talent through direct hire and contract searches since 2005. Either way, ask better questions. The market is too tight to keep guessing.
