277 JavaScript Frontend Developer Interview Questions & Answers

The new operator creates a fresh object, chooses its prototype from the constructor, calls the constructor with that new object as this, and then decides what value to return. If the constructor returns an object or function, that value replaces the fresh object. If it returns nothing or returns a primitive value, JavaScript returns the fresh object. The target must also be constructable. For example, an arrow function cannot be used with new.

The main idea is that new creates an object by following a fixed set of steps. JavaScript prepares a fresh object and connects it to an object used for shared behavior. It then runs the constructor while making the fresh object the current object. What the constructor returns can change the final result. Returning no value keeps the fresh object. Returning a simple value also keeps it. Returning another object replaces it. JavaScript also requires the value after new to support object construction. If it does not, JavaScript reports an error instead of creating an instance.

1. Should I explain both constructor functions and classes?
2. Would you like me to show the return value rule with a small code example?

For new Constructor(arg), JavaScript first checks that the target can be used as a constructor. If it is not constructable, new throws a TypeError.

For a constructable target, JavaScript creates a fresh ordinary object. Its prototype is normally taken from Constructor.prototype. If that property is an object, the fresh object uses it as its prototype. If that property is not an object, JavaScript uses the appropriate default intrinsic prototype instead.

Next, JavaScript runs the constructor with the fresh object as this. The arguments in the new expression are passed to the constructor. For example, this.name = name adds a name property to the fresh object.

JavaScript then applies the constructor return rule. If the constructor finishes without an explicit return value, the fresh object is returned. If it explicitly returns a primitive value such as a number, string, boolean, symbol, bigint, null, or undefined, that value does not replace the fresh object. If it returns an object or function, that returned value becomes the result instead.

So a constructor that sets this.name and returns nothing produces the fresh instance. A constructor that returns 42 still produces the fresh instance. A constructor that returns { replacement: true } produces that replacement object instead.

This behavior matters in production when working with classes, constructor functions, prototype methods, inheritance, libraries, and older frontend code. The construction itself has no useful single asymptotic complexity because the constructor can perform arbitrary work. The main allocation is the new object, unless the constructor returns another object instead.

The example uses three constructable functions. ReturnsNothing stores a name on this and has no explicit return value, so new returns the fresh instance. ReturnsPrimitive stores a name and returns the number 42. JavaScript ignores that primitive result and still returns the fresh instance. ReturnsObject stores a name and then returns another object, so that returned object replaces the fresh instance. The example also uses an arrow function to show that a nonconstructable target causes new to throw a TypeError.

A common mistake is saying that new always returns whatever the constructor returns. That is false because primitive return values are ignored. Another mistake is forgetting that the fresh object's prototype normally comes from the constructor's prototype property. Candidates may also assume that every function can be used with new. Arrow functions are callable but not constructable. Another mistake is assuming that changes made through this must appear in the final result even when the constructor explicitly returns another object. It is also incorrect to treat null as an object return for this rule. Returning null does not replace the fresh instance.

Explain the behavior in order: verify the target is constructable, create the object, choose its prototype, call the constructor with that object as this, then apply the return rule. Give the three requested cases next: no return value, primitive return value, and object return value. Finish by mentioning that a nonconstructable target causes a TypeError.

Static fields and static initialization blocks run when JavaScript evaluates the class definition, not when an instance is created. They run once for that class evaluation and in the order they appear. The base class is already evaluated before the subclass static elements run. Static methods are inherited, and this inside a static method depends on which constructor receives the call. Creating objects with new does not run static initialization again.

Static values belong to the class itself instead of each object created from the class. JavaScript creates these values while it creates the class. It processes them from top to bottom. A child class is created after its parent class is available. The child can also access class level values and functions from its parent. Creating a normal object later does not repeat this class setup. This matters when a program needs shared settings, counters, registration information, or setup work that should happen once when a class definition is evaluated.

1. Should I explain both a base class and a subclass?
2. Should I include how this behaves inside an inherited static method?

A static field initializer runs while JavaScript evaluates the class definition. A static initialization block also runs during that class evaluation. Static fields and static blocks are processed in source order, so a later static element can observe values or changes produced by an earlier static element.

For a base class, its static elements finish while that class is being evaluated. When JavaScript evaluates a subclass, the base class constructor already exists. JavaScript then processes the subclass static elements in their own source order. This gives a clear sequence: base class setup first, then subclass setup.

Static properties and static methods can be inherited through the relationship between constructor objects. If Base defines a static method named record, Child can call Child.record(). Inside that call, this is Child because Child is the receiver of the call. If Base.record() is called, this is Base.

Inside a static field initializer or static block, this refers to the class constructor currently being initialized. This makes it possible to compute class level values or record initialization work.

Creating an instance with new Child() does not evaluate the class definition again. Instance construction runs the constructor and initializes instance fields, but it does not rerun static fields or static blocks. Static initialization runs again only when JavaScript evaluates a separate class definition again.

A practical limitation is shared mutable state. If a static field contains an object or array and a subclass inherits access to it, both classes may refer to the same object unless the subclass defines its own static value. Production code should control such mutations carefully.

The example records the order in which static elements run. Base first creates its log, then its name label, then its computed name, and then its static block records that Base initialization happened. Child is evaluated afterward. Its static field and static block then run. Child inherits the Base static method named record. Calling Child.record uses Child as this, while calling Base.record uses Base as this. Because Child inherits the same log array and does not define its own log, changes made through Child are visible through Base.log as well. Constructing Base or Child instances afterward does not add static initialization entries because static elements are not part of instance construction.

A common mistake is saying static initialization runs when the first object is created. It actually runs when the class definition is evaluated. Another mistake is assuming every new instance reruns a static block. It does not. Candidates also sometimes think an inherited static method always uses the base class as this. The receiver matters, so Child.record() uses Child as this. Another mistake is forgetting that an inherited static object can still be the same object owned by the base class. Mutating that object through the subclass can therefore affect what the base class sees.

Start by saying that static fields and static blocks run during class evaluation, not during new. Then explain source order, base class before subclass, and the receiver rule for this in static methods. Use one small execution log to show the behavior clearly.

===, Object.is, and SameValueZero are almost the same, but NaN and signed zero show their differences. === says NaN is not equal to itself and treats positive zero and negative zero as equal. Object.is says NaN equals itself and distinguishes positive zero from negative zero. SameValueZero says NaN equals itself but treats both zero signs as equal. Set and Array.prototype.includes use SameValueZero. For objects, all three compare identity, so two separate objects with the same contents are not equal.

JavaScript has several rules for deciding whether two values should count as the same. Most ordinary values give the same result with all three rules, but two unusual number cases behave differently. One case is NaN, which represents a numeric result that is not a normal number. The other case is zero, because JavaScript can preserve a positive sign or a negative sign on zero. Objects are also important because JavaScript checks whether two values refer to the same object, rather than checking whether their contents merely look the same.

1. Would you like me to compare the important cases with a small code example?
2. Should I also explain how Set and Array.prototype.includes use SameValueZero?

Start with the practical rule. Use === for normal strict comparisons. Use Object.is when the exact behavior of NaN or signed zero matters. Remember that Set and Array.prototype.includes use SameValueZero.

For ordinary primitive values, all three relations usually agree. For example, the primitive strings "hello" and "hello" compare as equal with ===, Object.is, and SameValueZero.

The first important case is NaN. NaN === NaN is false. Object.is(NaN, NaN) is true. SameValueZero also treats NaN as equal to itself. This is why [NaN].includes(NaN) returns true. A Set also treats repeated NaN values as the same entry.

The second important case is signed zero. JavaScript has positive zero and negative zero. Strict equality treats them as equal, so 0 === -0 is true. SameValueZero also treats them as equal. Object.is is different because Object.is(0, -0) is false. This makes Object.is useful when the sign of zero must be preserved as part of the comparison.

For objects, all three relations compare object identity. Two separately created objects are not equal even when their properties contain the same values. A reference compared with itself is equal.

These comparisons do not copy or allocate the compared values. The important production concern is choosing the equality behavior that matches the operation. In most application logic, === is the normal choice. For collection membership with Set or includes, understand that SameValueZero makes NaN searchable and combines both zero signs.

The example compares the same important values under the three equality behaviors. It shows that ordinary primitive strings agree under all three rules. It shows that NaN differs under strict equality, while signed zero differs under Object.is. It also shows that two separate objects are different, while the same object reference is equal. Set and Array.prototype.includes demonstrate SameValueZero because JavaScript does not provide SameValueZero as a standalone comparison function.

A common mistake is saying that Object.is is simply a stricter version of ===. It is not. They specifically disagree for NaN and signed zero. Another mistake is assuming Array.prototype.includes uses ===. It uses SameValueZero, so [NaN].includes(NaN) is true. Developers also sometimes expect objects with identical properties to compare as equal. These equality relations compare object identity, so two separately created objects are different. Another mistake is assuming a Set can keep positive zero and negative zero as separate values. SameValueZero treats them as the same value.

State the two special number cases first. Say that Object.is treats NaN as equal to itself and distinguishes the two zero signs. Then say that SameValueZero also treats NaN as equal to itself but considers both zero signs equal. Finish by noting that Set and Array.prototype.includes use SameValueZero and that objects are compared by identity.

An inherited writable data property is usually shadowed when I assign the same property name on the child, because JavaScript creates an own property on the child. An inherited setter behaves differently. Assignment calls the setter and does not automatically create an own property with that name. If I delete a shadowing own property, normal lookup can see the inherited property again. I can use Object.hasOwn to confirm whether the property belongs directly to the child.

A child object can use values that come from another object above it. If the child gets its own value with the same name, that value can hide the older one. Removing the child value can make the older value visible again. There is one important special case. If the older object reacts when a value is assigned, the assignment can trigger that reaction instead of storing a new value on the child. We should check which object really owns each value after every change.

1. Should I show both a normal stored value and a property that reacts to assignment?
2. Should I verify ownership with Object.hasOwn after assignment and deletion?

Suppose proto has a writable data property named score with value 10. A child object inherits from proto. Reading child.score first returns 10 because child has no own score, so property lookup continues to proto.

When we run child.score = 20, JavaScript finds the inherited data property and sees that it is writable. The assignment creates an own score property on child with value 20. That own property now shadows the inherited score. The original proto.score is still 10. Object.hasOwn(child, "score") returns true.

Now consider an inherited accessor named status that has a setter. When we assign child.status = "ready", JavaScript calls the inherited setter with child as this. Assignment does not automatically create an own status property. In this example, the setter stores the received value in child.savedStatus. Object.hasOwn(child, "status") therefore remains false.

If we delete child.score, only the own score property is removed. The prototype property is not deleted. Reading child.score again continues through the prototype chain, finds proto.score, and returns 10. Object.hasOwn(child, "score") now returns false.

This behavior matters when objects inherit shared defaults or shared behavior. Shadowing is useful when one object needs its own value. An inherited setter can validate, transform, or redirect an assignment. A key limitation is that an inherited data property that is not writable blocks normal assignment to that name. Another important point is that delete only removes a configurable own property from the object where delete is used. Prototype based designs can save repeated definitions, but they can also make ownership less obvious, so production code should use clear conventions and ownership checks when that distinction matters.

The example creates proto with two inherited properties. score is a writable data property. status is an accessor with a setter and getter. child inherits from proto. Assigning child.score creates an own score property that shadows proto.score. Assigning child.status calls the inherited setter with child as this. The setter stores the value in child.savedStatus, so child does not gain an own status property. Deleting child.score removes the own shadowing property, so reading child.score finds the inherited value 10 again. Object.hasOwn verifies whether score and status belong directly to child.

A common mistake is assuming every assignment creates an own property. An inherited setter can receive the assignment instead. Another mistake is thinking that shadowing changes the prototype property. It does not. The own property only hides it during lookup. Developers may also expect delete child.score to delete proto.score, but delete only targets an own property on child. Another mistake is using the in operator as an ownership check because in reports both own and inherited properties. Object.hasOwn checks direct ownership. It is also incorrect to assume normal assignment can shadow an inherited data property that is not writable.

Explain the two assignment cases separately. First show a writable inherited data property that becomes shadowed by an own property. Then show an inherited setter that receives the assignment without automatically creating that property on the child. Finish by deleting the shadowing property and using Object.hasOwn to prove that the inherited value is visible again.

#value gives real language enforced privacy, while _value is only a normal property that follows a naming convention. Code outside the declaring class cannot directly use #value, and a subclass body cannot directly use the parent class private name. Private fields are also hidden from normal property reflection and JSON serialization. In contrast, _value can be read, changed, listed, serialized, or dynamically accessed with a string such as obj["_value"]. A private field cannot be dynamically addressed that way because #value is a private name, not a normal string property key.

The practical difference is simple. A name that starts with an underscore only asks other programmers not to touch it. Nothing in the language stops them from reading or changing it. A name that starts with # has a stronger rule. JavaScript itself controls where that value can be used. A child class does not automatically get permission to use the parent private name. Normal ways of listing object values do not reveal it. Converting the object to JSON does not include it either. This makes #value useful when a value must stay behind the class public behavior.

1. Should I compare inheritance behavior as well as direct access?
2. Would you like me to show how reflection and JSON serialization treat both forms?

I would start with one class that contains both #value and _value.

_value is an ordinary JavaScript property. The underscore has no special meaning to the language. Any code with the object can normally use obj._value or obj["_value"]. If it is an enumerable own property, it can appear in Object.keys and JSON.stringify. It also appears in Object.getOwnPropertyNames because that method returns ordinary own string properties whether they are enumerable or not.

#value is different. It is a private field declared by the class. Code in a place where that private name is not in scope cannot write obj.#value. JavaScript rejects that source because the private name is not available there.

JavaScript also performs a brand check when private access happens. In simple terms, the object must actually have the private field created by that class. A method cannot successfully read its private field from an unrelated object just because that object has a property with similar text.

Inheritance is strict about private names. An instance of a subclass can still contain the parent class private field because the parent constructor initializes it. Parent class methods can access that field on the subclass instance. However, code written in the subclass body cannot directly use the parent private name. If the subclass declares its own #value, that is a different private field.

Private fields are not normal properties with string keys. Therefore obj["#value"] does not reach the private field. It only looks for an ordinary public property whose string key is #value. Private fields are also absent from normal property reflection and JSON serialization.

I use #value when the class should enforce an internal boundary. I use _value when a project only needs a visible convention or when external tools intentionally need ordinary property access.

The example creates one class with both forms. Public methods read and update the real private field because those methods are declared where #value is available. The underscore property is accessed directly and through a string key to show that it is an ordinary property. The example also shows that normal reflection and JSON serialization see _value but not #value. A static method uses #value in object to perform a private brand check. The subclass shows that parent methods can still read the parent private field on a subclass instance, while the subclass body cannot directly use the parent private name.

A common mistake is saying that _value is private. It is not. The underscore only communicates intent. Another mistake is trying to access a private field with obj["#value"]. That searches for a normal string property and does not access the private field. Candidates also sometimes say that subclass instances do not contain parent private fields. They can contain them when the parent constructor initializes them. The important restriction is that the subclass body cannot directly use the parent private name. Another mistake is expecting Object.keys, Object.getOwnPropertyNames, or JSON.stringify to expose private fields. They do not. Finally, a private field with the same spelling declared in a subclass is a separate private field.

Start with the main contrast: #value is enforced by JavaScript, while _value is only a convention. Then explain direct access, inheritance, reflection, JSON serialization, string property access, and the private brand check. A small example containing both fields makes each difference easy to show.

Promise resolution adopts thenables instead of simply fulfilling with them. JavaScript reads the value's then property first. That property access can run a getter immediately. If the getter throws, the Promise rejects. If then is callable, JavaScript calls it later through Promise job processing and adopts what it produces. Only the first resolve or reject call matters. Nested thenables are adopted recursively. Directly resolving a Promise with itself rejects with a TypeError.

The main idea is that some values can carry instructions for how a future result should finish. JavaScript does not always accept such a value as the final result right away. It first looks for a special part of that value. Looking at that part can itself run code. That code may fail, or it may provide instructions that later choose success or failure. Only the first choice counts. Those instructions may point to another similar value, so JavaScript can keep following them until it reaches an ordinary final value or a failure.

1. Should I explain both when the then getter runs and when the returned then function runs?
2. Should I cover direct self resolution and nested thenable cycles separately?

The practical rule is that Promise resolution adopts a thenable instead of automatically fulfilling with that object.

When a Promise is resolved with an object x, JavaScript reads x.then. This property access happens as part of resolving the value. A getter for then can therefore execute immediately. With Promise.resolve(x), that getter can run before Promise.resolve returns. If reading then throws, the Promise is rejected with that error.

If the retrieved then value is not callable, the Promise is fulfilled with x. If it is callable, JavaScript schedules a Promise job that later calls that function with resolve and reject functions.

Those functions follow a single settlement rule. If the thenable calls resolve first and reject second, the rejection is ignored. The first call wins even when the value passed to resolve still needs more adoption.

If resolve receives another thenable, JavaScript repeats the adoption process. This can continue through several thenables until an ordinary value is reached or one step rejects.

JavaScript also rejects direct self resolution. If a Promise is resolved with that same Promise, it rejects with a TypeError. This direct check does not mean every indirect thenable cycle is detected. A cycle formed only through separate thenables can repeatedly continue the adoption process instead.

This behavior matters at library and application boundaries. An unfamiliar object may run code through its then getter and later through its then function. Each additional thenable layer also creates more Promise job work and bookkeeping, so unnecessary deep adoption chains should be avoided.

The example shows the important resolution cases with the same rules described above. The outer thenable has a then getter, so its log happens when Promise.resolve reads that property. The getter returns a then function that is invoked later. That function resolves with a nested thenable and then tries to reject. The rejection is ignored because resolve was called first. JavaScript recursively adopts the nested thenable and eventually fulfills with final value. A second object demonstrates that a throwing then getter causes rejection. A final example demonstrates direct self resolution, which rejects with a TypeError.

A common mistake is saying that calling resolve always fulfills a Promise immediately. Resolve can instead begin adoption of another thenable. Another mistake is assuming that both resolve and reject can change the result when a thenable calls both. Only the first call has an effect. Candidates also sometimes say that the then getter and the callable then function run at the same time. The getter can run during the synchronous resolution call, while the callable then function runs later through Promise job processing. Another mistake is saying that JavaScript detects every possible thenable cycle. The required direct check rejects a Promise resolved with itself, but separate thenables can form indirect cycles that are not caught by that same direct identity check.

Start with the rule that Promise resolution adopts thenables. Then explain the order clearly: read then, reject if that access throws, fulfill directly if then is not callable, call a callable then later, accept only its first resolve or reject call, recursively adopt nested thenables, and reject direct self resolution with TypeError. Mention that Promise.resolve can execute a user supplied getter before returning when given an arbitrary thenable.

An unbounded microtask chain can keep the browser inside the same microtask checkpoint because every microtask adds another microtask before the queue becomes empty. The browser may therefore keep delaying timers, animation frames, rendering, and user input. I would bound the amount of microtask work and periodically yield through a task boundary. That lets the event loop move on to other browser work. I would not assume that the yield or a pending timer happens after an exact amount of time.

The main problem is that a small piece of work can keep adding another piece of urgent work forever. The browser normally gets chances to update what the user sees and react to clicks, typing, and other actions. But if each piece creates another piece before the browser gets that chance, the browser can stay busy with the chain. A waiting timer or screen update may remain delayed even though its requested time has passed. The practical fix is to stop after a limited amount of work and give control back to the browser regularly.

1. Should I assume this code is running on the browser main thread?
2. Do you want the solution to preserve frequent microtask processing while still allowing rendering and input?

A browser performs a microtask checkpoint after certain JavaScript work finishes. During that checkpoint, it keeps taking microtasks from the microtask queue until the queue is empty.

That rule is important here. Suppose a callback runs through queueMicrotask and schedules itself again before returning. The new microtask is added to the same microtask queue. When the browser finishes the current callback, another one is already waiting. If this continues without a limit, the queue never becomes empty, so the current checkpoint may never finish.

Other browser work can then be delayed. A pending timer callback runs as a later task, so it cannot run while the browser remains inside the endless microtask checkpoint. A pending animation frame can also be delayed because the browser does not reach a rendering opportunity. Paint, visual updates, and handling of user input can therefore appear frozen.

The production solution is to bound the work. Process only a limited number of items, then yield through a task boundary. The example uses MessageChannel to schedule that boundary. When the message task runs, the previous microtask checkpoint has ended, so the event loop can make progress between batches and the browser can take rendering opportunities when appropriate.

The exact timing is not guaranteed. Yielding gives the browser an opportunity to continue other work. It does not promise that a timer, animation frame, paint, or input callback will happen after a fixed delay.

The example processes work in small batches. Each item in a batch is scheduled as a microtask, so the example still shows microtask behavior. After a fixed number of items, it awaits a Promise resolved by MessageChannel. A channel message is handled as a task, so this creates a task boundary instead of extending the current microtask checkpoint forever. The batch size controls how much work can happen before yielding. The code does not depend on a timer duration and does not claim that rendering or another callback will run at an exact moment.

A common mistake is assuming that queueMicrotask automatically gives the browser time to render. It does not. Another mistake is believing that returning from one microtask ends the checkpoint even when that microtask has already queued another one. Developers also sometimes replace the chain with Promises but keep the same unbounded behavior, because Promise reactions also use microtasks. Another mistake is assuming that a timer with zero delay runs immediately or after an exact delay. Finally, yielding after every tiny operation can create unnecessary scheduling overhead, so production code should choose a reasonable amount of work between yields.

Start with the key rule: the browser drains microtasks until the microtask queue is empty. Then explain that recursively adding another microtask prevents that empty state. Name the visible effects, such as delayed timers, animation frames, rendering, and input. Finish by explaining bounded work plus a task boundary, and clearly say that yielding provides an opportunity for other browser work rather than an exact timing guarantee.

The current call stack does not stay in place across an await. An async function runs normally until it reaches await. It then suspends and returns control to its caller, so the active stack can unwind. Even when the Promise is already fulfilled, the code after await continues later as a microtask. If that continuation throws, the async function's returned Promise rejects. A caller can handle that rejection with await inside try and catch, or by attaching .catch() to the returned Promise.

Before await, JavaScript runs the nested function calls immediately, like ordinary function calls. When the inner function reaches await, it pauses at that point and gives control back. The outer function also pauses if it is waiting for the inner function. The current work can then finish and its call stack can disappear. Later, JavaScript continues the inner function. If that continued work throws an error, the failure travels through the results returned by the waiting functions. The original caller can then handle that failure instead of leaving it unhandled.

1. Should I assume the Promise being awaited is already fulfilled?
2. Should I explain both try and catch with await and Promise .catch() handling?
3. Should I also explain what browser developer tools mean when they show an async stack trace?

An async function executes synchronously until it reaches an await. In this example, outer() calls inner(), so both functions initially execute as normal JavaScript calls on the active call stack. inner() then executes await Promise.resolve("ready").

The Promise is already fulfilled, but await still creates a suspension boundary. JavaScript does not execute the next statement in inner() on that same active stack. inner() suspends and its async call has already returned a Promise to outer(). Because outer() awaits that Promise, outer() suspends too. Its async call has already returned its own Promise to the original caller. The active call stack can then unwind completely.

The continuation after the inner await is scheduled by Promise reaction processing as a microtask. After the current synchronous work finishes, that continuation runs during microtask processing with a new active call stack. JavaScript did not keep the old runtime stack alive and resume it later.

When inner() throws after the await, the Promise returned by inner() becomes rejected. outer() is waiting for that Promise. Because outer() does not catch the rejection, the Promise returned by outer() also becomes rejected. The original caller can handle that rejection by awaiting it inside try and catch, or by attaching .catch().

Browser developer tools may show an async stack trace that connects the related async calls. That is debugging information that preserves useful causal history. It does not mean the original runtime call stack remained active across the await.

This matters in production because error handling must follow the Promise chain. A normal synchronous try and catch around a call to outer() without awaiting its returned Promise cannot catch a rejection that happens later.

The example uses outer() and inner(). outer() calls and awaits inner(). inner() logs a message, awaits an already fulfilled Promise, and then throws. The first logs happen synchronously on the original active call stack. Reaching await suspends inner(). outer() also suspends because it awaits the Promise returned by inner(). The original caller already has the Promise returned by outer(), so the remaining synchronous log statements run before the inner continuation. The inner continuation later runs as a microtask and throws. That rejects the Promise from inner(). Because outer() does not catch the rejection, its returned Promise also rejects. The caller's .catch() handles that final rejection.

A common mistake is saying that await blocks the JavaScript thread. It does not. The async function suspends and other JavaScript work can continue. Another mistake is saying that an already fulfilled Promise makes await continue synchronously. The continuation still runs later through Promise microtask processing. Candidates also sometimes say that the original call stack is frozen until the async function resumes. The active stack actually unwinds, and the continuation later runs with a new active stack. Another mistake is treating an async stack trace as proof that one physical runtime stack survived the suspension. Developer tools can preserve useful causal async information for debugging. Finally, a synchronous try and catch around outer() without awaiting its Promise does not catch a rejection that happens later.

Explain the sequence in time order. First say that nested async functions run synchronously until await. Then say that await suspends the function and lets the current stack unwind. Next explain that the continuation runs as a microtask. Finish by showing how a throw becomes a Promise rejection that the caller handles with awaited try and catch or .catch().

instanceof can fail across realms because each realm has its own constructors and prototype objects. An array created inside an iframe can be a real array but still fail value instanceof Array when Array comes from the parent realm. For arrays, I would use Array.isArray(value). For custom classes crossing realm boundaries, I would use an explicit brand or carefully validate the required structure instead of assuming the parent constructor has the same identity.

A page and an iframe can each have their own JavaScript world. An array made inside the iframe belongs to that iframe world. The parent page has a different Array object. Because of this, asking whether the iframe array came from the parent Array can return false even though the value really is an array. The practical fix is to use Array.isArray when you need to recognize arrays. For your own object types, use a clear brand or validate the data you expect when values can cross between separate JavaScript worlds.

1. Should I assume the iframe is same origin so the parent can directly read values from it?
2. Should I also explain how custom class instances should be checked across realm boundaries?

instanceof uses prototype identity. In normal use, value instanceof Constructor checks whether Constructor.prototype appears in the prototype chain of value.

Each JavaScript realm has its own intrinsic constructors and prototype objects. An iframe creates another realm. Its Array, Object, and other built in constructors are separate objects from the matching constructors in the parent realm.

Suppose a same origin iframe creates const items = []. That array has the iframe realm Array.prototype in its prototype chain. If the parent checks items instanceof Array, the parent realm Array.prototype is not in that chain, so the result is false.

For arrays, Array.isArray(items) is the correct cross realm check. It recognizes whether the value has the internal array nature instead of depending on the parent realm Array prototype identity.

Custom classes have the same identity problem. A class defined in the iframe and a class with the same name defined in the parent are still different constructor objects. An instance created by the iframe class normally fails instanceof against the parent class.

At a cross realm boundary, custom objects can use an explicit brand together with validation of the required data. Structural validation can also check the properties and value types that the application needs. The tradeoff is that a structural check proves that the value has an expected shape. It does not prove that one exact constructor created the value.

For a cross origin iframe, the parent cannot directly read arbitrary objects from the iframe because of the same origin policy. Communication normally uses messaging. That is a separate browser security boundary from the realm identity issue demonstrated by a directly accessible same origin iframe.

The example creates a same origin iframe with srcdoc. The iframe creates an array in its own realm and stores it on the iframe window. After the iframe loads, the parent reads that array. The parent realm instanceof Array check returns false because the parent Array prototype is different from the iframe Array prototype. Array.isArray returns true because it recognizes the value as an array without depending on that prototype identity. The example also creates a custom class in each realm and shows that matching class names do not make the constructor objects identical. It then validates an explicit brand and the required data shape.

A common mistake is assuming that every real array must pass value instanceof Array. That is false when the value and Array constructor come from different realms. Another mistake is assuming that two custom classes are equivalent because they have the same name or source text. Their constructor and prototype objects can still have different identities. It is also a mistake to treat one loose property check as proof that untrusted data is valid. If structural validation is used, the code should validate every property and value type that the application actually depends on. A separate mistake is forgetting that direct access to a cross origin iframe is restricted by the browser same origin policy.

Start with the key rule: instanceof depends on prototype identity, and each realm has separate constructors and prototypes. Then give the iframe array example. Say that Array.isArray works for cross realm array detection. Finish by explaining that custom classes often need explicit branding or structural validation when constructor identity is not a stable boundary.

An algorithm is a finite and clear sequence of steps that transforms valid input into the required output. In this example, I use linear search on [3, 7, 1, 9, 7, 4] to find 7. I check values from left to right and stop at the first match, which is index 1. The same steps work with a JavaScript Array or TypedArray. The search takes O(n) time and O(1) auxiliary space.

An algorithm is a clear set of steps for solving a problem. The steps must have one clear meaning and must eventually finish. Here, the input is [3, 7, 1, 9, 7, 4], and the target is 7. We want the index of the first matching value. Linear search fits because it checks each value from left to right and can stop when it finds the target. The same search steps can work with either a JavaScript Array or a TypedArray.

1. Should I return the index of the first matching value?
2. What should I return when the target is not present?
3. Can the input be empty or contain duplicate values?

The input is a sequence of values and a target value. In the diagram, the input is [3, 7, 1, 9, 7, 4], and the target is 7. The required output is the index of the first matching value. The answer is index 1 because the value at index 1 is 7. If no match exists, the function returns -1.

Linear search checks the input from the beginning, one item at a time. It fits because the values are not shown as sorted. At each index, compare the current value with the target. If they are equal, return the current index immediately. Otherwise, move to the next item.

Start at index 0. The current value is 3. Check whether 3 === 7. It is false, so move to the next index.

Now check index 1. The current value is 7. Check whether 7 === 7. It is true, so return index 1 and stop. Indices 2 through 5 are not processed because the answer has already been found.

Before checking index i, every earlier index has already been checked and did not contain the target. Therefore, the first successful comparison gives the first matching index. If the loop reaches the end without a match, then every valid index has been checked, so returning -1 is correct. The loop also always terminates because the index increases by one each time and cannot continue past the input length.

The same linearSearch function works with a normal JavaScript Array and an Int32Array. Both provide indexed access and a length property, so the search steps do not change. For [3, 7, 1, 9, 7, 4] with target 7, both versions return index 1. Only the structure that stores the values changes.

Let n be the number of input items. Linear search checks at most n items, so its time complexity is O(n). It uses only a fixed amount of extra state, so its auxiliary space complexity is O(1). Important boundary cases are an empty input, a single item, the target at the first or last position, duplicate target values, and a target that is not present.

The key idea is to scan the input from left to right and return as soon as the target is found. The invariant is: before checking index i, every earlier index has already been checked and does not contain the target. This means the first successful comparison gives the first matching index. If no comparison succeeds, returning -1 is correct because every valid position was checked. The same algorithm works with both Array and Int32Array because both support indexed access and a length property.

Let n be the number of items in the input. The algorithm checks at most n items, so the time complexity is O(n). It can stop earlier when it finds the target. The algorithm uses only a small fixed amount of extra state, mainly the loop index, so the auxiliary space complexity is O(1). The Array and TypedArray versions shown in the diagram use the same search steps and have the same complexity.

A common mistake is returning the value 7 instead of its index 1. Another mistake is continuing after the first match even though the diagram returns the first matching index. Candidates may also forget to return -1 when the target is absent. With duplicate values, they should return the first match because the search moves from left to right. Another mistake is claiming O(1) time because one indexed access is constant time. The full search may still inspect up to n items, so the time complexity is O(n).

Walk through the first two positions aloud: index 0 contains 3, so continue; index 1 contains 7, so return 1 and stop. This makes the processing order, early return, correctness, and complexity easy to explain.