Question 1

What is the prototype chain, and how does property lookup work?

Accepted Answer

Objects link to a prototype via [[Prototype]]; missing properties are looked up on that chain until found or null. Almost every object has an internal [[Prototype]] (accessible via Object.getPrototypeOf / __proto__). When you read obj.prop, the engine looks on obj, then its prototype, and so on. Writing obj.prop = usually sets an own property (unless a setter exists on the chain). Object.create(proto) makes an object with a chosen prototype. null prototype objects (Object.create(null)) are useful as pure dictionaries without inherited Object methods. Understanding the chain explains inheritance before ES6 classes (which are mostly sugar over prototypes).

Question 2

What is the difference between Fn.prototype and obj.__proto__ / [[Prototype]]?

Accepted Answer

Fn.prototype is the object that will become [[Prototype]] of instances created with new Fn(); __proto__ accesses an object's actual prototype link. Functions (that are constructors) have a .prototype property used when new runs: the new object's [[Prototype]] is set to Fn.prototype. Instances do not have a .prototype property by default. __proto__ is a legacy accessor for [[Prototype]]; prefer Object.getPrototypeOf / Object.setPrototypeOf. Changing Fn.prototype after instances exist does not rewire already-created objects unless they still point at the same object reference you mutate.

Question 3

What does the new operator do step by step?

Accepted Answer

Creates an object, sets its prototype to Fn.prototype, binds this to that object while calling Fn, and returns the object (or an explicit object return). Rough algorithm: (1) create a new object; (2) set [[Prototype]] to Constructor.prototype; (3) invoke Constructor with this set to the new object and the given args; (4) if the constructor returns an object (or function), that value is the result of new; otherwise return the created object. Primitives returned from constructors are ignored. This is why constructors usually assign fields on this and put shared methods on .prototype. new.target lets constructors detect construct vs call.

Question 4

What is prototype pollution, and how do you mitigate it in application code?

Accepted Answer

Attackers inject properties into Object.prototype (e.g. via recursive merges of __proto__), affecting all objects; mitigate with safe merges, null-prototype maps, and hardened parsers. If user-controlled JSON is deep-merged unsafely, keys like __proto__ or constructor.prototype can assign to the prototype chain. Then checks like if (obj.isAdmin) may become true on ordinary objects. Mitigations: use Object.create(null) for dictionaries, Map instead of objects, block __proto__/prototype/constructor keys in merges, use libraries with safe defaults, freeze prototypes in locked-down environments, and validate payloads with schema parsers. Prefer Object.hasOwn(obj, key) over truthiness of inherited props.

Question 5

As a tech lead, when (if ever) would you allow mutating built-in prototypes, and what policy would you set?

Accepted Answer

Almost never in app code; if required for polyfills, isolate, feature-detect, and document — prefer composition and well-maintained polyfill packages. 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.

Prototype JavaScript Interview Questions

Other JavaScript interview topics