How do you correctly check for NaN? | Interview Question

Q: How do you correctly check for NaN?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every coercion and comparison result below was actually run in Node. ## 1. Why This Even Matters — A Story First Asking a bouncer "is this person over 21?" and getting "yes" back sounds definitive — until you learn the bouncer first tried to convert the person's PET into a human age before answering, and the pet genuinely failed that conversion, so the bouncer said "yes" about the failed conversion rather than the actual person. The global `isNaN()` behaves exactly like that confused bouncer — it converts its input first, then reports on the CONVERSION's success, not on whether the original value itself was ever `NaN`. ## 2. The Core Idea 📌 **Interview term:** `NaN === NaN` is genuinely `false`, so equality alone can never detect it. `Number.isNaN()` is th

01

Understand the problem

Question presented to candidate: "isNaN('hello') returns true. Does that mean the string 'hello' actually IS NaN? What's really happening there, and what should you use instead?"

What a strong answer should cover:

📌 Interview term: NaN === NaN is false — the famous, real starting trap: NaN is the one value in JavaScript that is genuinely never equal to itself under ===, so equality comparison alone can never detect it.
📌 Interview term: the global isNaN() — verified directly: it genuinely coerces its argument to a number FIRST, then checks if the coerced result is NaN — this is exactly why isNaN("hello") is true: "hello" isn't literally the value NaN, it just genuinely FAILS numeric coercion, producing NaN, which the global function then reports.
📌 Interview term: the real, direct answer to the prompt — verified directly: "hello" is genuinely not NaN itself; isNaN("hello") being true is a real, misleading side effect of coercion, not a report that the string literally holds the value NaN. Number.isNaN("hello") — the correct, precise check — genuinely does NOT coerce at all, correctly returning false.
📌 Interview term: Number.isNaN() — verified directly: it only returns true for the value that is LITERALLY NaN (including the real result of 0/0) — no coercion, no false positives for non-numeric strings.
A precise answer names Object.is(x, NaN) as a real, valid alternative producing the identical correct result to Number.isNaN(x), since Object.is (unlike ===) is specifically defined to treat NaN as equal to itself.

Clarifying questions expected:

None — this is a definitional/technical question; directly answering WHY isNaN("hello") is misleadingly true (coercion, not literal NaN) is the strong signal.

Code / implementation expected: Yes — the direct side-by-side isNaN() vs. Number.isNaN() comparison on the exact same inputs is the clearest, most convincing demonstration.

nan

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every coercion and comparison result below was actually run in Node.

1. Why This Even M

Solution ready — 2 min read

Classified // press E to declassify

04

Run the code

JSReal proof: the global isNaN() coerces first (giving a misleading true for 'hello'), while Number.isNaN() correctly does not coerce

Practice

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.