When a US advert asks for React and TypeScript rather than React alone, it is telling you something about the codebase: bigger, older, more people touching it, and a cost attached to runtime errors. It is also telling you the interview will test the type system on its own.
These adverts often name the hardest part of the job themselves, and they name it correctly: keeping type safety over data that comes back from a backend that changes. Then they give the wrong answer to it. The usual advice is to keep your interfaces updated and use type guards. That advice misses what types actually are, and this page is about that gap, because understanding it is both the right engineering answer and the best thing you can say in the interview.
For pay and the market picture, see our React developer jobs guide.
Your Types Are Not There At Runtime
This is the whole thing, and TypeScript's own documentation states it in one sentence:
"Type annotations never change the runtime behavior of your program."
And the mechanism:
"Type annotations aren't part of JavaScript (or ECMAScript to be pedantic), so there really aren't any browsers or other runtimes that can just run TypeScript unmodified. That's why TypeScript needs a compiler in the first place — it needs some way to strip out or transform any TypeScript-specific code so that you can run it. Most TypeScript-specific code gets erased away, and likewise, here our type annotations were completely erased."
So a compiled React application contains no types at all. The compiler checked what it could see, then deleted the annotations, and what ships is JavaScript.
The direction of travel confirms it rather than changing it. There is a TC39 proposal to allow type annotation syntax in JavaScript itself, whose stated design is that "at runtime, a JavaScript engine ignores them, treating the types as comments". It is at stage 1, which is early, so it is a signal and not a fact about today — but the signal is that annotations are documentation for tools, not instructions to the runtime.
Why That Makes the API Boundary the Real Problem
Now put those two facts together with the job.
You write an interface describing what the server returns. You annotate the response with it. Everything compiles. But nothing about that annotation inspects the bytes that arrive: the type was erased, and fetch hands your code whatever the server sent. An interface describing an API response is a claim about data you have not received yet. If the backend renames a field, sends a string where you expected a number, or returns null for something you marked required, TypeScript raises nothing. The failure surfaces three components later, as an error about a property of undefined, and the type system has actively made it harder to find by asserting the shape was fine.
This is why the brief-style advice — keep your interfaces in step with the backend, add type guards — is only half right. Interfaces going stale is a symptom. The structural answer is:
- Validate at the boundary, at runtime. Parse the response into your type rather than asserting it is one. The check must be real code that runs, because the type is not.
- Derive the type from the validator, not the other way round. Then there is one definition and it cannot drift from what you actually check.
- Treat everything crossing the boundary as unknown. Network responses, URL parameters, local storage, message events and anything from a third-party script are all data you did not type-check, whatever the annotation says.
- Be suspicious of assertions. A type assertion tells the compiler to stop asking. It is sometimes right and it is never a check.
- Turn on the strict options. Most of what people dislike about the language is the compiler declining to accept an assumption they would otherwise have shipped.
Say that in an interview and you will have answered their hardest question with a mechanism rather than a habit.
One Thing Worth Knowing About the Language Itself
JavaScript is a standard. It is ECMA-262, published by Ecma International and revised annually, and no single company decides what goes into it.
TypeScript is not that. It is a language and compiler maintained by Microsoft, and its own documentation is explicit that type annotations "aren't part of JavaScript (or ECMAScript to be pedantic)". That is not a criticism — it is why TypeScript can move quickly — but it has a practical consequence worth understanding when you read an advert asking for a specific version: your type-level code is tied to one vendor's compiler and its release cadence, while the JavaScript it compiles to is tied to a standard. When a codebase pins an old compiler, that is usually what is being pinned.
The TC39 proposal above is the attempt to close that gap. Its champions come from Microsoft, Igalia and Bloomberg, which tells you the intent is serious even at stage 1.
What the Interview Actually Tests
Expect two parts, and prepare them separately — the same structure our JavaScript React guide describes for the language round.
The type system: the difference between an interface and a type alias and when it matters; unions and discriminated unions, which are the ones that model real API responses; narrowing, and what actually narrows a type; generics, and writing a function whose return type depends on its argument; unknown against any, which is the single most revealing question on this list; readonly and immutability; and utility types such as Partial, Pick, Omit and Record.
Typed React specifically: typing props and children; typing hooks, especially a useReducer with a discriminated union of actions; generic components; typing event handlers without reaching for any; and what a context's type should be before a provider has supplied it.
The question behind the questions is whether you understand that the compiler is a static tool. A candidate who answers "unknown forces you to check before you use it, any switches the checker off" is describing exactly the discipline these codebases exist to enforce.
What These Roles Pay
There is no federal wage for a typed React title, and salary-site averages for it swing by tens of thousands of dollars from month to month, which is a sign of thin sampling rather than a moving market. The occupation figures for May 2025 are the honest benchmark: software developers at a $135,980 median, with the lowest tenth under $82,460 and the highest tenth above $214,670; and web developers at $92,650.
Which of those a typed React role is benchmarked against depends on its scope rather than on the language, and our main React guide explains how to read that from the advert. If the role is a contract through a staffing firm, the pay rules are different again and our contract jobs guide covers them.
Frequently Asked Questions
Why do employers ask for TypeScript specifically?
Usually because the codebase is large and long-lived enough that the cost of a runtime error exceeds the cost of the type discipline. It is also a signal that the interview will test the type system separately from React.
Does TypeScript protect me from bad API data?
No. Type annotations never change runtime behaviour and are erased at compile time, so nothing inspects the response when it arrives. Protection requires a runtime parse at the boundary.
What happens to my types when the code runs?
They are gone. TypeScript's documentation states that most TypeScript-specific code "gets erased away" by the compiler, because no browser or runtime executes TypeScript directly.
What is the difference between unknown and any?
unknown accepts any value but forces you to narrow it before use. any turns the checker off for that value. For anything crossing a boundary, unknown is the correct starting point.
Will JavaScript ever have types built in?
There is a TC39 proposal for type annotation syntax, designed so that an engine "ignores them, treating the types as comments". It is at stage 1, so treat it as a direction rather than a plan.
Is TypeScript a standard like JavaScript?
No. JavaScript is standardised as ECMA-262 by Ecma International. TypeScript is maintained by Microsoft, and its own documentation notes that type annotations are not part of ECMAScript.
Do TypeScript roles pay more than JavaScript roles?
No federal source distinguishes them, and salary-site figures for the title move too much month to month to be reliable. Scope decides the band, not the language.
How do I show TypeScript experience without a job?
One project that validates its API responses at the boundary and derives its types from that validation demonstrates the thing these roles actually hire for.
People Also Search For
React TypeScript developer jobs
Larger, longer-lived codebases where type discipline is part of the work rather than a preference.
TypeScript interview questions
Unions and narrowing, generics, and unknown against any. The last one reveals the most.
Runtime validation TypeScript
The real answer to unreliable API data: parse at the boundary and derive the type from the validator.
Type safety API responses
An interface is a claim about data you have not received. Nothing checks it when the data arrives.
TypeScript vs JavaScript jobs
The same occupations and the same pay bands. TypeScript signals codebase size, not a separate market.
Does TypeScript run in the browser
No. It is compiled first, and the annotations are erased in the process.
TypeScript strict mode
Mostly the compiler declining to accept an assumption you would otherwise have shipped. Turn it on.
React developer jobs USA
The market picture, the two occupations and the pay bands are on the main React guide.
Related career guides
- React Developer Jobs in USA — the main guide: the two occupations, the pay bands and the eligibility filter.
- JavaScript React Developer Jobs in USA — the language round, and the two standards a fundamentals interview draws on.
- Frontend Developer Coding Tests in USA — the assessment stage, and the adjustment you are entitled to ask for.
- React JS Developer Contract Jobs in USA — the staffing layer, and the pay rules inside it.
- Senior React Developer Jobs in USA — what the grade changes, including your overtime status.
- Full Stack React Developer Jobs in USA — the same boundary from the server side, where validation is a legal duty rather than a preference.
Official sources
- TypeScript documentation — the handbook on type annotations, runtime behaviour and erasure.
- TC39 — the type annotations proposal, its stage and its stated design.
- Ecma International — ECMA-262, the ECMAScript Language Specification.
- Bureau of Labor Statistics — Occupational Outlook Handbook for software developers and for web developers and digital designers, May 2025 wages.
This article is for general informational purposes. Language specifications, compiler behaviour and wage data change — confirm the current position with the TypeScript documentation, TC39, Ecma International and the Bureau of Labor Statistics before relying on any of it.
