Comparison questionEasy~5 minJavaScript Language & Async Semantics / 9 of 9

Interview question

Which JavaScript equality and coercion rules matter in application code, and how do you avoid surprising comparisons?

Prioritizes explicit normalization, strict equality, object identity, nullish handling, and NaN over coercion puzzles.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I use strict equality by default because it compares values without converting between types. Objects compare by identity, so two separate objects with the same fields are not equal. I normalize external strings, numbers, and booleans at the boundary instead of relying on implicit coercion throughout the application. I also treat nullish values and NaN deliberately.

Full answer below

Practice focus

Whether the candidate knows the small set of comparison rules that prevent real application defects.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
The interview value is safe application behavior, not predicting deliberately obscure coercion puzzles.
I use strict equality by default because it compares values without converting between types. Objects compare by identity, so two separate objects with the same fields are not equal. I normalize external strings, numbers, and booleans at the boundary instead of relying on implicit coercion throughout the application. I also treat nullish values and NaN deliberately.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A form input is a string even when it looks numeric, so I parse and validate it before comparing it with a numeric identifier. I use value == null only if the codebase deliberately wants the narrow loose-equality behavior that matches both null and undefined; otherwise I write the cases explicitly. For NaN, Number.isNaN is clearer than equality because NaN is not equal to itself.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I distinguish equality from domain equivalence. Comparing dates, money, normalized identifiers, or value objects usually needs an explicit rule rather than ===. Object.is differs from strict equality for NaN and signed zero, which matters in a few framework and numeric boundaries but not as general trivia. Consistent parsing and domain comparison functions are safer than teaching every caller the coercion table.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using loose equality as a shortcut for mixed input types.
Expecting separate object literals with the same fields to be equal.
Comparing NaN with ordinary equality.
Turning the answer into a list of obscure coercion puzzles.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

External data is compared before parsing or validation.
Identity equality is used where domain value equality is required.
The answer recommends one operator without discussing boundary normalization.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why are two equal-looking objects not strictly equal?
How would you compare domain values such as dates or money?
When is Object.is observably different from ===?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Next in path

Move forward in the planned practice sequence.

Structural typingMove from JavaScript runtime values to TypeScript's compile-time model.

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.

About the creator Editorial standards

Was this drill useful?