TypeScript vs JavaScript Interview Questions

Interviewers frequently probe whether candidates understand not just TypeScript syntax but why it exists relative to plain JavaScript, and how the two interoperate in real projects. This topic focuses specifically on contrastive questions: what TypeScript adds on top of JavaScript, the difference between compile-time and runtime type checking, structural versus nominal typing, how TypeScript consumes existing JavaScript code and libraries, and practical strategies for migrating a JavaScript codebase to TypeScript incrementally. Use it to prepare for the 'why TypeScript' portion of an interview, which is common even in roles that are primarily JavaScript-focused.

TypeScript catches an entire class of bugs — wrong argument types, typos in property names, null/undefined access, mismatched function signatures — at compile time instead of in production. It also improves editor tooling significantly: accurate autocomplete, inline documentation, safe rename-refactoring, and jump-to-definition all rely on static types. On larger teams and codebases, types serve as executable documentation of function contracts and data shapes, reducing the cognitive load of understanding unfamiliar code and making large-scale refactors far safer.

TypeScript is a strict syntactic superset: it adds optional static type annotations, interfaces, generics, enums, type aliases, access modifiers on class members (public/private/protected), abstract classes, and advanced type-level features (mapped types, conditional types, template literal types). It does not add new runtime behavior or new JavaScript language features by itself beyond what the configured compilation target already supports — all of TypeScript's own additions are erased during compilation, leaving plain JavaScript.

Compile-time type checking happens when the TypeScript compiler (or an editor's language service) analyzes your source code before it ever runs, flagging type mismatches as errors during development or the build step. Runtime type checking happens while the program executes, using JavaScript's native mechanisms (typeof, instanceof, Array.isArray) or a validation library (zod, io-ts) to inspect actual values. Crucially, TypeScript's types are entirely erased at compile time and provide zero protection at runtime — data coming from an API response, user input, or JSON.parse still needs runtime validation if you want real safety, because TypeScript cannot verify that external data actually matches the declared type.

No. Type annotations, interfaces, and type-only constructs are fully erased during compilation and have no effect on the emitted JavaScript's runtime behavior — a correctly typed program and an equivalent untyped program compile to functionally identical JavaScript (aside from features like enums and the legacy 'parameter properties' shorthand in constructors, which do generate real runtime code). Types exist purely to catch mistakes during development; at runtime, TypeScript's checks simply do not exist anymore.

TypeScript uses structural typing: two types are considered compatible if they have the same shape (matching members and types), regardless of how or where they were declared. In nominal typing (Java, C#), a class must explicitly declare 'implements SomeInterface' to be considered compatible with that interface, even if its shape matches exactly. This means in TypeScript, an object literal or class instance can satisfy an interface it was never explicitly declared to implement, which is more flexible but can occasionally allow unintended compatibility between unrelated types that merely share a shape.

TypeScript relies on separate '.d.ts' declaration files that describe a library's shape (functions, classes, exported values) without containing any implementation. Many popular libraries ship their own .d.ts files; for others, the community-maintained DefinitelyTyped project provides @types/ packages (e.g. npm install --save-dev @types/lodash) that can be installed alongside a plain JS library. If no declarations exist at all, TypeScript treats the imported values as 'any' by default (or errors under certain settings), and a developer can write custom ambient declarations to add type safety incrementally.

With 'checkJs': true (and 'allowJs': true) in tsconfig.json, the TypeScript compiler will type-check .js files in place using inferred types and JSDoc comments, without requiring a rename to .ts. Developers can add JSDoc annotations like '/** @param {string} name */' to get real type checking and editor autocomplete on plain JavaScript functions. This is a common intermediate step before a full migration, letting teams get typing benefits file by file without committing to TypeScript syntax everywhere at once.

A common approach: (1) add a tsconfig.json with 'allowJs': true and 'checkJs': false initially so both .js and .ts files can coexist and compile together; (2) rename files to .ts/.tsx incrementally, starting with leaf modules that have few dependencies, fixing type errors as they surface; (3) start with loose settings (noImplicitAny: false) to avoid being overwhelmed, then progressively tighten to full 'strict': true as coverage grows; (4) add @types packages for third-party dependencies; (5) prioritize converting shared utility/data-model files early since their types propagate benefits throughout the codebase. This avoids a risky 'big bang' rewrite.

Because by the time code is compiled, all type errors should already have been caught and fixed — 'tsc' refuses (by default) to consider a build fully clean if there are type errors, though it can still emit output alongside those errors unless noEmitOnError is set. Once compiled, there is no type information left to check, so any type-related bug that slipped past compile time (for example due to an 'any' type, a type assertion using 'as', or invalid external data) will simply manifest as a normal JavaScript runtime error, like calling a method on undefined, with no TypeScript-specific runtime guard involved.

If the function lives in a .js file without 'checkJs' enabled, TypeScript does not check it at all — parameters are effectively 'any' and no error is raised regardless of what arguments are passed. If 'checkJs' is enabled but no JSDoc annotations exist, TypeScript still infers parameter types where possible (e.g., from default values or usage) but otherwise treats untyped parameters as implicit 'any', meaning many mismatches will still go undetected until JSDoc types or a .ts rewrite are added.

Almost everything in TypeScript is purely a compile-time construct that gets erased, but a few features do generate actual runtime JavaScript code: numeric and string enums compile into real objects; the legacy class 'parameter properties' shorthand (constructor(private x: number)) generates real assignment code; and namespaces compile into IIFE-wrapped objects. Interfaces, type aliases, generics, and type annotations, by contrast, are 100% erased and produce zero runtime footprint.

No, not on its own. const data = await response.json() as User; uses a type assertion, which tells the compiler 'trust me, treat this as a User' without performing any real verification — if the API actually returns a different shape, TypeScript will not catch the mismatch, and the bug will only surface as a runtime error (e.g., undefined.someMethod()) when the code accesses a property that isn't really there. To genuinely guard against this, you need runtime validation (a library like zod, or manual property checks) in addition to the TypeScript type.