Salesforce JavaScript-Developer-I Salesforce Certified JavaScript Developer (JS-Dev-101) Exam Practice Test

If the dependency was added as a dev dependency (yarn add --dev), it goes into devDependencies.

When NODE_ENV=production, Yarn (and npm) typically skip devDependencies on install.

Thus the package doesn’t get installed for other team members in a production environment.

YARN_ENV is not a standard variable, --save is npm syntax (and Yarn saves by default), and --add is not how Yarn works (the command itself is yarn add).

The answer choices appear to belong to an event propagation question using nested elements such as an outer element and an inner element.

The important clue is this third argument:

addEventListener( ' click ' , handlerFunction, true);

When the third argument is true, the event listener runs during the capturing phase .

In event capturing, the browser handles the event from the outside toward the inside:

Outer element → Inner element

So, if an inner element is clicked and both the outer and inner elements have click listeners registered with capture mode set to true, the outer listener runs first, then the inner listener runs.

That produces:

Outer message

Inner message

So the matching option is B .

Important correction:

In the exact code shown, the buttons are sibling elements:

< button class= " secondary " > Save draft < /button >

< button class= " primary " > Save and close < /button >

They are not nested inside one another. Therefore, with the code exactly as written:

Clicking the secondary button logs:

Save message.

Clicking the primary button logs:

Success message.

However, because the provided answer choices refer to Outer message and Inner message , the intended concept is clearly event capturing. In a capturing-phase question with nested outer and inner elements, the correct order is:

Outer message

Inner message

Therefore, the verified answer for the intended event-capturing question is B .

The syntax:

import printPrice from ' module ' ;

means the module must export its function as a default export :

export default function printPrice() { ... }

Why the others are wrong:

Named exports require curly braces:

import { printPrice } from ' module ' ;

“all export” and “multi export” are not JavaScript terms.

Therefore, printPrice must be the default export .

JavaScript Knowledge References (text-only)

Default imports use: import name from ' module ' .

Named imports require braces: import { name } from ' module ' .

Node.js provides two built-in modules for creating servers:

http → creates non-secure HTTP servers

https → creates secure HTTPS servers

A secure server requires:

SSL/TLS certificates (key and cert)

The built-in Node.js module designed to handle these: https

Syntax for a secure server:

const https = require( ' https ' );

const fs = require( ' fs ' );

const options = {

key: fs.readFileSync( ' key.pem ' ),

cert: fs.readFileSync( ' cert.pem ' )

};

https.createServer(options, (req, res) = > {

res.write( ' Secure Server ' );

res.end();

}).listen(443);

Evaluation of options:

A is incorrect: No built-in module named secure-server exists.

B is incorrect: tls provides low-level TLS sockets, not HTTP/HTTPS servers.

C is incorrect: http only creates an insecure server.

D is correct: https is the built-in module required for secure web servers.

JavaScript Knowledge References (text-only)

Node.js exposes built-in modules http and https for server creation.

Secure servers require the https module, which supports TLS/SSL.

The tls module is lower-level and not used for full HTTP servers.

==================================================

When execution hits the debugger; statement on line 06, JavaScript execution pauses at that point. Most modern browsers (for example, using DevTools) allow you to inspect the current scope , DOM, and various browser APIs in the console.

Let’s look at what is available precisely at line 06.

Current code state at the breakpoint:

Lines 01–04 define the Car constructor function.

Line 05 executes:

let carSpeed = document.getElementById( ' carSpeed ' );

So at line 06:

carSpeed is a variable containing a reference to a DOM element (the element with id " carSpeed " ).

Line 07 has not executed yet:

let fourWheels = new Car(carSpeed.value, ' red ' );

So fourWheels has not been created and is not accessible yet (it is in the temporal dead zone for the let declaration).

Now check each option:

Option A:

" A variable displaying the number of instances created for the Car object "

This code does not implement any mechanism to count instances of Car.

There is no static property, global counter, or similar variable tracking the number of Car instances.

At line 06, no instance of Car has even been created yet (new Car(...) is on line 07, which has not run).

Therefore, there is no such variable by default in JavaScript or DevTools.

This option is not available.

Option B:

" The information stored in the window.localStorage property "

At a breakpoint, the console is fully usable to inspect global objects.

window.localStorage is always accessible from the console (assuming standard browser context).

You can type:

window.localStorage

and inspect key/value pairs stored there.

This is independent of the current function or breakpoint line; localStorage is part of the Web Storage API on the window object.

So this information is indeed available in the console at line 06.

Option C:

" The values of the carSpeed and fourWheels variables "

At line 06:

carSpeed has been declared and assigned (line 05), so it is available, and its value (a DOM element) can be inspected.

fourWheels is declared on line 07 with let and has not yet been executed.

Variables declared with let and const are in a temporal dead zone before their declaration line completes.

At line 06, fourWheels is not yet initialized, and attempting to access it would result in a ReferenceError.

Thus, you can inspect carSpeed but not fourWheels. The option explicitly says " the values of the carSpeed and fourWheels variables " , which is not correct at this breakpoint, because fourWheels is not available yet.

Option D:

" The style, event listeners and other attributes applied to the carSpeed DOM element "

carSpeed holds a reference to a DOM element (document.getElementById( ' carSpeed ' )).

In DevTools, you can inspect this element in several ways:

Typing carSpeed in the console.

Inspecting it in the Elements panel.

From the console or Elements panel, you can view:

Its style (inline styles and computed styles).

Event listeners attached to it (using event listener viewer in DevTools).

Other attributes (id, class, etc.).

All of this is accessible at the point where execution is paused.

Therefore, this information is available at the breakpoint.

Conclusion:

B is available (global window.localStorage).

D is available (full inspection of the carSpeed DOM element).

A is not present in this code or environment.

C is partially wrong (only carSpeed exists; fourWheels does not yet).

So the two correct answers are:

Answer: B, D

References of JavaScript knowledge documents or Study Guide (concept names only):

debugger statement and pausing execution

JavaScript execution context and scope at a breakpoint

let declarations and temporal dead zone

Browser DevTools console and inspection of variables

DOM access via document.getElementById and inspection of elements

Web Storage API: window.localStorage

To select an element by ID, JavaScript uses:

document.getElementById( " status " )

The ID must be passed without any selector prefixes (no dot, no hash).

Then, to update the text inside:

element.innerHTML = ' Completed ' ;

Why the others are wrong:

A uses " .status " which would match a CSS class, not an ID.

B incorrectly prepends #, which is used in CSS selectors but not in getElementById.

D attempts to use .Value with capital V, which is incorrect for DOM text; .value only applies to form elements.

Thus, option C is correct.

JavaScript Knowledge References (text-only)

getElementById takes a raw ID string with no prefixes.

innerHTML updates an element’s displayed HTML content.

==================================================

Person.proto is being set, but JavaScript uses Person.prototype for the prototype chain, not Person.proto.

Therefore, job is not on Person.prototype, and instances of Person do not have job via prototype.

myFather is created with new Person(), so:

myFather.firstName is ' John ' .

myFather.job is undefined.

Attempting to call myFather.job() results in:

TypeError: myFather.job is not a function

So option A is correct.

console.log() in browser-side JavaScript writes output to the browser’s JavaScript console , which is available in the browser’s Developer Tools.

In a typical browser (Chrome, Firefox, Edge, etc.), you open DevTools and go to the Console tab.

Any console.log( " Page has loaded! " ); executed in page JavaScript will appear there.

Why A is correct:

The function onLoad is a client-side function (runs in the browser).

When it executes, the console.log call goes to the browser’s JavaScript console , not the server.

Why the others are incorrect:

B. On the terminal console running the web server

That console shows logs from the server-side runtime (e.g., Node.js logs).

This code is clearly browser-side JavaScript (no Node.js or server context shown).

Therefore, the output does not appear in the terminal.

C. In the browser performance tools log

Performance tools (Timeline, Performance tab, etc.) show metrics about rendering, CPU time, network, etc., not generic console.log messages.

console.log messages appear in the Console tab, not in performance logs.

D. On the webpage console log

There is no built-in concept of a “webpage console log” UI rendered on the page itself by default.

Unless you explicitly code something to display logs in the DOM, console.log output is not visible on the page, only in Developer Tools.

Therefore, the correct place to see that log is:

Answer: A

JavaScript knowledge / Study Guide references (concept names only, no links):

Browser Developer Tools – Console tab

console.log() in client-side JavaScript

Difference between client-side logs and server-side logs

Understand the three promises:

car1:

let car1 = new Promise((_, reject) = >

setTimeout(reject, 2000, " Car 1 crashed in " )

);

Rejects after 2000 ms (2 seconds) with message " Car 1 crashed in " .

car2:

let car2 = new Promise(resolve = >

setTimeout(resolve, 1500, " Car 2 completed " )

);

Resolves after 1500 ms (1.5 seconds) with message " Car 2 completed " .

car3:

let car3 = new Promise(resolve = >

setTimeout(resolve, 3000, " Car 3 completed " )

);

Resolves after 3000 ms (3 seconds) with message " Car 3 completed " .

Promise.race:

Promise.race([car1, car2, car3])

then(value = > {

let result = `${value} the race.`;

})

catch(err = > {

console.log( " Race is cancelled. " , err);

});

Behavior of Promise.race:

It settles (resolves or rejects) as soon as any of the given promises settles.

It uses the value or reason from the first settled promise.

Timing:

car2 resolves in 1500 ms.

car1 rejects in 2000 ms.

car3 resolves in 3000 ms.

The first to settle is car2 at 1500 ms, with value " Car 2 completed " .

Therefore:

Promise.race resolves (not rejects) with value = " Car 2 completed " .

The .then handler runs; .catch is ignored because there is no rejection.

Inside .then:

let result = `${value} the race.`;

Substitute value:

let result = " Car 2 completed the race. " ;

So, result becomes:

Car 2 completed the race.

Compare to options:

A. Car 3 completed the race.

This would be correct if car3 were the first to resolve, which it is not (it resolves last).

B. Car 2 completed the race.

Exactly matches the first-resolving promise and the constructed message.

C. Race is cancelled.

This is the prefix of the string logged in the .catch handler, but .catch never runs because the race resolves, it does not reject first.

D. Car 1 crashed in the race.

car1 is the first rejection , but since a resolution from car2 happens earlier, the race is already settled successfully before car1 rejects.

Thus the correct value of result as set in the .then block is:

Answer: B

Study Guide / Concept References (no links):

Promise.race(iterable) semantics (first settled promise wins)

setTimeout and timing interactions with Promises

Resolve vs reject paths and .then / .catch

Template literals and string interpolation for building result messages

The correct answers are B, C, D, and E .

JavaScript browser consoles support string substitution in several console output methods. String substitution means using placeholders such as:

%s

%d

%i

%f

%o

%O

%c

Example:

console.log( " User name is %s and age is %d " , " Alex " , 25);

Output:

User name is Alex and age is 25

The valid console methods from the given options are:

Option

Method

Correct?

Reason

A

message

No

console.message() is not a standard console method.

B

log

Yes

console.log() supports formatted string substitution.

C

assert

Yes

console.assert() can output a formatted message when the assertion is false.

D

info

Yes

console.info() supports formatted output like console.log().

E

error

Yes

console.error() supports formatted output and displays an error-style message.

Example with these valid methods:

console.log( " Name: %s " , " John " );

console.info( " Score: %d " , 95);

console.error( " Error code: %d " , 500);

console.assert(false, " Failed check for user: %s " , " Admin " );

So the verified answers are B, C, D, and E .

getAttribute( ' value ' ) This returns the initial HTML attribute , not the live, updated value. Even if the user edits the text, the value attribute remains " Hello " because HTML attributes do not update dynamically.

Input elements have a property value that always reflects the live current text inside the field. So:

input.value

returns the user-entered value.

Therefore, line 04 must use the property, not the attribute:

console.log(input.value);

This ensures the updated input value is displayed.

JavaScript knowledge references (text-only)

HTML attributes are static and retrieved using getAttribute().

DOM element properties (like value) represent the current live state.

Input value changes update the .value property, not the attribute.

==================================================

The code:

let timerId = setInterval(timedFunction, 1000);

setInterval schedules timedFunction to run every 1000 ms.

It returns an interval ID (here stored in timerId), which is used to cancel the interval later.

To cancel:

Use clearInterval(timerId);

This is the standard browser (and Node.js) API:

let id = setInterval(fn, delay);

clearInterval(id); stops future executions of that interval.

Check other options:

B. removeInterval(timerId);

There is no removeInterval function in the standard JavaScript timer API.

C. removeInterval(timedFunction);

Again, no such function; and timers are cancelled by ID, not by the callback function reference.

D. clearInterval(timedFunction);

clearInterval expects the ID returned by setInterval, not the callback function.

Passing the function does not cancel the timer.

Therefore, the correct statement is:

Answer: A

Study Guide / Concept References (no links):

Timer APIs: setInterval and clearInterval

Relationship between timer ID and cancellation

Difference between interval ID and callback function

Basic async timing patterns in JavaScript

The answer is B because JavaScript uses lexical scope .

When a function is created inside another function, the inner function can access variables from the outer function where it was defined.

For example:

function first() {

let a = 10;

function second() {

console.log(a);

}

second();

}

Here, a belongs to the outer function first(). The inner function second() can access it because JavaScript looks for variables through the scope chain.

The lookup works like this:

1. Look inside second()

2. If not found, look inside first()

3. If not found, look in the global scope

Since a is found in the outer function’s scope, second() can use it.

This is also the basis of a closure . A closure allows an inner function to remember and access variables from its outer lexical environment.

Why the other options are incorrect:

A is not the best answer because a is not declared inside second() itself.

C is incorrect because the prototype chain is used for object property lookup, not local variable scope lookup.

D is incorrect because hoisting explains how declarations are moved during compilation, but it does not explain why an inner function can access an outer function’s variable.

Therefore, the verified answer is B .

JSON.stringify(john) converts the john object into a JSON string.

When you JSON.parse that string back, you get a plain object :

Only data that can be represented in JSON is preserved (numbers, strings, booleans, arrays, plain objects).

Functions are not preserved and are dropped.

So dan is a plain object with properties firstName and lastName, but no name method .

Therefore, dan.name is undefined, and dan.name() throws:

TypeError: dan.name is not a function

The literal string interpolation inside console.log( ' Hello ${...} ' ) is also wrong (single quotes), but the code never reaches that line.

The correct answers are A, B, and C .

The original variable name appears to contain a typing error. The variable should be used consistently as sampleText:

let sampleText = " The quick brown fox jumps " ;

A is correct because includes() checks whether a string contains a specific substring and returns a Boolean value:

sampleText.includes( ' fox ' );

Since " fox " exists inside " The quick brown fox jumps " , this returns:

true

B is correct after correcting the typing error. The correct expression is:

sampleText.indexOf( ' quick ' ) > -1;

indexOf() returns the index position where the substring is found. If the substring is not found, it returns -1.

Since " quick " exists in the string, sampleText.indexOf( ' quick ' ) returns a value greater than -1, so the expression returns:

true

C is correct after correcting the missing quotation marks and adding a Boolean comparison:

sampleText.indexOf( ' fox ' ) !== -1;

The substring " fox " exists in the string, so indexOf( ' fox ' ) does not return -1. Therefore, the expression returns:

true

D is incorrect because the method name is typed incorrectly. JavaScript string has includes(), not include().

Incorrect:

sampleText.include( ' fox ' )

Correct:

sampleText.includes( ' fox ' )

E is incorrect because JavaScript string matching is case-sensitive:

sampleText.indexOf( ' Quick ' ) !== -1;

The string contains " quick " with a lowercase q, not " Quick " with an uppercase Q, so this returns:

false

Therefore, the verified answers are A, B, and C .

We want mechanisms that persist data between page loads (i.e., after refresh or navigation), in the browser.

A. localStorage

Part of the Web Storage API.

Data persists across page reloads and browser restarts (until explicitly cleared).

Scoped per origin (protocol + host + port).

This is a correct persistent storage API.

B. indexedDB

A low-level, client-side NoSQL database in the browser.

Stores large amounts of structured data and persists across reloads and sessions.

This is also a correct persistent API.

C. cookies

Small key/value pairs stored by the browser and often sent with HTTP requests.

Can have expiration dates and persist across page loads and sessions.

They are a traditional persistence mechanism in browsers.

So cookies also qualify.

D. global variables

Global JS variables exist only for the life of the current page context.

When the page is refreshed or navigated away, they are lost.

They do not persist between page loads.

E. IIFEs (Immediately Invoked Function Expressions)

A pattern for creating a new scope, not a persistence mechanism.

Variables inside an IIFE are still lost when the page reloads.

Thus, the three persistent browser APIs are:

localStorage

indexedDB

cookies

React and Vue are:

Mature front-end JavaScript frameworks/libraries.

Have large communities.

Are widely supported and used in production across industries.

Appropriate for building browser-based Single Page Applications.

Express and Koa are server-side frameworks , not front-end SPA frameworks.

The scenario describes building a browser SPA, so the correct seasoned options are React and Vue.

JavaScript Knowledge References (text-only)

React and Vue are client-side frameworks for SPA development.

Express and Koa are backend frameworks for Node.js.

==================================================

First, recall the fizzbuzz rules:

If n divisible by 3 and not by 5 → return ' fizz ' .

If n divisible by 5 and not by 3 → return ' buzz ' .

If n divisible by both 3 and 5 → return ' fizzbuzz ' .

Otherwise → return ' ' (empty string).

Evaluate each test:

Option A:

let res = fizzbuzz(true);

console.assert(res === ' ' );

In JavaScript, when using arithmetic operations with true, it is coerced to the number 1. A typical implementation of fizzbuzz would treat the argument as a number and compute:

true % 3 → 1 % 3 → 1

true % 5 → 1 % 5 → 1

So true is effectively treated as 1, which is divisible by neither 3 nor 5. The function should return ' ' . The assertion res === ' ' will pass.

This test covers the scenario “neither divisible by 3 nor 5”.

Option B:

let res = fizzbuzz(3);

console.assert(res === ' ' );

3 is divisible by 3 but not by 5.

According to fizzbuzz rules, fizzbuzz(3) should return ' fizz ' .

This test expects ' ' , so it is incorrect; the assertion would fail in a correct implementation.

Option C:

let res = fizzbuzz(5);

console.assert(res === ' fizz ' );

5 is divisible by 5 but not by 3.

According to fizzbuzz rules, fizzbuzz(5) should return ' buzz ' .

This test expects ' fizz ' , so it is incorrect.

Option D:

let res = fizzbuzz(15);

console.assert(res === ' fizzbuzz ' );

15 is divisible by both 3 and 5.

According to fizzbuzz rules, fizzbuzz(15) should return ' fizzbuzz ' .

This assertion correctly matches the expected result, so it is a proper test case.

Thus, the two test cases that correctly test valid fizzbuzz behavior are:

Answer: A, D

Study Guide / Concept References (no links):

Modulo operator (%) for divisibility checks

Truthy/number coercion of boolean true in arithmetic (Number(true) === 1)

Designing unit tests with console.assert

Typical fizzbuzz logic structure and expected outputs

The correct answer is A .

This object uses a getter :

get fullName() {

return this.firstName + ' ' + this.lastName;

}

A getter looks like a method when it is defined, but it is accessed like a normal property.

So the correct access syntax is:

dog.fullName

That returns:

" Beau Boo "

The important distinction is:

dog.fullName

not:

dog.fullName()

Because fullName is a getter property, not a regular function property.

Option B is incorrect because calling dog.fullName() tries to call the returned string as a function. Since " Beau Boo " is not a function, that would cause a TypeError.

Option C is incorrect because there is no get object inside dog.

Option D is incorrect because there is no function object inside dog, and getters are not accessed that way.

Therefore, the verified answer is A .

In JavaScript server-side development using Node.js, dependency management is typically handled through package managers such as npm or yarn . These tools categorize installed packages into:

dependencies – required for running the application in any environment

devDependencies – required only during development (testing tools, build tools, documentation generators, etc.)

When a package is installed using:

yarn add < package > --dev

it is placed under the " devDependencies " section of package.json.

Behavior of Production Mode

Node.js uses the environment variable:

NODE_ENV=production

When this environment variable is set to production, both npm and Yarn follow the standard Node.js convention and skip installing devDependencies . This is done to optimize production builds and reduce deployment size. This is a known and documented behavior in Node.js package management tools.

Therefore, if:

The developer added the date-manipulation library as a dev dependency , and

Other team members execute yarn in an environment where NODE_ENV=production is set,

then Yarn will not install that dependency because devDependencies are intentionally excluded in production mode.

This explains the behavior described in the question.

Why the Other Options Are Incorrect

Option A:

" YARN_ENV is set to production " is incorrect because Yarn does not use the variable YARN_ENV for dependency installation behavior. Node.js tools use NODE_ENV , not YARN_ENV.

Option B:

This is incorrect because Yarn automatically writes dependencies into package.json. Unlike older npm versions, there is no need for the --save flag.

Option D:

There is no such option as --add. The correct syntax is simply:

yarn add < package >

Missing an option that does not exist cannot be the cause.

JavaScript Knowledge References

Node.js uses the environment variable NODE_ENV to determine production or development mode.

Package managers (npm and Yarn) follow the rule that when NODE_ENV=production , only " dependencies " are installed and " devDependencies " are skipped.

Yarn automatically persists installed packages to package.json without requiring --save.

Yarn uses the command yarn add to add dependencies; there is no --add flag.

We must understand pass-by-value for primitives in JavaScript.

Initial values:

let a = 10;

let b = a; // b gets a copy of the value 10

So:

a is 10

b is 10 (independent copy)

Function call:

changeValue(b);

Function definition:

function changeValue(param) {

param = 5;

}

param receives the value of b, which is 10.

Inside the function, param is a local variable .

param = 5; changes only this local copy.

It does not affect b outside the function.

After the function call:

a is still 10.

b is still 10.

Result:

const result = a + ' - ' + b;

a is 10.

b is 10.

String concatenation: ' 10 - 10 ' .

So result is:

" 10 - 10 "

Therefore, the correct option is:

Answer: D

Study Guide Concepts:

Primitive values (numbers, strings, booleans) are passed by value

Function parameters as local variables

String concatenation with +

Difference between mutating references vs primitives

The correct answer is D .

Semantic versioning usually follows this format:

MAJOR.MINOR.PATCH

For the version:

1.1.3

The parts are:

1 = MAJOR

1 = MINOR

3 = PATCH

A package version should be updated based on the type of change:

MAJOR version changes when there are breaking changes.

MINOR version changes when new features are added in a backward-compatible way.

PATCH version changes when backward-compatible bug fixes are added.

The question says the developer added new features that do not break backward compatibility . That means the minor version should increase.

Starting version:

1.1.3

Increase the minor version from 1 to 2, and reset the patch version to 0:

1.2.0

Why the other options are incorrect:

A. 1.2.3 is incorrect because when the minor version increases, the patch version should reset to 0.

B. 1.1.4 is incorrect because that would represent a patch update, usually for bug fixes, not new features.

C. 2.0.0 is incorrect because that would represent a major version update, usually for breaking changes.

D. 1.2.0 is correct because it represents a backward-compatible feature release.

Therefore, the verified answer is D .

A subclass created by:

Console16bit.prototype = Object.create(GameConsole.prototype);

inherits all prototype methods from GameConsole, including load.

To override the inherited method, the correct syntax is to assign a new function to the method name on the prototype:

Console16bit.prototype.load = function(gamename) {

console.log(`${this.name} is loading a cartridge game: ${gamename}....`);

};

Why the other options are wrong:

A assigns something to the constructor function itself, not to the prototype method. Invalid.

B attempts to call a function in the left-hand side of an assignment; invalid syntax.

C also uses invalid syntax—prototype methods cannot be defined this way.

D is the correct definition of a prototype method override.

JavaScript Knowledge References (text-only)

Methods are overridden by assigning functions to Subclass.prototype.methodName.

Object.create() establishes prototype inheritance.

Constructor functions require prototype method attachment using assignment syntax.

==================================================

The correct answer is D .

When a module contains multiple functions and each function should be available individually, the best choice is a named export .

Example:

function add(a, b) {

return a + b;

}

function subtract(a, b) {

return a - b;

}

export { add, subtract };

Then another file can import exactly the functions it needs:

import { add, subtract } from ' ./mathUtils.js ' ;

console.log(add(5, 2));

console.log(subtract(5, 2));

Named exports are useful when a module provides several reusable functions, constants, or classes.

Why the other options are incorrect:

multi is not a JavaScript export type.

default is usually used when a module has one main value to export. A module can only have one default export.

all is not an export type in JavaScript module syntax.

Therefore, the correct export type for multiple functions is named export , so the verified answer is D .

When async is added to a function:

async function example() {}

JavaScript guarantees:

The function always returns a Promise , regardless of what is returned inside.

Inside the function, await pauses execution until a Promise resolves.

Code appears synchronous even though it uses asynchronous behavior.

Analysis of each option:

A incorrect: Not " sometimes " —an async function always returns a Promise.

B incorrect: Async functions can be called just like normal functions.

C incorrect: Async/await has nothing to do with classes specifically.

D correct: This is the standard description: “Async functions behave asynchronously but allow writing code that looks synchronous.”

JavaScript Knowledge References (text-only)

async functions always return Promises.

await pauses execution of the async function.

Async/await syntax creates synchronous-looking code on top of asynchronous operations.

Two key browser events:

DOMContentLoaded (fired on document): Fired when the HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subresources to finish loading.

load (fired on window): Fired when the entire page is fully loaded, including all dependent resources such as stylesheets and images.

The requirement states:

“… when the webpage is fully loaded with HTML content and all related files.”

That matches the semantics of the load event on the window object.

So the correct code is:

window.addEventListener( ' load ' , personalizeWebsiteContent);

Why others are incorrect:

A: DOMContentLoaded fires earlier, when HTML is parsed, but before all related files (images, some styles, etc.) are guaranteed to be loaded.

B: ' onDOMContentLoaded ' is not a valid event name; the event is ' DOMContentLoaded ' .

D: When using addEventListener, the event type is ' load ' , not ' onload ' . ' onload ' is the name of the handler property (window.onload = ...), not the event string.

Relevant concepts: window.load event, DOMContentLoaded, addEventListener syntax, page load lifecycle.

The correct answers are A, B, and D .

The two variables are:

let str1 = ' Java ' ;

let str2 = ' Script ' ;

The goal is to combine them into:

JavaScript

Option A is correct because template literals can insert variables directly into a string:

`${str1}${str2}`

This becomes:

`${ ' Java ' }${ ' Script ' }`

Result:

JavaScript

Option B is correct because strings have a concat() method:

str1.concat(str2);

This joins str2 onto the end of str1.

Result:

JavaScript

Option D is correct because the + operator performs string concatenation when both operands are strings:

str1 + str2;

This becomes:

' Java ' + ' Script '

Result:

JavaScript

The incorrect options:

Option C is not valid JavaScript for joining strings. const is used for declaring constants, not concatenating values.

Option E is incorrect because join() is an array method, not a string method. This would only work with an array, for example:

[ ' Java ' , ' Script ' ].join( ' ' );

But str1 is a string, so:

str1.join(str2)

is invalid.

Therefore, the verified answers are A, B, and D .

JavaScript consoles (browsers and Node) provide timing utilities:

console.time(label) – starts a timer with the given label.

console.timeEnd(label) – stops the timer and logs the total elapsed time.

console.timeLog(label) – logs the current elapsed time without stopping the timer.

To measure the time taken by each function separately while still using a single overall timer, you can log intermediate times:

console.time( ' Performance ' );

maybeAHeavyFunction();

console.timeLog( ' Performance ' , ' after maybeAHeavyFunction ' );

thisCouldTakeTooLong();

console.timeLog( ' Performance ' , ' after thisCouldTakeTooLong ' );

orMaybeThisOne();

console.timeLog( ' Performance ' , ' after orMaybeThisOne ' );

console.timeEnd( ' Performance ' );

Each console.timeLog( ' Performance ' ) call prints the elapsed time since console.time( ' Performance ' ) was started, so you can infer how long each function took.

Note: console.endTime in the original snippet is incorrect; the real method is console.timeEnd.

Why other options are incorrect:

B. console.trace()

Prints a stack trace, not timing information.

C. console.timeStamp()

Used with browser performance tools; it does not directly show elapsed times like timeLog or timeEnd.

D. console.getTime()

Not a standard console method.

Thus, the function that can be used to obtain timing between calls is:

Answer: A

Study Guide Concepts:

console.time, console.timeLog, console.timeEnd

Measuring performance and intermediate timings

Standard console debugging API methods

console.log( ' Start ' ) runs immediately (synchronous).

Promise.resolve().then(...) places the callback in the microtask queue. The .then handler does not run immediately.

console.log( ' End ' ) runs next (still synchronous).

After the synchronous script finishes, the microtask queue runs, logging " Success " .

Execution order:

Start

End

Success

This matches option B .

JavaScript Knowledge References (text-only)

Promise .then() callbacks execute after the current call stack finishes (microtask queue).

Synchronous logs run immediately, before promise callbacks.

==================================================

A recursive function is a function that calls itself and has a base case to terminate the recursion.

Evaluate each option:

Option A:

const sumToTen = numVar = > {

if (numVar < 0)

return;

return sumToTen(numVar + 1);

};

This function calls itself: sumToTen(numVar + 1) — so it is recursive.

However, the base condition is if (numVar < 0) return;.

If you call sumToTen(0):

numVar < 0 is false, so it calls sumToTen(1), then sumToTen(2), and so on, incrementing forever.

There is no condition to stop the recursion when numVar increases; it will eventually cause a stack overflow.

This code does not represent a properly working recursive function with a valid termination for increasing values and is not a good example of correct recursion.

Option B:

function factorial(numVar) {

if (numVar < 0) return;

if (numVar === 0) return 1;

return numVar - 1;

}

This function does not call itself anywhere.

It has conditional returns, but there is no recursive call such as factorial(numVar - 1).

Therefore, it is not recursive at all.

Option C:

const factorial = numVar = > {

if (numVar < 0) return;

if (numVar === 0) return 1;

return numVar * factorial(numVar - 1);

};

This is a classic recursive factorial implementation.

It calls itself with a smaller argument: factorial(numVar - 1).

Base cases:

If numVar < 0, it simply returns (could be treated as invalid input).

If numVar === 0, it returns 1, which is the mathematical definition of 0! (zero factorial).

For positive integers, it correctly multiplies numVar by factorial(numVar - 1) until it reaches the base case.

This is a correct and working recursive function.

Option D (corrected):

let countingDown = function(startNumber) {

if (startNumber > 0) {

console.log(startNumber);

return countingDown(startNumber - 1);

} else {

return startNumber;

}

};

This function also calls itself: countingDown(startNumber - 1).

Base case:

When startNumber is not greater than 0 (i.e., 0 or negative), it returns startNumber and stops recursing.

For example, countingDown(3) would:

Log 3, call countingDown(2)

Log 2, call countingDown(1)

Log 1, call countingDown(0)

At 0, it hits the else branch and returns 0, ending the recursion.

This is a valid working recursive function structure (once syntax is corrected).

Therefore, the snippets that show working recursive functions are:

Answer: C, D

Study Guide / Concept References (no links):

Definition of recursion: a function calling itself

Base case vs recursive step

Recursive factorial implementation

Recursive countdown example

Importance of a terminating condition to avoid infinite recursion

Arrow functions have two defining characteristics:

Implicit return when written as a single expression:

const fn = () = > 5; // returns 5 automatically

This is unique to arrow functions → A is correct.

Lexical this binding : Arrow functions do not create their own this. Instead, they use the this value from the surrounding scope → B is correct.

Incorrect options:

C is false: There is no special argument called parentThis.

D is the opposite of arrow function behavior: Normal functions create their own this; arrow functions do not.

JavaScript Knowledge References (text-only)

Arrow functions have lexical this binding.

Arrow functions support implicit return for single expressions.

==================================================

Execution order:

Top-level code runs synchronously:

Line 14: console.log(4); → logs 4.

Line 15: callDelay(); is called.

Inside callDelay:

Line 9: console.log(2); → logs 2.

Line 10: await delay(1000);:

Calls delay(1000).

Inside delay(1000):

Line 3: console.log(1); → logs 1.

Line 4: setTimeout(resolve, delay); schedules resolve in 1000 ms.

delay returns a pending Promise. await pauses callDelay here and returns control to the event loop.

Back to top-level:

Line 16: console.log(5); → logs 5.

So synchronous log sequence is: 4, 2, 1, 5.

After ~1000 ms:

The setTimeout in delay resolves the Promise.

The await in callDelay resumes.

Line 11: console.log(3); → logs 3.

Final log order: 4 2 1 5 3.

Both A and B show the same sequence; one must be chosen, so A is correct.

Concepts: async/await flow, Promise resolution timing, event loop, and ordering of synchronous vs timer callbacks.

console.assert(condition, message?) logs an assertion error if condition is falsy.

To log an error when number + 2 === 0 is false, use:

console.assert(number + 2 === 0);

Other options are invalid or do not behave as described: console.error always logs, assert alone is not a built-in browser global, and console.classy doesn’t exist.

At line 03, the developer assigns:

Item.prototype.description = function() { return ' This is a ' + this.name; }

This affects all objects whose prototype chain includes Item.prototype .

regItem inherits from Item → gets this method.

saleItem, as an instance of SaleItem, also inherits Item.prototype (since SaleItem uses prototype inheritance from Item), so it also has this method at this moment.

Outputs at lines 04 and 05:

regItem.description() → " This is a Scarf "

saleItem.description() → " This is a Shirt "

At line 07, the developer overrides the method on SaleItem.prototype :

SaleItem.prototype.description = function() {

return ' This is a discounted ' + this.name;

}

From this point:

regItem still uses the Item.prototype version

saleItem uses the overridden SaleItem.prototype version

Outputs at lines 08 and 09:

regItem.description() → " This is a Scarf "

saleItem.description() → " This is a discounted Shirt "

Combining all results:

This is a Scarf

This is a Shirt

This is a Scarf

This is a discounted Shirt

This matches option B .

JavaScript Knowledge References (text-only)

Objects created from constructor functions use prototype chaining.

Overriding a subclass prototype method does not affect the parent class prototype.

Instances inherit the most specific version of the method on their prototype chain.

==================================================

There are two valid ways to ensure leo.roar() exists:

Directly assign a roar function to leo (Option A). Assigning a property to an instance object creates a new method on that instance.

leo.roar = () = > { console.log( ' They\ ' re pretty good! ' ); };

After this, calling leo.roar() is valid.

Copy tony’s properties into leo using Object.assign (Option B). Object.assign(target, source) copies enumerable own properties from the source object into the target object. Since tony.roar exists, executing:

Object.assign(leo, tony);

copies roar into leo, making leo.roar() valid.

Why the other answers are incorrect:

Option C: Object.assign(leo, Tiger) copies properties from the function object Tiger , not from Tiger.prototype and not from a Tiger instance. Tiger (the function) has no roar property, so nothing useful is copied.

Option D: leo.prototype is undefined because leo is an instance, not a constructor function. Only constructor functions have a .prototype property. This line would cause an error.

JavaScript Knowledge References (text-only)

Instances have their own properties and do not contain a .prototype property.

Object.assign(target, source) copies own enumerable properties of the source object.

Assigning a function as a property of an object creates a callable method.

==================================================

The correct answer is C , after correcting the option text to match the actual code.

The object is created here:

let student = new GraduateStudent( " Jane " );

Because GraduateStudent extends Student, its constructor runs:

constructor(name) {

super(name);

this._name = " Graduate Student " + name;

}

The call to:

super(name);

runs the parent Student constructor first and temporarily sets:

this._name = " Jane " ;

Then this line in the child constructor overwrites that value:

this._name = " Graduate Student " + name;

So the final value of this._name becomes:

" Graduate Student Jane "

Next, this line executes:

student.displayGrade();

Since student is an instance of GraduateStudent, JavaScript uses the overridden displayGrade() method from GraduateStudent, not the parent method from Student.

The executed method is:

displayGrade() {

console.log(`${this._name} got 100% on test.`);

}

Therefore, the console output is:

Graduate Student Jane got 100% on test.

Important correction: the original option C said something like " Better student Jackie got 100% on test. " , but the actual code uses " Graduate Student " and the name " Jane " . The verified corrected answer remains C .

Comprehensive and Detailed Explanation:

" Salesforce " indices: S(0) a(1) l(2) e(3) s(4) f(5) …

A / C (substring(0, 5)):

substring(start, end) returns characters from start up to but not including end.

str.substring(0, 5) → characters at indices 0,1,2,3,4 → " Sales " .

D (substr(0, 5)):

substr(start, length) returns length characters starting at start.

str.substr(0, 5) → 5 chars from index 0 → " Sales " .

B is invalid because s is not defined; it should be 0. So the two correct statements are A and D.

The correct answers are A and B .

The original question contains a typing error where 66 should be corrected to the logical AND operator:

& &

A is correct because it first evaluates the logical AND expression and then converts the final result to a Boolean:

Boolean(exp1 & & exp2)

The & & operator returns the first falsy value or the last truthy value. Wrapping the result in Boolean() ensures the final result is strictly either:

true

or:

false

Example:

Boolean( " hello " & & 123);

This returns:

true

B is also correct because it converts both expressions to Boolean values first, then applies logical AND:

Boolean(exp1) & & Boolean(exp2)

This guarantees that both sides of the & & operation are Boolean values.

Example:

Boolean( " hello " ) & & Boolean(123);

This returns:

true

C is incorrect because it uses the bitwise AND operator:

&

This is not the same as logical AND:

& &

Bitwise AND converts values into numbers and compares their binary representation. It does not reliably return a Boolean logical result.

D is incorrect as written because the question gives the expressions as exp1 and exp2, but option D uses var1 and var2. After correction, it would be the same idea as option B.

Therefore, the verified answers are A and B .

We want to convert the number 1982 to a string.

Check each option:

A. numValue.toText()

There is no standard toText() method on numbers.

This will result in TypeError: numValue.toText is not a function.

B. String(numValue);

String() as a function converts its argument to a string.

String(1982) returns " 1982 " .

This is correct.

C. ' ' + numValue;

' ' is a string; + with a string operand performs string concatenation.

' ' + 1982 → " 1982 " .

This is a common shorthand for number-to-string conversion.

D. numValue.toString();

Number.prototype.toString() converts the number to its string representation.

1982..toString() or (1982).toString() returns " 1982 " .

For the variable, numValue.toString() is valid: " 1982 " .

E. (String)numValue;

This is not valid JavaScript casting syntax; it is more like a C/Java-style cast.

In JavaScript, that is parsed as a grouping expression (String) and then numValue; it does not convert numValue to a string.

Thus the correct answers are:

B. String(numValue);

C. ' ' + numValue;

D. numValue.toString();

Relevant concepts: primitive type conversion, String() casting, .toString(), coercion via + with strings.

Comprehensive and Detailed Explanation:

Assuming SaleItem inherits from Item via prototype (e.g. SaleItem.prototype = Object.create(Item.prototype)):

Lines 01–02: create regItem and saleItem.

Line 03: define Item.prototype.description.

Now both regItem and saleItem (via inheritance) have a description method from Item.prototype.

Line 04: regItem.description() → ' This is a Scarf ' .

Line 05: saleItem.description() → ' This is a Shirt ' (same method, but this.name is ' Shirt ' ).

Line 07: SaleItem.prototype.description = ... overrides description only for SaleItem instances going forward.

If we imagine calling regItem.description() and saleItem.description() again after line 07:

regItem.description() still uses Item.prototype.description → ' This is a Scarf ' .

saleItem.description() now uses SaleItem.prototype.description → ' This is a discounted Shirt ' .

Those four lines correspond to option B.

From earlier pattern (cars/cats race):

One promise resolves the fastest with " Car 2 completed " (or analogous " Cat 2 completes " ).

Promise.race resolves with the first settled promise’s value.

In .then, value is " Car 2 completed " and:

let result = `${value} the race.`;

// " Car 2 completed the race. "

Thus result is " Car 2 completed the race. " → option A.

Option A:

this.growl = () = > { ... } inside the constructor creates a new function per instance .

For 1000 new Monster(), you get 1000 distinct growl functions , each stored on the instance itself.

Option B:

Monster.prototype.growl = () = > { ... } attaches growl to the prototype.

All instances share the same single growl function via the prototype chain.

For 1000 instances, only 1 growl method exists in memory.

So: Option A → 1000; Option B → 1.

Semantic versioning: MAJOR.MINOR.PATCH

MAJOR: incompatible API changes.

MINOR: add functionality in a backward compatible manner.

PATCH: backward compatible bug fixes.

Here:

Bug fixes only, no breaking changes → increment PATCH.

From 2.1.1 to 2.1.2.

So the correct new version is 2.1.2.

JSON.stringify() applies the following rules:

String objects (new String( ' false ' )) Are converted to their primitive string values . So:

new String( " false " ) → " false "

Boolean objects (new Boolean(false)) Convert to their primitive boolean value :

new Boolean(false) → false

Undefined values inside arrays According to the JSON specification, undefined becomes null when stringifying an array:

JSON.stringify([undefined]) → " [null] "

Therefore, the array becomes:

[ " false " , false, null]

And JSON.stringify wraps it in quotes:

' [ " false " , false, null] '

This is exactly option A.

JavaScript Knowledge References (text-only)

Object wrappers (String, Boolean) are converted to primitives during JSON serialization.

undefined becomes null inside arrays when stringified.

JSON.stringify() follows the JSON data-model rules strictly.

==================================================