- What does the code log?
Answer: (edi)
When you see nested template literals combined with a ternary operator, slow down and evaluate the condition first before worrying about the string formatting.
Here, active is false, so the ternary active ? ... : ... takes the false branch: ` (${role.slice(0, 3)}) . Now you just need to evaluate role.slice(0, 3). The string "editor" has characters at indices 0 (e), 1 (d), and 2 (i) — slice(0, 3) extracts from index 0 up to (but **not including**) index 3, giving you "edi". Wrapping that in parentheses produces "(edi)"`, making B the correct answer.
A (EDITOR!) would be the result if active were true, which triggers the true branch: ` ${role.toUpperCase()}! . It's a classic trap — the toUpperCase()` and exclamation mark are visually prominent, so you might assume that's the output without checking the condition.
C ((editor)) is wrong because it ignores the .slice(0, 3) call. You might land here if you see role inside the false branch and assume the entire string is used unchanged.
D (edi!) mixes pieces from both branches — the sliced text from the false branch and the ! from the true branch. That's not how ternaries work; only one branch ever executes.
A good habit: always resolve the condition first, then trace only the branch that actually runs. Ternaries inside template literals can look complex, but they execute one path at a time just like any other ternary.
- What does the code log?
Answer: 2-6-4
When you see a template literal with multiple expressions, the key is understanding that JavaScript evaluates each ${} expression left to right, and that pre/post-increment operators mutate the variable in place — meaning each expression sees the updated value of n.
Starting with n = 2, let's walk through each slot:
1. ${n++} — this is post-increment: it returns the current value (2), then increments n to 3.
2. ${n * 2} — n is now 3, so this evaluates to 3 * 2 = 6. n remains 3.
3. ${++n} — this is pre-increment: it increments n to 4 first, then returns 4.
The result is "2-6-4", confirming B is correct.
A (2-4-3) reflects a common mistake: treating all expressions as if n is still 2 throughout, and not accounting for how n++ mutates n before the second expression runs.
C (3-6-4) misreads the first slot — if you use ++n (pre-increment) logic on the first expression instead of n++ (post-increment), you'd get 3. But n++ returns the value before incrementing, so the first slot is 2, not 3.
D (3-8-4) compounds both errors — applying pre-increment logic to the first slot and recalculating the second slot with a wrong value of n.
A reliable trick: for n++, think "use it, then change it." For ++n, think "change it, then use it." In template literals, always trace left to right — n's value is live and changing.
- What does the code log?
Answer: 3 items cost $12.00
When you see template literals (backtick strings) with embedded expressions, trace each ${} placeholder carefully — that's exactly what this question tests.
The template string has three dynamic parts. First, ${units} simply inserts 3. Second, ${units === 1 ? "" : "s"} is a ternary: since units is 3, not 1, the condition is false, so it inserts "s" — making the word "items." Third, ${units * price} computes 3 * 4 = 12, and notice the surrounding text includes a literal $ sign before the ${} placeholder, written as $$. The first $ is just a plain dollar sign character; the second $ opens the template expression. So the output reads $12. Combine everything and you get 3 items cost $12.00 — which is C.
A (3 item cost $12.00) is wrong because it drops the "s". This would only happen if units === 1 were true, but units is 3, so the ternary returns "s".
B (3 items cost 12.00) is wrong because it omits the dollar sign. The $$ in the template means one literal $ followed by the expression delimiter — the dollar sign is part of the output.
D (3 items cost $34.00) reflects a misreading of units * price as 3 + 4 = 7 or as string concatenation "34" — but since both variables are numbers, * performs multiplication: 3 × 4 = 12.
Tip: When reading template literals, parse them character by character. A bare $ not followed by { is just a literal dollar sign — don't confuse it with the interpolation syntax ${}.
- What does the code log?
Answer: x=[3], y=[2]
When you see a tagged template literal like ` label... `, recognize that the function receives two things: an array of the static string parts split around the expressions, and a rest array of the evaluated expression values. This is the key insight — expressions are always evaluated before being passed to the tag function.
For ` labelx=${2 + 1}, y=${"ab".length} , JavaScript evaluates the expressions first: 2 + 1 becomes 3 and "ab".length becomes 2. So the tag function receives parts = ["x=", ", y=", ""] and values = [3, 2]`.
Now trace through the function: it starts with parts[0] which is "x=", then maps over values. For index 0: ` [${3}]${", y="} → "[3], y=". For index 1: [${2}]${""} → "[2]". Joining those and appending to "x=" gives **x=[3], y=[2]`** — answer D.
A (x=3, y=2) is wrong because it ignores the bracket wrapping [${value}] in the template — each value gets wrapped in square brackets by the map function. B (x=3[3], y=2[2]) imagines the raw expression text appearing alongside the evaluated value, which isn't how tagged templates work. C (x=[2 + 1], y=[2]) is the trickiest trap — it assumes expressions are passed as unevaluated source strings, but JavaScript always evaluates interpolated expressions before passing them to any function, tagged or not.
When studying tagged templates, always remember: the tag function sees evaluated values, never raw expression source code.
- What does the code log?
Answer: Cost: ${item} = pen
When working with JavaScript template literals (backtick strings), the key skill is distinguishing between escaped interpolation syntax and active interpolation syntax.
Template literals use ${...} to embed expressions. However, when you place a backslash before the dollar sign — \${...} — you're escaping it, which tells JavaScript to treat it as a literal string of characters rather than evaluating the expression inside. This is the core mechanic being tested here.
In the code, message contains two placeholders: \${item} and ${item}. The first is escaped, so JavaScript prints it literally as ${item}. The second is a real interpolation, so JavaScript evaluates item (which holds "pen") and substitutes it. That gives you Cost: ${item} = pen, making A the correct answer.
B is wrong because it assumes both placeholders were evaluated — but the backslash in the first one prevents that. C keeps the backslash in the output (\${item}), but the backslash itself is an escape character and doesn't appear in the final string — only ${item} prints, not \${item}. D would be correct if neither placeholder was evaluated, which would only happen if the string used regular quotes instead of backticks.
A useful tip: whenever you see a backslash before $ in a template literal, mentally flag it as "frozen" — it won't be evaluated, and the backslash disappears. Only the bare ${...} syntax (no backslash) triggers interpolation. Watch for this escape pattern in exam questions; it's a common trap.
- What does the code log?
Answer: Mina: 0/7
When you see template literals combined with nullish coalescing (??), the key question to ask is: *what values does ?? actually treat as "nullish"?*
The nullish coalescing operator (??) returns the right-hand side only when the left-hand side is null or undefined — nothing else. This is critically different from the logical OR operator (||), which falls back on any falsy value, including 0, "", and false.
Here, user.scores[0] is 0. Since 0 is not null or undefined, the expression user.scores[0] ?? "N/A" evaluates to 0 itself. Meanwhile, user.scores.length - 1 equals 1, so user.scores[1] is 7, making last = 7. The template literal assembles "Mina: 0/7", confirming C is correct.
Choice A is the classic trap here — it assumes ?? treats 0 as nullish and falls back to "N/A". That's what || would do, not ??. Choice B similarly misunderstands the operator, imagining it somehow returns a boolean false. Choice D reverses the two scores — scores[0] is 0 and last is 7, not the other way around. The variable name last is a helpful clue: it's grabbing the final element using length - 1.
Study tip: Always distinguish ?? from || on JavaScript exams. Ask yourself: "Is this value nullish (null/undefined), or just falsy (0, "", false)?" The ?? operator only cares about the former.
- What does the code log?
Answer: ?q=a%20b&page=3
When you see template literals combined with function calls and expressions, slow down and evaluate each interpolated piece separately before reading the final result.
Inside the template literal, ${encodeURIComponent(term)} calls the built-in encodeURIComponent() function on the string "a b". This function converts characters that aren't URL-safe into percent-encoded equivalents — a space becomes %20. So that portion resolves to a%20b. The second interpolation, ${page + 1}, evaluates the arithmetic expression 2 + 1, which equals 3. Combining everything, the full string becomes ?q=a%20b&page=3, making D correct.
A is wrong because it shows the raw string a b with an unencoded space. That would only happen if you used the term directly without encodeURIComponent(), like ${term}. B reflects a fundamental misunderstanding — it treats encodeURIComponent(a b) as literal text, as if the function call isn't executed. In JavaScript, any valid expression inside ${} is evaluated, not printed as code. C gets the encoding right (a%20b) but makes a type-coercion mistake on the second expression. If page were a string "2" and you wrote ${page + 1}, JavaScript would concatenate rather than add, giving "21". But here page is declared as a number, so 2 + 1 is arithmetic addition, not string concatenation.
As a study tip, whenever you see ${} in a template literal, ask yourself: "What type is each variable, and what does each operator or function actually return?" Type awareness prevents both the concatenation trap in C and the literal-text trap in B.
- What does the code log?
Answer: 2,4,6|1-2-3
When you embed an expression inside a template literal using ${}, JavaScript automatically calls .toString() on whatever value that expression returns. This question tests whether you know how arrays convert to strings — and how that differs from using .join() explicitly.
The expression values.map(n => n * 2) produces the array [2, 4, 6]. When that array lands inside the template literal, JavaScript calls .toString() on it, which is equivalent to calling .join(",") — joining elements with a comma by default. So the left side becomes "2,4,6". The right side, values.join("-"), explicitly uses a hyphen as the separator, producing "1-2-3". Combined with the pipe character in the template, the full result is "2,4,6|1-2-3", which is A.
B is wrong because it shows 2-4-6, implying the mapped array was joined with hyphens — but .toString() on an array always uses commas, not hyphens. C is wrong for a subtler reason: it shows 1,2,3 on the right side, as if .join("-") also used commas instead of the hyphen you explicitly passed. D is wrong because it reverses the two sides — the mapped values appear on the right and the original array on the left, which contradicts the order written in the code.
The key tip to remember: any array placed inside a template literal (or coerced to a string) uses commas by default, just like calling .join() with no argument. If you want a different separator, you must call .join(separator) explicitly.
- Which escaped representation exactly matches the value of
text? Answer: A\n b\nC
When you see a template literal in JavaScript, you need to mentally "render" it — preserving every character exactly as written, including whitespace and newlines, then evaluating any embedded expressions.
In this template literal, the first line contains A, followed immediately by a newline (pressing Enter in the source). The second line has two spaces before ${"B".toLowerCase()}. The expression "B".toLowerCase() evaluates to "b" (lowercase). After that interpolated value, there's another newline. The third line contains C. So the full string is: A, newline, two spaces, b, newline, C — which in escaped form is exactly A\n b\nC, making B the correct answer.
A (A\nb\nC) is wrong because it drops the two leading spaces on the second line. This is a common trap — students forget that whitespace inside a template literal is literal and preserved exactly.
C (A\n B\nC) is wrong because it keeps the spaces but fails to apply .toLowerCase(), leaving B uppercase. The expression does run — "B".toLowerCase() always returns "b".
D (A \n b\n C) is wrong in two places: it adds a trailing space after A on the first line and a leading space before C on the third line, neither of which exist in the source.
As a study tip, always read template literals character-by-character, treating indentation as meaningful content. Unlike regular strings, template literals do not trim whitespace — what you type is exactly what you get.
