What does `Symbol.hasInstance` do to the `instanceof` operator, and why does `fn[Symbol.hasInstance] = handler` usually fail to take effect?

## The hook and where it sits `Symbol.hasInstance` is one of the well-known symbols added in ES2015. It names the method that the `instanceof` operator consults before doing anything else: 1. Evaluate `x instanceof F`; if `F` is not an object, throw a `TypeError`. 2. Get `F[Symbol.hasInstance]`. 3. If it is neither `undefined` nor `null`, call it with `x` as the argument and return the result coerced with `ToBoolean`. 4. Otherwise fall back to the ordinary algorithm, which requires `F` to be callable and walks `x`'s prototype chain against `F.prototype`. The subtlety is that step 3 is essentially always the branch taken. `Function.prototype[Symbol.hasInstance]` exists and holds the default implementation, so every function inherits it. Step 4 exists for the rare object that is callable without inheriting from `Function.prototype`. What that buys you is a documented extension point: the prototype-chain walk is the *default* meaning of `instanceof`, not its only meaning. ## Defining your own In a class, a static computed method is the clean form: ```js class Even { static [Symbol.hasInstance](value) { return Number.isInteger(value) && value % 2 === 0; } } 4 instanceof Even; // true 5 instanceof Even; // false '4' instanceof Even; // false ``` Note what just happened: `4` is a primitive, and the ordinary algorithm returns `false` for every primitive without exception. The hook bypasses that entirely, because the operator never reaches the chain walk. The return value is coerced, not required to be a boolean, so a truthy value counts as `true`. Returning a non-boolean is legal but unkind to readers. ## Why assignment silently does nothing The descriptor of the inherited default is the whole story: ```js Object.getOwnPropertyDescriptor(Function.prototype, Symbol.hasInstance); // { value: [Function], writable: false, enumerable: false, configurable: false } ``` Plain assignment to a property that does not exist as an own property first consults the prototype chain. If it finds a non-writable data property there, the assignment is rejected: it throws a `TypeError` in strict mode and fails silently in sloppy mode. Module code and class bodies are always strict, so in modern code you usually get the error rather than the silence — but the silent version in a plain script is a genuinely confusing bug, because the code looks correct and `instanceof` simply keeps behaving the old way. Both working forms define an own property rather than assigning: ```js function Legacy() {} Object.defineProperty(Legacy, Symbol.hasInstance, { value: (v) => typeof v === 'string' }); 'hi' instanceof Legacy; // true ``` A `static [Symbol.hasInstance]()` in a class body works because class element definition uses the define semantics, not assignment. ## Where it is genuinely used The honest answer is: rarely, and deliberately. - **Abstract-class guards.** A base declares `static [Symbol.hasInstance](x)` that checks for required methods, so `x instanceof Serializable` becomes a capability question rather than a lineage question. That is the structural-typing use, and it survives the duplicate-copy and cross-realm problems that plague chain identity, because it tests the value rather than its ancestry. - **Branded value types.** A type whose values are primitives or plain objects can still answer `instanceof` sensibly. - **Testing and matcher libraries.** A matcher object can accept `instanceof` as a readable spelling of "matches this predicate". Against that, the cost is real: `instanceof` is the one operator readers assume they understand without looking anything up. Overriding it makes a familiar expression mean whatever an arbitrary function decides, and the redefinition is invisible at the call site. A misbehaving implementation — one that throws, or that has side effects — turns every `instanceof` in the codebase into a hazard, since nothing about `x instanceof F` suggests a user function runs. ## What it does not change Two boundaries are worth stating explicitly. The hook affects only `instanceof`; it does not change what `new F()` produces, what the prototype chain contains, or what `Object.getPrototypeOf` returns. And it lives on the *right-hand operand*, so it is the type's author who opts in — a value cannot make itself pass someone else's check by defining the symbol on itself. In an interview, knowing this hook exists is a differentiator rather than a requirement. The strongest answer names it, shows the define-versus-assign trap, gives one honest use case, and then says plainly that redefining a core operator is a decision you justify rather than a technique you reach for.