In August 2025, TypeScript became the most used language on GitHub by monthly contributors, passing Python by about 42,000 contributors, according to GitHub's Octoverse 2025. In the Stack Overflow 2025 survey, 43.6% of respondents said they use it. So "knows TypeScript" now describes most of the web developers you'll meet, and it tells you almost nothing. The real question is whether a candidate uses the type system to make wrong code hard to write, or just adds annotations until the compiler stops complaining.
Key Takeaways
- TypeScript on a resume is table stakes. Screen for how they model data with types, not whether they've used the language.
- Good TypeScript developers type the boundaries: API responses, form input, database rows, and environment config, and they validate them at runtime.
- Watch how often they reach for any, type assertions, and non-null assertions. Frequent use is a skill signal in the wrong direction.
- Decide where the role sits: front end, Node back end, or full stack. The TypeScript skill carries across, the rest of the job does not.
Where This Guide Fits
We have separate guides for Node.js developers and Next.js developers, and a post on TypeScript vs JavaScript for teams still deciding. This one is about the language skill itself, which cuts across all of those roles. If you're hiring a full-stack engineer to work on a TypeScript codebase from database to browser, this is the skill that decides whether that codebase stays maintainable.
What Real TypeScript Skill Looks Like
The weakest TypeScript code is JavaScript with type annotations sprinkled on top. It compiles, and it catches typos, but the types don't describe the business. The strongest TypeScript code makes invalid states impossible to represent.
A few concrete markers:
- Discriminated unions for state. An order is pending, paid, or cancelled, each with different fields, instead of one type with ten optional properties.
- Types derived from one source. Types come from the database schema or an API contract, and change when it changes.
- Runtime validation at the edges. Data from the network is unknown until it's checked, often with a schema library, so the static types can be trusted inside.
- Strict mode on. They know what strict catches and don't want to turn it off.
| Signal | Green flag | Red flag |
|---|---|---|
| Modeling | Uses unions and narrowing to model states | Optional fields everywhere |
| Boundaries | Validates API and form data at runtime | Casts fetch responses with "as" |
| Escape hatches | Uses any and assertions rarely, and explains each one | any to silence errors |
| Generics | Writes simple generics where they remove duplication | Writes clever generics nobody else can read |
| Tooling | Keeps builds and type checks fast in CI | Has never looked at compile times |
The generics row cuts both ways. Some candidates show off with type-level puzzles that are hard for the rest of your team to maintain. You want someone who writes types your mid-level engineers can read.
The Tooling Is Changing
Microsoft announced TypeScript 7 in July 2026 as a native port of the compiler written in Go, with full builds typically 8x to 12x faster. In the announcement, Slack reported its CI type-check time falling from about 7.5 minutes to 1.25 minutes. A senior TypeScript developer should know about this and have an opinion on when your team should move, especially if slow type checks are costing you CI time.
A Practical Exercise
Hand candidates a small, untyped or loosely typed module: a checkout function that takes a cart, applies discounts, and returns an order. It should have a couple of hidden bugs, such as a missing case for an expired coupon. Ask them to type it properly in 90 minutes.
Watch what they do first. Strong candidates model the states before they touch the logic, and the type errors lead them to the bugs. Then ask:
- How would you type the response from our payments API so a schema change breaks the build instead of production?
- When is it fine to use any?
- How would you share types between our front end and back end?
For more on building exercises like this, see how to design a coding challenge.
A Concrete Version
A fintech startup with 14 engineers has a React and Node codebase that's "TypeScript" in name. A quick search finds about 1,100 uses of any and strict mode switched off. The team ships a bug a week where an API field was renamed or came back null.
They hire a senior TypeScript engineer. She doesn't propose a big-bang cleanup. She turns on strict mode one package at a time, starting with the payments module, adds runtime validation to the six external API responses that caused the most incidents, and generates shared types from the API schema so the front end breaks at build time when the back end changes. Over four months, uses of any drop by about 70%, and the rename-and-null class of bug mostly stops reaching production. Nobody stopped shipping features to make it happen.
The Honest Counterpoint
You may not need a TypeScript specialist. If you're a small team building a straightforward product, a strong full-stack developer with solid TypeScript habits covers it, and paying for a type-system expert is over-hiring. And a type system catches a narrow class of bugs. It won't save a bad data model or missing tests.
There's also a trap in hiring the most advanced TypeScript person you can find. The team has to live with their types. If they write code at a level nobody else can maintain, you've made the codebase harder, not safer.
Frequently Asked Questions
Should I hire a TypeScript developer for the front end or back end?
Hire for the part of the stack that needs work. The language skill transfers, but a React specialist and a Node specialist know very different things beyond it.
How do I test TypeScript skill without a long homework assignment?
Use a short typing exercise on real-looking code, like the checkout example above. Ninety minutes shows you how someone models data.
Is TypeScript experience enough, or do they need specific frameworks?
For senior roles, the framework matters less than you'd think. Someone strong in TypeScript and React can learn Next.js quickly. Test fundamentals, then check framework experience.
The Bottom Line
Hire TypeScript developers who model your domain with types, validate data at the edges, and write code the rest of the team can read. Ruzora sends a vetted shortlist of senior TypeScript engineers within 72 hours. Hire TypeScript developers in LATAM, or read how to hire a full-stack developer for the wider role.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
