Pass the Salesforce Developer JavaScript-Developer-I Questions and answers with Dumpstech

First, compute sampleText:

let codeName = ' Bond ' ;

let sampleText = `The name is ${codeName}, Jim ${codeName}`;

The template literal evaluates to:

" The name is Bond, Jim Bond "

Now evaluate each statement:

Option A: sampleText.includes( ' Jim ' );

String.prototype.includes(substring) returns true if substring occurs anywhere in the string.

sampleText clearly contains " Jim " ( " The name is Bond, Jim Bond " ).

So this returns true.

Option B: sampleText.includes( ' The ' , 1);

includes(searchString, position) starts searching from the given position index.

" The name is Bond, Jim Bond " has " The " starting at index 0.

Starting search at index 1 means " The " at index 0 is not considered, and there is no second " The " .

So this returns false.

Option C: sampleText.includes( ' Jim ' , 4);

" Jim " appears after " The name is Bond, " which is longer than 4 characters; the index of " Jim " is well past 4.

So when searching from index 4, " Jim " is still found.

This returns true.

Option D: sampleText.indexOf( ' Bond ' ) !== -1;

String.prototype.indexOf(substring) returns:

-1 if the substring is not found,

Otherwise, the starting index of the first occurrence.

" Bond " appears twice in " The name is Bond, Jim Bond " .

So sampleText.indexOf( ' Bond ' ) is some non-negative index (for the first occurrence).

Therefore indexOf( ' Bond ' ) !== -1 is true.

Option E: sampleText.substring( ' Jim ' );

substring expects numeric indexes: substring(startIndex, endIndex?).

If given a string " Jim " as the argument, JavaScript coerces it to a number:

Number( ' Jim ' ) → NaN

NaN for startIndex is treated as 0.

So sampleText.substring( ' Jim ' ) is effectively sampleText.substring(0), which returns the full string " The name is Bond, Jim Bond " .

This is a string , not a boolean. The question asks “which code statements return true?”

This statement returns a string, not the boolean value true.

Thus, the three statements that actually return true (boolean) are:

Answer: A, C, D

Study Guide / Concept References (no links):

Template literals and ${} interpolation

String.prototype.includes(searchString, position?)

String.prototype.indexOf(substring) and checking for !== -1

String.prototype.substring(start, end?) and argument coercion

Boolean vs non-boolean return types in string methods

We want to guarantee that the result is of type string regardless of what var1 and var2 are (numbers, booleans, etc.).

Option A:

String(var1).concat(var2)

String(var1) converts var1 explicitly to a string.

.concat(var2) calls String.prototype.concat, which:

Converts var2 to string if needed.

Returns a new string that is the concatenation of the two.

Result is always a string. So A is valid.

Option B:

String.concat(var1 + var2)

String.concat (as a static method) does not exist. concat is an instance method on string objects, not on the String constructor.

var1 + var2 might be a number (if both numeric) and used incorrectly here. So B is invalid.

Option C:

var1 + var2

+ can mean:

String concatenation (if at least one operand is a string).

Numeric addition (if both operands are numbers).

If var1 and var2 are both numbers, var1 + var2 will be a number, not a string.

This does not ensure the result is always a string. So C is not guaranteed to satisfy the requirement.

Option D:

var1.toString() + var2.toString()

var1.toString() converts var1 to a string (for most primitive/object types).

var2.toString() does the same.

Now both operands of + are strings, so the result is string concatenation.

Result is guaranteed to be a string. So D is valid.

Therefore, the two valid ways are A and D.

Study Guide / Concept References (no links):

String() conversion vs .toString()

String.prototype.concat

+ operator overload: numeric addition vs string concatenation

Type coercion rules for primitives

Key details:

var has function scope , not block scope.

Declaration var msg is hoisted to the top of the function, but initialization only happens if the if condition is true.

Effectively, the function behaves like:

function getAvailableilityMessage(item) {

var msg; // hoisted declaration

if (getAvailableility(item)) {

msg = " Username available " ;

}

return msg;

}

Now, given:

getAvailableility( " newUserName " ) returns false.

Execution:

The if condition is false, so the body does not execute.

Therefore msg is declared but never assigned .

In JavaScript, an uninitialized variable that has been declared with var has the value undefined.

Thus:

return msg; // returns undefined

Why other options are wrong:

A: " newUserName " – msg never receives the parameter value; it ' s only set to " Username available " inside the if, which does not run.

B: " msg is not defined " – That kind of error occurs if msg were never declared. Here it is declared via var, so it is defined but undefined.

D: " Username available " – This would require the if branch to run, which it does not when getAvailableility(...) is false.

So the return value is:

undefined

Study Guide Concepts:

var hoisting and function scope

Uninitialized variables default to undefined

Control flow and conditional initialization

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 .

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.

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

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.

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

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 .

Key JavaScript Promise rule:

try...catch does not catch asynchronous errors that occur in Promise chains.

Therefore, the correct way to handle errors in a Promise is:

promise.then(...).catch(...);

Analysis of options:

A and B: Both wrap asynchronous code in try...catch, which does not catch Promise rejections. try...catch only catches errors thrown synchronously inside the block.

C: Correct. A .catch() on the Promise chain handles any error from the Promise returned by requestPromise().

D: .finally() executes regardless of success or failure, but it does not receive the error object , so it cannot handle the error.

Thus the only valid solution is option C .

JavaScript Knowledge References (text-only)

Promise rejections must be handled with .catch().

try...catch only handles synchronous code.

.finally() does not receive a rejection reason.

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

Behavior of Promise.prototype.finally:

.finally(handler) registers a callback that runs when the promise is settled , meaning:

Either fulfilled (resolved) , or

rejected .

Important points:

The finally callback does not receive the promise’s value or error (unlike then and catch).

It is executed after the promise is settled, but before the resolution value or rejection reason is passed further down the chain.

It runs in both success and failure paths.

In the given code:

The promise may either:

Call reject( ' fraction > 0.5, ' + fraction) if fraction > 0.5, or

Call resolve(fraction) otherwise.

In both cases:

If it resolves , .then(() = > console.log( ' resolved ' )) runs, and then .finally(...) is executed.

If it rejects , .catch((error) = > console.error(error)) runs, and then .finally(...) is executed.

So .finally runs:

Not just “when rejected”.

Not just “when resolved”.

But whenever the promise is resolved or rejected .

Therefore, the correct choice is:

D. When resolved or rejected .

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