JavaScript Prototype Interview Questions

What is the prototype chain?

Every object carries a hidden link to another object, its prototype. When you read a property, the engine checks the object itself first; if the key is not there it follows the link and checks that object, and so on until it either finds the key or reaches `null`. That walk is the prototype chain, and it is the entirety of inheritance in JavaScript. Writing a property, by contrast, never walks the chain — it always creates or updates the key directly on the object you wrote to.

That asymmetry between reading and writing is the source of a whole class of confusing behaviour. Assigning to a property that exists on the prototype does not modify the prototype — it creates a same-named property on the instance that shadows it. Every other instance still sees the original, which is why a bug like this can look like it only affects one object at random.

What is the difference between __proto__ and prototype?

They are related but different things, and mixing them up is the single most common prototype mistake. `prototype` is a property that exists only on functions, and it holds the object that will become the prototype of any instance created by calling that function with `new`. `__proto__` — properly accessed with `Object.getPrototypeOf` — exists on every object and is the actual link the engine follows during lookup.

A useful way to hold it in your head: `prototype` is a plan a function carries for objects it has not made yet, and `__proto__` is the wire an object actually uses. `__proto__` itself is legacy — it is standardised only for web compatibility, and `Object.getPrototypeOf` and `Object.setPrototypeOf` are the supported API. Mentioning that distinction is a cheap way to show you have read the modern documentation.

It is worth knowing why the chain exists at all, because the follow-up "why not just copy the methods onto every object?" does come up. Copying would mean a thousand array instances holding a thousand copies of every array method, and it would make later additions impossible — a method added after an object was created could never reach it. Linking costs one pointer per object and keeps everything live, which is the trade the language made.

What does the new keyword actually do?

This is asked constantly and has a precise four-step answer worth memorising. `new Fn(args)` creates a fresh empty object, links its prototype to `Fn.prototype`, calls `Fn` with `this` bound to that object, and returns the object — unless the constructor explicitly returns a different object, in which case that wins. Returning a primitive is ignored, which surprises people.

The four steps also explain two errors people meet without understanding them. Forgetting `new` on an old-style constructor means `this` is undefined in strict mode, so the assignment throws rather than quietly writing to the global object — which is why class constructors were made to throw explicitly. And an arrow function has no `prototype` property and no own `this`, so it cannot be used with `new` at all; the engine rejects it before any of the four steps run.

Are ES6 classes just sugar over prototypes?

Underneath, yes — a class declaration produces a constructor function with its methods installed on `.prototype`, exactly as the older syntax did by hand. What classes add is a set of guardrails rather than a new object model: the body always runs in strict mode, methods are non-enumerable so they do not show up in `for…in`, calling the class without `new` throws instead of silently polluting the global object, and `extends` wires the chain for both instances and statics.

The one genuine addition is that `extends` also links the constructors themselves, so static methods are inherited — `Dog.someStaticFromAnimal` resolves. The old two-line pattern of `Child.prototype = Object.create(Parent.prototype)` only wired the instance side, which is why static inheritance had to be done manually. That is a good detail to have ready if someone claims classes add nothing at all.

A practical way to see all of this is to log an object in the browser console and expand the `[[Prototype]]` entry. Every method you can call but never defined is sitting one or two levels down that tree, and clicking through it once makes the chain concrete in a way that reading about it does not. It also shows you immediately whether a library has added anything to a built-in prototype.

How do you create an object with a specific prototype?

`Object.create(proto)` makes a new object whose prototype is exactly what you pass, with no constructor involved. Passing `null` produces an object with no prototype at all — no `toString`, no `hasOwnProperty`, nothing inherited — which is genuinely useful for dictionaries where user-controlled keys must not collide with built-in property names.

Null-prototype objects have become more relevant, not less, because prototype pollution is a real vulnerability class. If untrusted input is merged into an object using a naive deep merge, a key called `__proto__` can reach `Object.prototype` and change behaviour across the whole application. Using a null-prototype object for anything built from user input removes the target entirely, which is a strong thing to mention if security comes up.

Why do inherited properties break for…in and how do you avoid it?

`for…in` iterates every enumerable property in the whole chain, not just the object's own. If anything added an enumerable property to `Object.prototype` — an old polyfill, a careless library — every `for…in` loop in the application picks it up. That is why defensive `hasOwnProperty` checks used to be everywhere, and why the modern replacements exist.

The practical rule is to reach for `Object.keys`, `Object.values` or `Object.entries` for plain objects and `for…of` for arrays, leaving `for…in` for the rare case where you genuinely want inherited keys. `Object.hasOwn` is the modern replacement for `hasOwnProperty` and is safe even when an object has a property literally named `hasOwnProperty` — a real hazard when keys come from user input.

One caveat about null-prototype objects worth stating alongside the recommendation: they lose every convenience method, so `dict.toString()` throws and logging one in some environments prints awkwardly. Use them where the keys are untrusted and the object is pure data, and use a `Map` instead when you want both safety and a real API — which is usually the better answer once you are choosing deliberately rather than defaulting to an object literal.

Why put methods on the prototype instead of in the constructor?

Memory and identity. A method defined inside the constructor is created fresh for every instance, so ten thousand objects mean ten thousand identical function objects. A method on the prototype exists once and is shared by every instance through the chain. It also means the functions compare equal across instances, which matters anywhere identity is used for change detection.

What is the difference between prototypal and classical inheritance?

Classical inheritance, as in Java or C++, copies structure from a class — a blueprint that is not itself an object — into instances at creation time. Prototypal inheritance links objects to other objects, and the link is live: adding a method to a prototype makes it immediately available on every existing instance, because lookup happens at read time rather than at creation time.

The other consequence is that there is no separate class entity to reason about: a constructor is an ordinary function and a prototype is an ordinary object, both inspectable and modifiable at runtime. That live behaviour is exactly why monkey-patching built-ins is possible and exactly why it is discouraged — adding to `Array.prototype` changes every array in the program, including ones inside libraries you did not write. Composition is generally the better answer in modern JavaScript: build objects from small functions rather than deep inheritance chains, which is the same advice that has moved React from class hierarchies to hooks.