Master equals in C by spotting 7 interview traps: = vs ==, assignment results, precedence, strings, pointers, floats, and aliases.
Most candidates who blank on equals-sign questions in C interviews already know the symbols. The problem with understanding equals in C is not vocabulary — it's that nobody told them where the language diverges from what they'd intuitively expect, and interviewers know exactly which three or four questions will expose that gap. This guide covers those seven traps directly, with the kind of concrete examples you can reason through out loud under pressure.
== vs =: the mistake interviewers actually care about
The typo that is not really a typo
Writing `=` when you meant `==` inside a condition is not a typo. It reveals that the candidate has not fully separated two different operations in their mental model: one that stores a value and one that tests a relationship. In C, `=` is the assignment operator — it puts a value into a variable and then evaluates to that value. `==` is the equality operator — it tests whether two operands are equal and evaluates to 1 or 0. Those are fundamentally different jobs, and interviewers ask about this distinction first because it tells them whether the candidate thinks in terms of state mutation versus state inspection.
The reason this error survives in real code is that C's grammar allows assignment inside a conditional expression. The compiler does not reject `if (x = 5)` — it compiles it and runs it. Many compilers, including GCC, will emit a warning like `warning: suggest parentheses around assignment used as truth value`, but only if warnings are enabled. That warning is the only safety net.
What this looks like in practice
The first `if` block always executes, regardless of what `x` was before it. The assignment changes program state and then the condition evaluates the assigned value, not the original one. A candidate who wrote this in a take-home exercise once told me they only caught it because GCC flagged it with `-Wall`. Without that flag enabled, the program ran, printed something, and looked correct — until they checked what `x` contained afterward.
GCC's warning documentation covers `-Wparentheses`, which specifically targets this pattern. Enabling `-Wall` during practice is not optional.
Why C comparison operators return 1 or 0, not true and false
The truthiness model C actually uses
The comparison operators in C do not return a boolean type by default — they return an integer. Specifically, a true comparison evaluates to `1` and a false comparison evaluates to `0`. C99 introduced `_Bool` and the `<stdbool.h>` header, which gives you `true` and `false` as macros, but the underlying values are still 1 and 0. If you write C89 or simply do not include `<stdbool.h>`, there is no `true` keyword. The language treats any nonzero integer as true in a conditional context, and zero as false.
This matters in interviews because a candidate who says "the condition returns true" without knowing what that means in C terms sounds like they're importing assumptions from Python or Java. The precise answer — "it evaluates to 1 or 0, and the if statement treats nonzero as the branch condition" — signals a different level of understanding.
What this looks like in practice
A candidate who ran this during prep once said they expected `result` to print `true`. When it printed `1`, they assumed something was wrong. Nothing was wrong — that is exactly how C works. The `1` flows into the `if` as a nonzero integer, the branch executes, and the language never produces a string representation of truthiness on its own. The C standard reference at cppreference.com confirms that relational and equality operators yield `int` values of 0 or 1.
Use all six comparison operators without guessing
The whole family, not just == and !=
The equality operator in C is `==`, but it belongs to a larger family of six comparison operators that all share the same return behavior: they yield 1 when the condition holds and 0 when it does not. Treating them as a family — rather than memorizing each one in isolation — makes it easier to reason about them under pressure. The six are: `==` (equal), `!=` (not equal), `<` (less than), `>` (greater than), `<=` (less than or equal), and `>=` (greater than or equal).
What this looks like in practice
This is the kind of compact reference that belongs on a prep notes page. Each line is a complete thought, and the result follows directly from the operator's definition. The cppreference comparison operator page groups relational and equality operators together and confirms this behavior across all six.
The one thing worth memorizing: `<=` and `>=` are two-character operators, and the order matters — `=<` is not valid C. That is a real mistake candidates make when writing quickly.
Stop writing comparisons that break in if statements and loops
Why conditions are where mistakes show up
An isolated comparison expression that evaluates to the wrong value is harmless. The same mistake inside an `if` or a loop condition becomes a control-flow bug — it changes which branches execute and how many times a loop runs. This is why interviewers care about comparison operators in C in the context of control flow, not just as standalone expressions. A candidate who understands the operator but writes the wrong one in a condition has a bug that will not crash, will not throw an exception, and will produce output that looks plausible until someone checks the logic carefully.
What this looks like in practice
During interview prep, a candidate wrote the second version while trying to test whether `i` had reached 5. The loop never terminated. The assignment `i = 5` evaluates to 5 on every pass through the condition, which is always nonzero, so the loop runs forever. The compiler's treatment of assignment-in-condition as a valid expression is what makes this survivable code that still compiles cleanly.
Operator precedence is where = and == start causing real bugs
The bug that looks fine until you read it twice
The == vs = in C distinction gets more dangerous when both operators appear in the same expression. Operator precedence in C is not always intuitive, and a line that looks like a comparison can silently become an assignment depending on how the compiler parses it. The assignment operator has lower precedence than most comparison operators, but that ordering only helps you if you know the precedence table. Most beginners do not carry it in memory — they read left to right and assume the expression does what it looks like.
The real trap is an expression like `if (result = a == b)`. The eye reads this as "assign the result of comparing a and b," which is actually what it does — but only because `==` has higher precedence than `=`. Swap the operators and the meaning changes completely.
What this looks like in practice
GCC produces `warning: suggest parentheses around comparison in operand of '='` on the first version. That warning is doing real work. The GCC warning flags documentation explains how `-Wparentheses` catches exactly this pattern. In practice, the safe rule is: if you need both operators in one expression, use parentheses to make the order explicit, not to rely on precedence to do the right thing silently.
Strings are where == stops working the way people expect
Why two identical strings are not the same thing
String comparison in C is the trap that surprises candidates who learned to compare strings with `==` in Python, Java, or JavaScript. In C, a string is an array of characters stored somewhere in memory, and a string variable or literal is represented as a pointer to the first character of that array. When you write `str1 == str2`, you are not comparing the text content — you are comparing two memory addresses. Two strings with identical content but stored in different locations will not compare equal with `==`.
This is not a quirk or a bug. It is a direct consequence of how C represents strings: as `char *` pointers, not as first-class objects with built-in comparison semantics. If you understand that, the need for `strcmp` becomes obvious rather than arbitrary.
What this looks like in practice
The `==` result is implementation-defined because some compilers intern string literals (store them at the same address), so `s1 == s2` might accidentally return 1. That makes the bug worse: it passes on one compiler, fails on another. A candidate who spent an afternoon trying to compare string literals with `==` before discovering `strcmp` described it as "the most confusing thirty minutes of my C prep" — because the code worked on their machine and failed in the grader. The Linux man page for strcmp documents the correct approach: `strcmp` returns 0 for equal strings, a negative value if the first is lexicographically less, and a positive value if greater.
Pointer equality is not value equality
The address question interviewers are really asking
Pointer comparison in C with `==` tests whether two pointers hold the same address — whether they point to the same location in memory. It does not test whether the values stored at those addresses are equal. Interviewers ask about this because candidates often blur the two: they say "I'm checking if they're equal" without specifying equal in what sense. The answer that impresses is the one that names the distinction immediately.
What this looks like in practice
During a debugging session, a candidate was checking whether two nodes in a linked list held the same data. They wrote `if (node1 == node2)` and wondered why the branch never executed when the values matched. The pointer comparison was technically correct — it correctly determined that `node1` and `node2` were different objects. But the actual goal was `node1 == node2`, comparing the stored values. The distinction is one character (`*`) and one entirely different semantic question.
Floating-point equality is the trap that sounds obvious until it isn't
Why == is the wrong tool for most float checks
Floating-point numbers in C are stored in binary with finite precision. Most decimal fractions — including simple ones like 0.1 — cannot be represented exactly in binary floating-point. When you perform arithmetic on floats, the result accumulates rounding errors at the hardware level. Two values that should be mathematically equal often differ by a tiny amount in their binary representation, so `==` returns 0 even though the values look identical when printed.
This is not a C-specific problem — it is a consequence of IEEE 754 floating-point representation, the standard that governs float arithmetic in virtually every modern language and processor. C exposes this directly because it does not abstract away the hardware.
What this looks like in practice
The correct approach for float comparison is a tolerance check:
A candidate building a simple calculator during prep spent an hour debugging a test case where `0.1 + 0.2 == 0.3` returned false. The values printed identically with two decimal places. Only when they increased the print precision did the rounding difference become visible. Interviewers like this answer because it demonstrates that the candidate understands the hardware, not just the syntax.
How Verve AI Can Help You Prepare for Your Interview With Understanding Equals in C
The structural problem this article has laid out is not that these seven traps are obscure — it's that knowing them on paper and explaining them cleanly under live questioning are two different skills. When an interviewer asks "why can't you use == for strings in C?" you need to produce a clear, confident answer in real time, not a correct-but-halting one. That requires rehearsal under realistic conditions, not re-reading notes.
Verve AI Interview Copilot is built for exactly that gap. It listens in real-time to your spoken answers and responds to what you actually said — not a canned prompt — so you can practice the follow-up questions that trip candidates up most. Say you explain the `==` vs `=` distinction correctly but vaguely. Verve AI Interview Copilot can push back with "what does the compiler actually do with that expression?" and force you to be more precise. That kind of dynamic pressure is what separates candidates who memorized the material from candidates who understand it. Verve AI Interview Copilot stays invisible during live sessions, so you can use it right up to the moment of the real interview. If you want to stop sounding uncertain when the equals-sign question comes up, the fastest path is saying the answer out loud to something that can actually respond.
FAQ
Q: What does == mean in C, and how is it different from =?
`==` is the equality operator — it tests whether two values are equal and returns 1 (true) or 0 (false). `=` is the assignment operator — it stores a value into a variable and evaluates to that stored value. The critical difference is that `=` changes program state while `==` only inspects it. Writing `=` inside an `if` condition is valid C syntax and will compile, which is exactly why interviewers test this distinction.
Q: Why does a comparison in C return 1 or 0 instead of true or false?
C's type system does not have a native boolean type in C89. Relational and equality operators are defined by the language standard to return `int` values: 1 for a true condition, 0 for a false one. C99 added `_Bool` and the `<stdbool.h>` header with `true` and `false` macros, but those macros expand to 1 and 0 respectively. In a conditional context, any nonzero integer is treated as true.
Q: When should I use ==, !=, <, >, <=, or >= in if statements and loops?
Use `==` when you need exact equality, `!=` when you need to detect a difference, and `<`, `>`, `<=`, `>=` when you need to establish ordering or range. In loops, the most common pattern is `<` for index-based iteration (`i < n`) and `!=` for sentinel-based iteration. The choice should match the semantic question you are actually asking — not just the one that happens to work for your test inputs.
Q: Why can comparing floating-point numbers with == be risky?
Floating-point numbers are stored in binary with finite precision, and most decimal fractions cannot be represented exactly. Arithmetic on floats accumulates rounding error, so two values that are mathematically equal often differ by a tiny amount in their binary form. The safe alternative is a tolerance-based comparison: check whether the absolute difference between the two values is smaller than an acceptable epsilon, typically using `fabsf` or `fabs` from `<math.h>`.
Q: How do you compare strings in C correctly if == does not work?
Use `strcmp` from `<string.h>`. It compares the character content of two strings and returns 0 if they are equal, a negative value if the first is lexicographically less, and a positive value if greater. The reason `==` fails is that string variables in C are pointers — `==` compares memory addresses, not text content. Two strings with identical text stored in different memory locations will not be equal under `==`.
Q: What are the most common interview mistakes involving equality in C?
The seven most tested: using `=` instead of `==` in a condition, not knowing that comparison results are 1 or 0, misapplying one of the six comparison operators in a loop, relying on precedence instead of parentheses when mixing `=` and `==`, using `==` for string comparison instead of `strcmp`, using `==` for pointer equality when value equality was the goal, and using `==` for float comparison instead of a tolerance check. Each one sounds simple in isolation and becomes a real bug under pressure.
Q: How does pointer comparison differ from value comparison in C?
`p1 == p2` tests whether two pointers hold the same memory address — whether they point to the same object. `p1 == p2` dereferences both pointers first and then compares the values stored at those addresses. These are two completely different questions. Interviewers test this because candidates often say "I'm checking if they're equal" without specifying equal in which sense, which signals that they have not fully separated address identity from value equality in their mental model.
Conclusion
The seven traps in this guide are not obscure edge cases. They are the exact places where C's design diverges from what a beginner's intuition would predict — and interviewers know that because they have watched candidates stumble on the same ones repeatedly. Memorizing the symbols is not the goal. The goal is being able to explain, out loud, why `==` fails on strings, why floats need a tolerance check, and why a compiler warning about assignment in a condition is not a suggestion.
The fastest way to stop sounding uncertain on these questions is to rehearse saying the answers, not just reading them. Pick any three of the seven traps, close the article, and explain each one to the wall. If you stumble on the explanation, you have found exactly what still needs work — before the interviewer finds it first.
Quinn Okafor
Interview Guidance
