From the ai augmented javascript sample test

When does AI-generated `==` belong, and when should it be `===`?

The item shows a candidate an AI-generated input-validation function that uses == (loose equality with type coercion) to compare a string against a numeric form input value, and asks whether the AI’s choice is correct, accidental, or context-dependent. The question probes a category of AI-generated code that defies easy “always X” review rules: the strict equality operator === is the right default in nearly all JavaScript code, but there is exactly one widely accepted idiom where loose == is preferred, and reviewers need to know it cold to grade AI suggestions correctly.

What this question tests

The concept under test is the type-coercion semantics of == versus === and the one defensible idiom (x == null to match both null and undefined) where loose equality is preferred over strict. The ECMAScript specification defines === as the Strict Equality Comparison and == as the Abstract (now “loose”) Equality Comparison; the latter applies a type-coercion algorithm before comparison that produces counterintuitive results for some operand pairs ('' == 0 is true, '0' == false is true, [] == 0 is true).

AI assistants generate == for two distinct reasons. First, training data from the long pre-2015 era of JavaScript heavily uses ==, and AI models occasionally regress to that style when generating code in a less-constrained context. Second, some prompts explicitly ask for “null-or-undefined” checks where x == null is the idiomatic shorthand. The senior reviewer’s job is to distinguish the two cases: the first is a bug to fix, the second is correct as written.

Why this is the right answer

The correct answer is that === should be the default nearly everywhere, and the one exception is the x == null (or x != null) idiom for null-or-undefined checks. Walking through the specific cases:

// Correct: strict equality for typed comparisons
if (formValue === '0') { ... }
if (count === 0) { ... }
if (status === 'pending') { ... }

// Bug: AI-generated loose equality where types matter
if (formValue == 0) {
  // matches '0', 0, '', false, '\t\n', '0.0', and more
  // — almost certainly not what was intended
}

// Correct: the one idiomatic loose-equality use
if (user.middleName == null) {
  // matches both null and undefined, nothing else
  // shorthand for: middleName === null || middleName === undefined
}

The mental model that holds up under review is: === for everything except the single == null idiom. Most modern linter configs (eslint:recommended, Airbnb, Standard) ban == outright and require explicit x === null || x === undefined; some teams allow the == null exception via the ESLint eqeqeq rule’s allow-null option. Both stances are defensible, and the review question is whether the AI-generated code matches the team’s stance.

The coercion table for == is published in the spec and worth memorizing for reviewers:

'' == 0           // true (string coerced to number)
'0' == false      // true (both coerced to number)
null == undefined // true (special-cased in the spec)
NaN == NaN        // false (NaN is not equal to itself)
[] == false       // true (array coerced through string)
[1] == 1          // true (single-element array coerced)

The unintended true results from these comparisons are exactly why teams ban loose equality: subtle bugs hide behind seemingly-correct comparisons, and code review catches some but not all of them.

What the wrong answers reveal

The plausible wrong options each map onto a different misconception about equality in JavaScript:

  • “== is always wrong; reject any AI suggestion that uses it.” This is too strict. The x == null idiom is widely accepted, documented in MDN, and allowed by the ESLint eqeqeq rule’s allow-null option. Picking this option suggests the candidate has memorized “use ===” without internalizing the exception.
  • “== is fine in most cases; the AI is right.” This is the inverse error and reflects training-data bias toward pre-strict-mode JavaScript. The coercion edge cases ('' == 0, [] == false) cause real production bugs often enough that the default rule has been “use ===” for a decade.
  • “Use Object.is for everything.” Object.is has yet another set of semantics — it differs from === in two cases: Object.is(NaN, NaN) is true (vs false for ===), and Object.is(+0, -0) is false (vs true for ===). It is the right tool for those two specific comparisons; it is not a general replacement for ===, and AI-generated code rarely needs it.

How the sample test scores you

In the AIEH 5-question AI-Augmented JavaScript sample, this item contributes one of five datapoints aggregated into a single ai_js_proficiency score via the W3.2 normalize-by-count threshold. Binary scoring per item: 5 for the correct option, 1 for any of the three wrong options. With 5 binary items, the average ranges 1–5 and the level threshold maps avg ≤ 2 to low, ≤ 4 to mid, > 4 to high.

Data Notice: Sample-test results are directional indicators only. A 5-question sample can’t reliably distinguish between “knows the equality coercion table cold” and “got lucky on these specific items”; for a verified Skills Passport credential, take the full 50-question assessment.

The full assessment probes type coercion across operators, truthiness, the abstract comparison algorithm, and the specific gotchas (NaN, -0, Symbol.toPrimitive) at depth. See the scoring methodology for how AI-Augmented JavaScript scores map onto the AIEH 300–850 Skills Passport scale.

  • Truthiness vs equality. if (x) and if (x == true) are not the same: the first tests the truthiness of x (covering 0, '', null, undefined, NaN, false), while the second runs the loose-equality coercion algorithm with true as the right operand. AI-generated guards occasionally conflate these; reviewing for the difference is part of the loop.
  • switch and strict comparison. switch uses strict comparison (===) for its case matches, which is sometimes surprising to candidates who learned switch in C. AI assistants rarely get this wrong, but knowing the rule helps when reading their output.
  • TypeScript and structural equality. TypeScript does not change the runtime equality semantics; === and == mean exactly what they mean in JavaScript. TypeScript’s contribution is compile-time errors when the operand types guarantee that == would coerce, which catches many AI- generated == bugs before they ship.

For the broader AI-Augmented JavaScript lineup including the full 50-question assessment, see the tests catalog. For broader context on how equality fluency interacts with other technical signals, see cognitive ability in hiring and learn for upskilling resources.

Sources

Try the question yourself

This explainer covers what the item measures. To see how you score on the full ai augmented javascript family, take the free 5-question sample.

Take the ai augmented javascript sample