TypeScript Interview Questions for AI Training Work

Both can describe an object's shape, but `interface` supports declaration merging, where multiple declarations of the same interface combine, which is useful for extending third-party types. `type` can express unions, intersections, and mapped types that `interface` can't. In practice I default to `interface` for public object shapes meant to be extended, and `type` for unions or anything computed from other types.

TypeScript compares types by their shape, so two differently-named types with the same properties are considered compatible, unlike Java where a class must explicitly implement an interface to satisfy it. That means a plain object literal can satisfy an interface it was never declared against, which is convenient but also means two unrelated types can accidentally be assignable to each other if their shapes happen to overlap.

Generics let a function or type stay flexible across different input types while still preserving type information, instead of falling back to `any` and losing all type safety. A `function firstElement<T>(arr: T[]): T` is a simple example: without the generic, the return type would have to be `any`, but with it, calling the function on a `string[]` correctly infers a `string` return type.

`any` disables type checking entirely, letting you call any method or access any property with no compiler complaints, which defeats the purpose of using TypeScript. `unknown` also accepts any value, but the compiler forces you to narrow it, with a type guard or assertion, before you can do anything with it, which preserves safety while still allowing genuinely unknown input, like data from an external API.

An optional parameter is marked with `?`, like `function f(x: number, y?: number)`, and its type inside the function becomes `number | undefined` since the caller might omit it. A default value, like `function f(x: number, y: number = 10)`, is also technically optional to callers, but inside the function `y` is always `number`, never `undefined`, because TypeScript knows the default fills the gap.

I'd enable `allowJs` and `checkJs` so the compiler can coexist with untouched `.js` files, start with `strict` mode off, and convert files incrementally, prioritizing shared utilities and core modules first since types there benefit everything downstream. I'd tighten `strict` settings gradually rather than all at once, since flipping strict null checks on a large untyped codebase usually surfaces hundreds of errors at once, which is discouraging and hard to review.

First I'd check if `@types/<package>` exists on DefinitelyTyped, which covers most popular untyped libraries. If not, I'd write a minimal `.d.ts` declaration file covering just the functions and shapes I actually use, rather than trying to fully type the whole library upfront. Declaring it as `any` is a last resort I'd avoid, since it silently reintroduces the exact class of bugs TypeScript is meant to catch.

I'd raise it in review rather than a blanket rule against them, since the assertion isn't always wrong, sometimes the developer genuinely knows more than the type checker at that point. But scattered non-null assertions usually mean the underlying type should be narrowed properly, with an early return or a guard clause, so I'd ask whether each one could be replaced with an actual null check that the compiler can verify instead of one the developer is just promising is true.

I changed an API response shape to make a field optional, and the compiler immediately flagged every place downstream that accessed that field without a null check, about a dozen call sites I wouldn't have thought to search for manually. In a plain JavaScript codebase that would have shipped as a runtime crash the first time the field was actually missing, instead of being caught at compile time.

A teammate wanted to keep `strict` mode off to move faster on a new feature. I agreed to ship the feature without it, but proposed a follow-up ticket to turn strict mode on before the module grew further, since retrofitting strictness gets harder the more code accumulates under a loose config. Framing it as a scoped follow-up rather than blocking the current work made the tradeoff easier to agree on.