How to assess · For hiring teams

How to Assess TypeScript Skills When Hiring

The test formats that actually work for TypeScript, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.

The short answer

Assess TypeScript with a task, not a conversation: type-tightening exercise on an existing module, domain modelling task, ai-scored assessment (e.g. cohesyve) or code review of a pull request. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.

Models the domain with discriminated unions and narrow types rather than optional-everything interfaces
Keeps `any` and non-null assertions out of application code, and can explain the rare cases where `unknown` is the honest choice
Validates at the boundary — API responses, form input, environment — and lets types carry the guarantee inward
Uses generics to remove duplication without producing signatures nobody can read

Build a TypeScript assessment →Read the full article ↓

Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.

TypeScript on a résumé tells you almost nothing. Nearly every JavaScript developer has touched it, and the gap between someone who adds `: any` to make errors go away and someone who uses the type system to make invalid states unrepresentable is the whole job. That gap does not show up in an interview conversation. It shows up when you hand a candidate a real module with loose types and ask them to tighten it without breaking the callers. This page covers how to assess TypeScript the way it is actually used: modelling a domain, working with an existing codebase, and knowing when strictness helps and when it is ceremony.

Why TypeScript is worth testing

The failure mode for a weak TypeScript hire is quiet. The code compiles, the tests pass, and the types are wrong — `any` in the data layer, unchecked casts at the boundaries, unions that should have been discriminated. Six months later the type system is providing no safety and the team has stopped trusting it. Testing surfaces who understands types as a design tool versus who treats them as a linter to be appeased, and that distinction predicts how much of the maintenance burden lands on the rest of the team.

What strong TypeScript looks like

Models the domain with discriminated unions and narrow types rather than optional-everything interfaces
Keeps `any` and non-null assertions out of application code, and can explain the rare cases where `unknown` is the honest choice
Validates at the boundary — API responses, form input, environment — and lets types carry the guarantee inward
Uses generics to remove duplication without producing signatures nobody can read
Knows the difference between structural typing and nominal expectations, and where that bites (branded types, ids)
Reads compiler errors properly instead of casting past them
Configures `strict` and understands the individual flags behind it

Ways to assess TypeScript

Type-tightening exercise on an existing module

Provide a 150–300 line module with loose types (`any` in a few places, an object with twelve optional fields, a function returning `Promise<any>`) and its callers. Ask the candidate to make the types honest without changing runtime behaviour, and to explain each decision.

Pros

Mirrors the real job on most teams — inheriting code, not greenfield. Shows judgement about how far to go.

Cons

Needs a well-prepared fixture; a poor one tests the fixture rather than the candidate.

Best for Mid and senior developers joining an existing codebase.

Domain modelling task

Describe a small domain in prose — an order that can be draft, paid, shipped or refunded, with different fields valid in each state — and ask for the types plus one function that transitions between states. Thirty to forty-five minutes.

Pros

Reveals whether they reach for discriminated unions and exhaustive checks, or a bag of optionals with runtime guards.

Cons

Abstract; does not test working in a real build or with third-party types.

Best for Any level; scales in difficulty by how many states and transitions you specify.

AI-scored assessment (e.g. Cohesyve)

Generate a TypeScript task from your own job description — a modelling problem, a tightening exercise or a code review — with a rubric attached. Each candidate receives a different variant, and an AI scores the written reasoning alongside the code.

Pros

Asynchronous and consistent; a different task per candidate removes the leaked-answer problem; scores the explanation, which is where TypeScript judgement lives.

Cons

Shortlisted finalists still deserve a human read of the code; less suited to debugging a live build configuration.

Best for Screening an applicant pool fairly before spending engineer time on interviews.

Code review of a pull request

Give a diff with four or five deliberate type problems — an unsafe cast, a widening, a missing exhaustive check, a generic that should be concrete — and ask for review comments as they would write them.

Pros

Fast, cheap, and tests the review skill directly, which senior engineers spend a lot of time on.

Cons

Passive; a candidate who reviews well may still write loosely under time pressure.

Best for Senior and lead roles where code review is a large part of the job.

Cohesyve

Run a TypeScript assessment on your next opening

Cohesyve generates a unique TypeScript task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.

Try it free →Book a 30-min demo

What to test

Domain modelling

Whether they use the type system to describe what is and is not possible.

Model a payment that is pending, succeeded or failed, where only failed has an error and only succeeded has a receipt idReplace an interface with nine optional fields with a union that makes the valid combinations explicitWrite an exhaustive switch over a union and show what happens when a new variant is added

Boundaries and runtime safety

Whether they know that types stop at the network and handle that honestly.

Type a `fetch` response so that the rest of the app can trust it, and say where the validation livesExplain when to use `unknown` versus `any` when parsing user inputShow how a branded type prevents passing a user id where an order id is expected

Generics and reuse

Whether they can remove duplication without making the code unreadable.

Write a typed `groupBy` and explain the constraint on the keySimplify an over-generic function signature that has four type parametersType a function that takes a config object and returns an object with the same keys

Working with the compiler

Whether they treat errors as information or as obstacles.

Read a three-line compiler error and say what is actually wrongExplain what `strictNullChecks` changes and why a codebase might turn it on graduallyFix a type error without a cast, or justify the cast

Sample TypeScript questions

Model a form field that is either untouched, valid with a value, or invalid with an error message. Write the type and a function that renders the right thing.

Entry

Look for A discriminated union with a `status` key, and a switch that handles every case — not an object with three optional fields.

Here is a function that returns `Promise<any>` from an API call. Make the rest of the app safe from it.

Mid

Look for Validation at the boundary (a schema library or hand-written guard), a specific return type, and awareness that the type alone is not a guarantee.

When would you reach for a branded or opaque type, and what does it cost?

Mid

Look for Ids and units as examples; the cost is friction at construction sites, and they can say when that trade is not worth it.

A teammate added `// @ts-ignore` above a line to ship a fix. What do you do in review?

Senior

Look for Asks what the error was; distinguishes a genuine library typing bug from a real defect; proposes `@ts-expect-error` with a comment if it must stay.

How would you migrate a large JavaScript codebase to strict TypeScript without stopping feature work?

Senior

Look for Incremental: `allowJs`, per-file conversion, turning on strict flags one at a time, boundaries first, and a way to stop regressions.

Red flags

Reaches for `any` or `as` as the first response to a compiler error
Models every domain object as an interface of optional fields
Cannot say where runtime validation lives in their last project
Describes TypeScript as "JavaScript with annotations" rather than as a modelling tool
Generic signatures grow in complexity without a clear reason

Scoring rubric

Criterion	Weight	What strong looks like
Domain modelling	30%	Invalid states are unrepresentable; unions are discriminated and checked exhaustively.
Boundary safety	25%	External data is validated once, at the edge, and typed truthfully inward.
Readability of types	20%	Generics and utility types serve the reader; a newcomer can follow the signatures.
Compiler fluency	15%	Errors are read and resolved at the cause, with casts justified when used.
Communication	10%	Explains trade-offs — strictness, migration, ceremony — in terms of what it saves the team.

Mistakes hiring teams make

Testing syntax trivia (mapped types, conditional types) instead of modelling judgement
Using a greenfield task when the job is maintaining an existing codebase
Treating "it compiles" as the pass bar when the types may be lying
Not weighting the written explanation — where TypeScript judgement actually shows
Assuming JavaScript experience transfers without testing type-system thinking specifically

Roles that need TypeScript

Frontend DeveloperFull-Stack DeveloperNode.js DeveloperReact DeveloperSoftware EngineerPlatform Engineer

Common questions

Should I test TypeScript separately from JavaScript?

Yes, if the role uses it seriously. JavaScript fluency does not predict type-system judgement; many strong JavaScript developers write TypeScript that provides no safety. A short modelling or tightening task isolates the skill in under an hour.

How long should a TypeScript assessment take?

Thirty to sixty minutes for a modelling or tightening task; two to three hours capped for a take-home that includes tests. Longer than that tests stamina and availability rather than skill.

What level of TypeScript knowledge is enough for a mid-level developer?

Discriminated unions, honest handling of external data, sensible generics, and the ability to read compiler errors. Advanced type-level programming is rarely needed and is a poor filter for most roles.

Can I assess TypeScript with multiple-choice questions?

Only superficially. Multiple choice can check whether someone knows what `unknown` is; it cannot show whether they would model a domain well or validate at a boundary. Use a short written task with a rubric instead.

Cohesyve · Skill assessments for hiring

Test TypeScript before the first interview

Generate a role-specific TypeScript assessment from your job description and see who can do the work before you spend interview time on them.

1,500+

assessments completed

50%

faster time-to-hire

90%

completion rate

5 min

from JD to assessment

No credit card · 10 free candidates · Plans sized to your hiring volume

From the blog

Related skill guides