Interview Questions: Fundamentals

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

Declaration merging

Two declarations with the same name combine into one. Interfaces merge; type aliases do not.

Top type

A type every value fits into. unknown is the safe one, any is the unchecked one.

Bottom type

A type no value has. That is never.

Structural typing

Two types are compatible when their shapes match. Names do not matter.

Fresh object literal

An object written directly at the place that expects a type, like const p: Point = { x: 1, y: 2 }. Extra properties are rejected only here.

Narrowing

The compiler making a type smaller inside an if or switch because of a check.

Discriminated union

A union whose members share a property with a different literal value in each, the tag that tells them apart.

Type predicate

A function return type like value is Order that tells the compiler what a true result proves.

satisfies

An operator that checks a value against a type but keeps the value's own, more precise type.

1. 1

   Predict, then check

   In the first example, change the body of withUnknown to if (typeof value === "string") return value.toFixed(1); followed by return "x";. Predict the new error: the old TS18046 is gone because value is now narrowed to string, and toFixed does not exist on string. The panel shows TS2551: Property 'toFixed' does not exist on type 'string'. Did you mean 'fixed'? on that line.

2. 2

   Move the extra property

   In the second example, add the line const direct: Point = { x: 1, y: 2, z: 3 }; just above const stored. Which line does the new TS2353 point at, and under which word? It is the same error as on the fresh line, because both are fresh object literals. Then explain why viaVariable still passes.

3. 3

   Add a case

   In the third example, add "auto" to the Mode object (Auto: "auto"). Predict what label("auto") returns and what the hover on m shows now. The hover is "auto" | "dark" (both are left after the if removes "light"), so return m still compiles and label("auto") returns auto.

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

1. 1

   The problem this solves: TypeScript interviews keep returning to the same few questions, and a memorised definition is easy to spot. Here each answer is a one-line difference plus a proof you can run, so you can explain it instead of reciting it. Type vs interface (Topic 3.4). Both describe the shape of an object, and for plain objects they are almost interchangeable. The real differences are small and testable: an interface can be reopened (declaration merging: two interface Config blocks join into one), while a type alias with the same name twice is an error. Only a type can name a union (A | B), a tuple (a fixed-length array, Topic 5.2), a primitive or a mapped type (Topic 8.4). interface can be extended with extends, and type combines shapes with &. A good default: interface for object shapes that other code may extend, type for everything else. Say that a team rule beats either choice.

2. 2

   any vs unknown vs never. any switches checking off: you can call anything on it, assign it anywhere, and the mistake appears at runtime. unknown is the safe top type: any value fits into it, but you can do nothing with it until you narrow it with typeof, instanceof or a type guard. never is the empty type: no value has it. It is the return type of a function that always throws, the type left over after all cases are handled, and the reason a switch can be checked for completeness. In one line: any = give up, unknown = check first, never = impossible.

3. 3

   Structural typing. TypeScript compares shapes, not names. If an object has every member a type requires, it fits, even if it came from a different class or was never declared as that type. That is why a Vec class with x and y can be passed where a Point interface is expected. The one place it is stricter: a fresh object literal written directly where a type is expected is checked for excess properties, because an extra property there is usually a typo. The same object stored in a variable first passes.

4. 4

   Enums vs literal unions. A string literal union ('light' | 'dark') is erased completely: no JavaScript is emitted, values are plain strings, and it works with erasableSyntaxOnly. An enum is real JavaScript code (an object, with reverse mappings for numeric enums) and numeric enums accept any number in older versions of the checker. The modern pattern is an as const object plus a derived union type, which gives you named values at runtime and a union at compile time, with no extra emit. Use an enum only when you must match existing code that uses one.

5. 5

   Narrowing. The compiler follows your code's control flow and shrinks a union as checks happen. The tools: typeof x === 'string', instanceof, the in operator, equality (=== undefined), truthiness, Array.isArray, a discriminant property on a discriminated union (shape.kind === 'circle'), and your own type predicates (value is Order). Be ready to name the pitfall: truthiness narrowing drops 0 and the empty string too.

6. 6

   **satisfies vs annotation vs as.** An annotation (const x: T = v) checks v and then forgets the precise type: x is just T. as overrides the checker without proving anything. satisfies T (TypeScript 4.9) checks v against T and keeps the precise type of v. Use satisfies for config objects where you want errors on typos and still want palette.accent to be a string, not a union.

7. 7

   Interviewers also love follow-ups: 'what is type erasure?', 'how do you type JSON.parse?', 'what does strict mode turn on?'. The answers below cover them. Practise answering aloud in under a minute each, with one small code example.

8. 8

   Recall, so you know where to revisit each answer: any and unknown are Topic 1.6, never is Topics 2.3 and 5.5, structural typing is Topic 3.5, enums are Topic 5.3, narrowing is Topics 4.3 to 4.7, and satisfies and as are Topic 5.6. Every explain answer below ends with its topic number.

• ↔

  A short, confident answer with one code proof beats a long definition. But do not skip the nuance: say when the 'rule' has exceptions (enums in legacy code, any at an untyped boundary with a comment).

• ↔

  Interviewers sometimes ask for a rule ('always interface'). Give the default and the reason, then name the case that breaks it. That shows judgement, which is what they are scoring.

• I can state the difference between type and interface in one sentence and show declaration merging.

• I can explain any, unknown and never with one example each.

• I can explain excess property checks and why a stored object passes.

• I can replace an enum with a union or an as const object.

• I can name five narrowing tools and one narrowing pitfall.

• I can explain satisfies against an annotation and against as.