JavaScript property lookup can find an object's own property or continue along its prototype chain. An interview answer should distinguish finding a value from deciding where that value is stored. The same property name does not mean every object owns the same data.

What does Object.create do in this example?

const defaults = { theme: "light", pageSize: 20 };
const settings = Object.create(defaults);
console.assert(settings.theme === "light");
console.assert(!Object.hasOwn(settings, "theme"));
settings.theme = "dark";
console.assert(Object.hasOwn(settings, "theme"));
console.assert(defaults.theme === "light");
delete settings.theme;
console.assert(settings.theme === "light");

The initial read finds theme on the prototype. The later assignment creates an own property on settings in this simple data-property case. Deleting that own property reveals the inherited value again. It does not delete the prototype's property.

Is an inherited property the same as copied data?

No. A copy places values into another object, while inheritance leaves lookup connected to another object. If the prototype's value changes and the child has no overriding property, a later read can see that change.

Nested objects need extra care. If a property value is itself a mutable object and two callers use that same value, edits can be shared. That follows from the referenced object, not a special rule that every inherited primitive is mutable.

How do own-property checks differ from in?

The in operator checks the object and its prototype chain. Object.hasOwn checks whether the object itself has the property. Choose the question you mean to ask. An object used as a lookup map can accidentally expose an inherited name if a check assumes every found property is application data.

A value check alone also has limits. A property can exist and contain undefined. Reading undefined does not, by itself, tell you whether the property is absent.

Does setting a property always create a plain own value?

Not in every case. Accessors, read-only descriptors and other object behavior can affect an assignment. The worked example intentionally uses ordinary writable data properties. State those assumptions before presenting its result as a universal assignment rule.

When a follow-up introduces a setter on the prototype, inspect that setter's behavior. Do not keep repeating the result from the simpler data-property case.

What changes when an object has no prototype?

const counts = Object.create(null);
counts["toString"] = 2;
console.assert(Object.hasOwn(counts, "toString"));
console.assert(counts["toString"] === 2);
console.assert(Object.getPrototypeOf(counts) === null);

This can be useful for a dictionary with arbitrary string keys, but it is not an ordinary object with all inherited methods available. A Map is another option with a different interface and key model. Choose deliberately rather than claiming that one is always the fastest or safest container.

What are common interview mistakes?

  • Describing a prototype as a copied set of properties.
  • Using an own-property check when inherited behavior is intended, or the reverse.
  • Assuming undefined proves a key is absent.
  • Ignoring descriptors when an example introduces an accessor.
  • Claiming a class declaration removes JavaScript's prototype mechanism.

For practice, change defaults.pageSize after creating settings, then add a pageSize override on settings. Predict the reads at each point. A clear answer traces the lookup path and names the first matching property, rather than treating inheritance as hidden duplication.

References and next practice

developer.mozilla.org — js objects

Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud