The Salesforce Certified JavaScript Developer (JS-Dev-101) (JavaScript-Developer-I)

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

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.

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

The correct answer is D , because JavaScript executes synchronous code first, while the code after await runs later after the Promise resolves.

The execution order is:

console.log(2);

This runs first, so JavaScript logs:

2

Then this line runs:

asyncCall();

The asyncCall() function starts executing. Inside it, JavaScript reaches:

await delay(1000);

The delay(1000) function returns a Promise that resolves after 1000 milliseconds:

return new Promise(resolve = > {

setTimeout(resolve, delay);

});

Because await pauses the rest of the asyncCall() function, this line does not run immediately:

console.log(1);

Instead, JavaScript continues executing the remaining synchronous code outside the async function:

console.log(3);

So JavaScript logs:

3

After approximately 1000 milliseconds, the Promise returned by delay(1000) resolves. Then the paused async function continues and runs:

console.log(1);

So JavaScript logs:

1

Final console output:

2

3

1

Important JavaScript concepts involved:

An async function always returns a Promise.

The await keyword pauses execution only inside the async function where it appears.

Code outside the async function continues running normally.

setTimeout() schedules its callback to run later, after the current synchronous code has finished.

Therefore, the verified answer is D. 2 3 1 .

The correct answer is C .

The browser provides the History API through:

window.history

To add a new entry to the browser’s session history without refreshing the page, JavaScript uses:

window.history.pushState(state, title, url);

So the valid statement is:

window.history.pushState(newStateObject, ' ' , null);

This updates the browser history stack without forcing a full page reload. It is commonly used in single-page applications when changing views or routes dynamically.

The method accepts three arguments:

window.history.pushState(stateObject, title, url);

stateObject stores custom data associated with the history entry.

title is usually passed as an empty string because many browsers ignore it.

url optionally changes the displayed URL. Passing null means no new URL is provided.

Option A is incorrect because:

window.customHistory

is not the standard browser History API object.

Option B is incorrect because:

createState()

is not a valid History API method.

Option D is incorrect because:

updateState()

is not a valid History API method.

The correct browser API method is:

window.history.pushState()

Therefore, the verified answer is C .

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

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.

Comprehensive and Detailed Explanation:

Evaluate step by step:

' 15 ' + 10

+ with a string operand performs string concatenation.

10 is coerced to ' 10 ' .

Result: ' 1510 ' .

' 1510 ' * 2

* always performs numeric multiplication.

' 1510 ' is converted to the number 1510.

1510 * 2 = 3020.

So x is 3020.

FishingBoat extends Ship, so it is a subclass. In ES6 classes:

When you define a constructor in a subclass, you must call super(...) before accessing this.

super(size) calls the parent class (Ship) constructor, which sets this.size = size.

So the correct constructor is:

class FishingBoat extends Ship {

constructor(size, capacity) {

super(size); // line 09

this.capacity = capacity;

}

displayCapacity() {

console.log(`The boat has a capacity of ${this.capacity} people.`);

}

}

Why others are incorrect:

B. ship.size = size;

ship is not defined; this would cause a ReferenceError.

C. super.size = size;

super is not an instance; you must call super(...) as a function to invoke the parent constructor.

D. this.size = size;

In a subclass constructor, you must call super() before using this, otherwise you get a ReferenceError. Also this bypasses the parent constructor logic.

Relevant concepts: ES6 class inheritance, extends, super() in subclass constructors, this initialization rules.

In a reduce callback, you must return the new accumulator value.

Currently:

(result, current) = > {

result += current;

// no return

}

This returns undefined each time, so the accumulator becomes undefined on the next iteration, leading to incorrect results.

Fix by returning result:

const sumFunction = arr = > {

return arr.reduce((result, current) = > {

result += current;

return result; // line 05

}, 10);

};

Option D correctly adds the return.

Options A/B/C do not fix the missing return in the reducer and therefore do not resolve the core issue.