Interview Questions
TypeScript Interview Questions and Answers
TypeScript interviews test whether you actually use its type system to catch real bugs, not just add type annotations that could've been 'any' everywhere.
Example: A generic function
TypeScriptfunction firstElement<T>(arr: T[]): T | undefined {
return arr[0];
}
const firstNum = firstElement([1, 2, 3]); // inferred as number | undefined
const firstName = firstElement(['a', 'b']); // inferred as string | undefined
// Without generics, you'd either lose type safety (using 'any')
// or need a separate function per type -- generics keep one function, fully typed.Frequently Asked Questions
Both describe object shapes, and for most everyday use they're interchangeable. Key differences: interfaces can be re-opened and extended later (declaration merging), and are generally preferred for defining object/class shapes as a style convention. type aliases can represent things interfaces can't, like union types (type Status = 'active' | 'inactive') or mapped types -- so type is often preferred for those cases.
A way to write a function, class, or interface that works with a variety of types while still preserving type safety and information about that specific type, rather than falling back to 'any' (which loses all type checking) or duplicating code per type. The example above shows a single function that stays correctly typed regardless of what array type is passed in.
It turns on a bundle of stricter type-checking options together -- including strictNullChecks (null and undefined aren't implicitly assignable to other types, catching a huge class of real null-pointer-style bugs), noImplicitAny (variables/parameters must have an inferable or explicit type, not silently fall back to any), and several others. Most teams enable strict mode from day one, since retrofitting it onto a large existing codebase later is painful.
TypeScript refining a variable's known type within a specific code branch, based on a runtime check -- e.g. after if (typeof value === 'string'), TypeScript knows value is a string for the rest of that block, and lets you call string methods on it without a type error, even if its declared type was a broader union.
any disables type checking entirely for that value -- you can do anything with it, and TypeScript won't complain, even if it's wrong. unknown also accepts any value, but you can't actually do anything with it (call a method, access a property) until you've narrowed its type first with a check -- it's the type-safe alternative when you genuinely don't know a value's type upfront.
Built-in generic helpers for transforming existing types without rewriting them. Partial<T> makes every property of T optional (useful for an "update" function that only needs some fields). Pick<T, K> creates a new type with only the specified subset of properties from T. They're commonly used to derive request/response DTO shapes from a base entity type.
No -- TypeScript is compiled ("transpiled") to plain JavaScript before it runs; the type annotations are stripped out entirely at compile time and have zero effect at runtime. This is an important distinction: TypeScript catches type errors at compile time, but provides no runtime type checking or safety by itself.