JavaScript · Prototype · Tech Lead · Architecture
As a tech lead, when (if ever) would you allow mutating built-in prototypes, and what policy would you set?
Short Interview Answer
Almost never in app code; if required for polyfills, isolate, feature-detect, and document — prefer composition and well-maintained polyfill packages.
Detailed Explanation
Mutating `Array.prototype` or `Object.prototype` creates global coupling: version conflicts, enumeration surprises, and breakage across microfrontends/shared realms. Acceptable niches: carefully reviewed polyfills behind feature detection, or locked-down runtimes you fully own. Policy: ban `eslint` `no-extend-native`, require ADR for exceptions, ship polyfills only via core-js/stable pipelines, never put enumerable props on `Object.prototype`, and avoid monkey-patching third-party prototypes. Prefer wrapper utilities or subclassing (`class MyArray extends Array`) when extending behavior. For plugin ecosystems, provide extension points instead of encouraging prototype hacks.
Interview Tip
Show governance thinking, not just 'don't do it'.
Common Mistake
Allowing casual `Array.prototype.foo =` helpers in a shared monorepo.