Free lesson · JavaScript Basic to Advance

Interview Lens: Type Coercion

Easy5 min read

The Question

"Can you explain the difference between == and ===? And while we're at it, can you predict the output of these expressions for me?"

The interviewer slides over a whiteboard with a list of expressions on it:

"5" + 3
"5" - 3
null == undefined
null === undefined
[] == false
{} + []
0.1 + 0.2 === 0.3
typeof null
NaN === NaN

This is the JavaScript type-coercion interview, and it shows up in nearly every JavaScript-focused onsite. Sometimes it's framed as a conceptual question ("explain coercion"). Sometimes it's an output-prediction puzzle ("what does this print"). Sometimes it's combined into one: explain the concept, then prove you understand it by predicting outputs.

Hi, I'm Arun. I work on iOS Frameworks at Apple. I'm the youngest founder on the AlgoInsight team and the one with the freshest memory of being on the other side of these interviews — fourteen consecutive rejections before I got my Apple offer. Type coercion questions came up in at least eight of those fourteen interviews. This Topic is what I wish I'd known before any of them.

Why They Ask It

This question is a depth check. It's not really about whether you can predict that "5" + 3 produces "53". The interviewer can see that answer on Stack Overflow. What they're checking is whether you understand JavaScript at the level of "I know why."

Three signals the interviewer is listening for:

Signal 1: Do you know the rules, or do you guess? A candidate who guesses will sometimes get answers right and sometimes wrong. A candidate who knows the rules can trace through any expression and arrive at the correct answer reliably.

Signal 2: Do you write defensive code? A developer who understands coercion intuitively will use === by default, will prefer explicit conversion like Number(x) over implicit conversion, and will catch coercion bugs in code review. A developer who doesn't will ship bugs and not know why their if (count) fails when count is zero.

Signal 3: Can you reason under pressure? Type coercion questions force you to slow down and think step-by-step in front of someone watching. The interviewer is testing whether you panic and guess, or whether you systematically work through the rules. This is a meta-skill — it applies to every interview question, not just coercion ones.

When I bombed my early interviews, I didn't fail because I didn't know the answers. I failed because I knew them when relaxed and forgot them when watched. The rules are the easier part. The pressure response is harder.

Interactive animation: The same knowledge, landing two ways - naming the rule out loud against guessing straight at an answer.

The Wrong Answers

Warning: The three wrong answers interviewers hear most often.

"== and === are basically the same, but === is stricter." This answer is incomplete in a way that signals you've heard the words without understanding the mechanism. "Stricter" doesn't explain anything. The right framing: === compares without coercion, == coerces first. Naming the mechanism, not the vibe.

"Use == when you want to be flexible, use === when you want to be safe." Wrong. You should almost never use ==. Calling it "flexible" implies it's a legitimate alternative for normal use. It isn't. The legitimate use case for == is narrow: value == null to check for both null and undefined. Beyond that, == is a footgun.

"typeof null returns 'null'." It doesn't. It returns 'object'. This is a famous bug from JavaScript's 1995 origin. A candidate who answers this question wrong has signaled they haven't studied JavaScript's quirks. A candidate who knows the right answer and knows the historical reason has signaled real depth.

The Right Answer

The right answer has three layers depending on how much the interviewer wants to hear. Match your answer to the moment.

The 30-Second Answer

For when the interviewer is checking a box and wants to move on:

"=== is strict equality — it compares value and type without any conversion. == is loose equality — it converts the operands to a common type before comparing. I use === by default in nearly all code. The one place == is sometimes acceptable is value == null, which catches both null and undefined."

That's enough for most warm-up moments. Stop here unless the interviewer pushes.

The 2-Minute Answer

For when the interviewer wants to see your reasoning:

Start with the 30-second answer. Then add:

"The reason == is dangerous is that the coercion rules are complex and not always intuitive. For example, 0 == false is true, 0 == "" is true, but "" == "0" is false. The transitive property doesn't hold. That makes loose equality hard to predict and easy to introduce bugs with.

=== doesn't have this problem because no coercion happens. If two values aren't already the same type, they're not equal. The behavior is uniform.

The one common exception is value == null. JavaScript has a special rule that null and undefined are loosely equal to each other but to nothing else. So value == null works as a shortcut to check for both, which some style guides allow."

This is the answer for a standard onsite when the interviewer wants to see you reason through the trade-offs.

The Deep Dive

For when the interviewer probes further, especially at senior levels:

Build on the 2-minute answer. Then add:

"Type coercion happens in three directions in JavaScript: toward number, toward string, toward boolean. The direction depends on the operator and the operands. The + operator is uniquely weird — it coerces toward string if either operand is a string, but toward number otherwise. Every other arithmetic operator coerces toward number.

The famous puzzles like [] + [] or [] == ![] all decompose into these rules. [] + [] becomes "" + "" because arrays coerce to strings in a + context. [] == ![] becomes 0 == 0 through five separate coercion steps.

The takeaway for production code: prefer explicit coercion (Number(x), String(x), Boolean(x)) over implicit. Make the intent visible. And use === unless you have a documented reason not to."

This level signals senior fluency. Use it when the interview is at a level where depth is being probed.

Walking Through the Whiteboard Examples

Let's walk through the expressions the interviewer slid over. The right pattern is to think out loud — verbalize the rule you're applying for each.

console.log("5" + 3);              // "53"
console.log("5" - 3);              // 2
console.log(null == undefined);    // true
console.log(null === undefined);   // false
console.log([] == false);          // true
console.log(0.1 + 0.2 === 0.3);    // false
console.log(typeof null);          // "object"
console.log(NaN === NaN);          // false

For each one, the verbal trace under interview pressure would be:

"5" + 3 → "The + operator with a string operand triggers string concatenation. The number 3 coerces to '3'. Result: '53'."
"5" - 3 → "The - operator only does numeric subtraction. The string '5' coerces to the number 5. Result: 2."
null == undefined → "The special-case rule: null and undefined are loosely equal. Result: true."
null === undefined → "Strict equality requires same type. Null and undefined are different types. Result: false."
[] == false → "Both sides coerce toward number. False becomes 0. Empty array becomes empty string, then empty string becomes 0. 0 equals 0. Result: true."
0.1 + 0.2 === 0.3 → "Floating-point representation can't store 0.1 + 0.2 exactly. The result is 0.30000000000000004. Result: false."
typeof null → "Famous bug from 1995. Returns 'object', not 'null'."
NaN === NaN → "By specification, NaN is never equal to anything, including itself. Result: false."

Notice the pattern. Each answer names the rule, applies it to the specific operands, and arrives at the result. This is what "thinking out loud" looks like for type coercion. It's not just stating the answer — it's showing the reasoning that produces the answer.

Interactive animation: The four-step read - a way to trace any expression they invent, naming each rule before the result.

The Follow-Ups

Interview: What the interviewer asks next after you've answered well.

"How would you safely check whether two values are equal?" They want to hear you mention === for most cases, Object.is() for the edge cases involving NaN and signed zero, and a deep-equality function for objects. Bonus points for mentioning that Object.is(NaN, NaN) returns true while NaN === NaN returns false.

"What are all the falsy values in JavaScript?" This is a list test. The six values: false, 0, "", null, undefined, NaN. Missing NaN is the most common mistake. Bonus: also mention 0n (bigint zero) and -0 for completeness.

"What does typeof return for each primitive type?" Another list test. "string", "number", "boolean", "undefined", "object" (for null — the bug), "object" (for actual objects), "function" (the special case), "symbol", "bigint".

"Why does 0.1 + 0.2 not equal 0.3?" They want to hear "floating-point representation" or "IEEE 754." Bonus: explain that this is true in most languages, not just JavaScript, and that for financial math you'd work in integer cents to avoid the precision problem.

"What's the difference between null and undefined?" Hit three points: undefined is automatic and means "not set"; null is deliberate and means "intentionally empty"; they're loosely equal to each other but to nothing else.

The Founder Moment

I'll tell you about the first time I bombed this question. It was my fourth interview, at a Series B startup, June 2023. The interviewer asked me to predict the output of "5" + 3 - "1". I knew the rules. I'd read the rules a week earlier. But in the moment, with someone watching, my brain skipped a step. I said "4". The interviewer waited. I corrected to 7. He waited longer. I started over, traced through it carefully, and got to the right answer: 51. ("5" + 3 concatenates to "53", then "53" - "1" is numeric subtraction, producing 52... wait, that's 52, not 51. Let me redo it. "53" - "1" is 53 - 1 is 52.)

Three minutes for one question. The interviewer didn't say anything about it, but I knew I'd burned the goodwill I needed for the harder questions later. I didn't get the offer.

What I learned: the answer is the easier part. The harder part is staying calm while you trace through the rules. After that interview, I built a flashcard deck of coercion expressions and went through them every morning for three weeks. By interview eight, I could trace "5" + 3 - "1" in fifteen seconds without flinching. By Apple, the type coercion questions felt routine.

The rules are learnable. The composure is trainable. Both take practice.

Back to JavaScript Basic to Advance