In TypeScript, `pet` is declared `Dog | Cat`, where both classes declare exactly the same members. Why does `if (pet instanceof Dog)` fail to narrow `pet` to `Dog`, and what change makes the narrowing work?

## The setup ```ts class Dog { constructor(public name: string) {} } class Cat { constructor(public name: string) {} } function speak(pet: Dog | Cat) { if (pet instanceof Dog) { // pet is still Dog | Cat } } ``` The guard looks textbook and does nothing useful. Understanding why is a good test of whether a candidate really believes that TypeScript is structural. ## Assignability, not names When the checker narrows a union with any guard, it walks the constituents and keeps those compatible with the guard's target type. Compatibility here is structural: `Dog` and `Cat` declare the same public members, so a value of type `Cat` is assignable to `Dog` and vice versa. There is nothing in the *type* of `Cat` that says "this is not a Dog" — the class name is not part of its type identity. So the constituent cannot be filtered out, and the branch keeps both. This is not a defect in `instanceof` support. The runtime check is perfectly capable of telling the two apart; the *type system* is the part that cannot express the difference. Narrowing can only ever be as precise as the types involved. ## What instanceof narrows to Mechanically, the right operand must be a value whose type has a construct signature (or `any`), and the type the guard narrows to is the type of that value's `prototype` property. This is why `instanceof` works with a class, and why it also works with a constructor-typed variable rather than only with a literal class name. It also explains subclass narrowing: for `x: Animal` and `class Dog extends Animal`, the guard narrows to `Dog` because `Dog.prototype` has the more specific type. ## The fix: make the classes structurally distinct A `private` member, or an ECMAScript `#private` field, is part of a class's type identity. Two classes that each declare a private member of the same name are *not* compatible — the declarations come from different classes, so the types are incompatible even when the names match. ```ts class Dog { #dog = true; constructor(public name: string) {} } class Cat { #cat = true; constructor(public name: string) {} } function speak(pet: Dog | Cat) { if (pet instanceof Dog) { // pet: Dog } else { // pet: Cat } } ``` This is the same trick as a brand on a plain type: the extra member exists only to stop the structural comparison from succeeding. The `#private` form has the advantage of being genuinely private at runtime as well, so nothing outside the class can forge it. When the values are plain objects rather than class instances, the equivalent — and usually better — answer is a required literal discriminant field, which makes the two types incompatible *and* gives you an equality check that a `switch` can exhaust. ## Related traps worth naming The guard's target must be a constructor. Interfaces are erased, so `x instanceof SomeInterface` is not merely unhelpful — there is no value to put on the right-hand side at all, and the code does not compile. Candidates who reach for it have not internalised that the type layer is erased. Separately, `instanceof` relies on runtime identity of the constructor, which can fail in situations the checker cannot see — the classic ones are values crossing a realm boundary or a bundle containing two copies of the same class. Those are runtime concerns rather than type-layer ones; from the checker's side the guard is simply trusted, which means a `false` result there silently narrows to the *wrong* branch with no complaint. Knowing that the compiler cannot help you with it is the type-level takeaway. ## Interview framing Lead with the reason — structural typing means the two classes are one type — rather than with the fix. Then give the fix (a private or `#private` member, or a discriminant for object unions), and add the mechanical detail that narrowing targets the `prototype` property's type. Mentioning that the check works fine at runtime while the type layer stays ambiguous shows you can separate the two layers, which is what the question is really probing.