Master the null in Python interview with a 30-second answer on None, is None vs == None, and the follow-up questions that trap candidates.
Most candidates who fumble a null in Python interview question don't blank on the concept — they give a decent first answer and then get caught flat-footed on the follow-up. Knowing that Python uses `None` instead of `null` is the easy part. Knowing why you check it with `is None` instead of `== None`, and being able to explain that under live pressure, is what actually separates candidates in a technical screen.
This guide gives you the 30-second answer first, then walks through every follow-up an interviewer is likely to throw at it.
Say the 30-second answer before you explain anything
The answer you can say out loud
When an interviewer asks about null in Python, say this:
"Python doesn't have a `null` keyword. The equivalent is `None` — it's a singleton object of type `NoneType` that represents the absence of a value. Because there's only one `None` object in a Python process, you check for it with `is None` rather than `== None`. That way you're testing identity — whether the object actually is `None` — not equality, which can be overridden by a custom class."
That's it. Roughly 60 words, under 30 seconds at a normal speaking pace, and it survives every standard follow-up because it already names the singleton behavior and the identity-versus-equality distinction.
What the interviewer is really checking
The question isn't a vocabulary test. Interviewers ask about `None` because it sits at the intersection of three things they actually care about: whether you understand Python's object model, whether you write defensive code, and whether you've seen `NoneType` tracebacks in production and know what caused them. A candidate who can say "`None` is a singleton" and then explain what that means is signaling real Python fluency, not just having read the docs once.
What this looks like in practice
The follow-up comes almost immediately. A candidate gives the answer above, and the interviewer says: "Okay, so why not just use `== None`? What's the actual difference?"
The right response: "Equality can be overridden. If a class defines `__eq__`, `== None` might return `True` even when the object isn't actually `None`. `is None` checks whether the object's identity is `None` — it can't be spoofed." A candidate who hasn't thought past the syntax will say "they're basically the same" and lose the thread entirely. The 30-second answer above is specifically built to not put you in that position.
Use None as Python's null equivalent, not a keyword from another language
Why Python has None instead of a null keyword
Languages like Java and JavaScript use `null` as a keyword that can be assigned to any reference type. Python made a different choice: a single object, `None`, lives in the `builtins` module and is available everywhere without an import. This isn't a gap in the language — it's a deliberate consistency decision. Everything in Python is an object, including the representation of absence. `None` fits that model; a bare keyword wouldn't.
None is a singleton, and that matters
There is exactly one `None` object in a running Python process. Every time you write `None`, you're referencing the same object. That's what makes identity checks meaningful: `is None` is asking "is this the one and only `None` object?" and the answer is always unambiguous. According to Python's data model documentation, `None` is the sole instance of `NoneType`, and the interpreter guarantees this. Python NoneType is not a class you can instantiate — `type(None)()` raises a `TypeError`. The singleton is enforced at the language level.
What this looks like in practice
Three common places `None` appears in real Python code:
An unassigned optional: `result = None` before a conditional block that may or may not populate it. A function that queries a database returns `None` if no row is found. An API response parser sets a field to `None` when the key is absent from the payload. In every case, `None` means the same thing — "this value was not provided or does not exist" — and the code that consumes it should check `is None` before doing anything with it.
Stop using == None when you mean is None
Why == None looks harmless and still fails the interview
The instinct to use `==` is reasonable. It works for comparing integers, strings, and most built-in types. For `None` specifically, it usually works too — until it doesn't. The steelman case for `==` is that in a codebase full of standard types, `== None` will almost always behave identically to `is None`. That's exactly why it's a trap: it looks safe until a custom class enters the picture.
The is None vs == None distinction is the single most common Python interview follow-up, and interviewers ask it because it cleanly separates candidates who understand identity from candidates who are pattern-matching on syntax they've seen in other people's code.
The edge case interviewers are waiting for
Custom classes can define `__eq__`. A class that overrides equality comparison can make `obj == None` return `True` even when `obj` is a perfectly valid, non-None instance. This isn't hypothetical — ORM objects, mock objects in test frameworks, and numeric types in libraries like NumPy all define custom equality behavior. `is None` bypasses all of that. It checks whether the object occupies the same memory address as the singleton `None`, and no amount of `__eq__` overriding changes that. PEP 8 is explicit on this: "Comparisons to singletons like `None` should always be done with `is` or `is not`, never the equality operators."
What this looks like in practice
A debugging session that surfaces this pattern can burn hours. The value passes an `if val == None` guard and then behaves unexpectedly downstream because it isn't actually `None`. The fix is one word: replace `==` with `is`. The interview answer is the same.
Know when Python returns None without saying so
The silent return that catches people off guard
Every Python function returns a value. If you don't provide a `return` statement — or you write `return` with no argument — the function hands back `None`. This is not an error. It's documented behavior. But it's also one of the most common sources of `NoneType` bugs in production, because the caller often assumes a function that does work must return something useful.
Default arguments and optional parameters are where None earns its keep
The standard Python pattern for optional parameters uses `None` as the default:
This is different from using a mutable default like a list or dict, which is a well-known Python footgun because mutable defaults are shared across calls. `None` as a default is safe precisely because it's immutable and singular. The function checks `is None` to detect "caller didn't provide this" and substitutes the real default inside the body. This pattern appears throughout the Python standard library and is worth naming explicitly in an interview answer.
What this looks like in practice
The function looks complete. It handles the case it was written for. The missing `return` for every other case silently produces `None`, and the crash happens one line later where the caller trusted the result. This is exactly the kind of production story that lands well in an interview — it shows you've seen the failure mode, not just the concept.
Read NoneType tracebacks instead of guessing
The bug pattern everyone has seen at least once
`AttributeError: 'NoneType' object has no attribute 'X'` is one of the most common Python errors in production systems. So is `TypeError: 'NoneType' object is not subscriptable`. Both mean the same thing: you tried to use `None` as if it were something else. The traceback is not lying to you — it's telling you exactly where the assumption broke down. The value was `None` at that line, and the line above (or ten lines above) is where it became `None` unexpectedly.
Why these bugs happen in real code
Three root causes account for most Python NoneType crashes: a function that was supposed to return a value didn't, a dictionary lookup used `.get()` and the key was absent, or a method chain kept executing after one step returned `None`. The third pattern is particularly insidious in data pipelines where transformations are chained: `data.clean().normalize().export()` fails silently at `normalize()` and explodes at `export()` with a `NoneType` error that points to the wrong place.
What this looks like in practice
A paraphrased stack trace from a real debugging session:
`record` was `None`. Why? The function two levels up called `.get("value")` on a dictionary where the key didn't exist, got `None` back, and passed it forward without checking. The fix was a guard at the point of retrieval:
Catching it at the source instead of three function calls later is the difference between a five-minute fix and an hour of tracing.
Separate None from False, 0, empty strings, and empty containers
Why people mix these up
All of these values are falsy in Python. `if not value` treats `None`, `False`, `0`, `""`, `[]`, and `{}` identically — they all take the false branch. That convenience is also the source of real bugs, because these values don't mean the same thing. Collapsing them with a truthiness check is fine for quick scripts and genuinely fine for some validation logic. It becomes a problem the moment any of these values is a legitimate input.
The business rule problem nobody says out loud
`None` means "not provided" or "missing." `0` means "provided, and the value is zero." `False` means "provided, and the answer is no." `[]` means "provided, and the list is empty." These are different states. A form field where a user enters `0` for a quantity is not the same as a form field the user left blank. An API that returns `False` for a permission check is not the same as an API that returned nothing. Python NoneType is specifically the "absence" type — the others are presence with a particular value.
What this looks like in practice
A real bug from API validation: a discount field that accepted `0` as a valid discount was being rejected because the validation check used `if not discount` instead of `if discount is None`. Zero-percent discount is a legitimate business value. The fix was one line, but finding it required understanding that None and 0 are not interchangeable — exactly the kind of reasoning an interviewer wants to see. Python's truth value testing documentation covers this in detail.
Answer the follow-up questions without getting trapped
Why None is not the same as NaN or SQL NULL
These three concepts come up together in data engineering interviews and in any role that touches databases or numerical computing. The clean distinction: `None` is Python's absence object — a real Python object of type `NoneType`. `NaN` (Not a Number) is a floating-point value defined by the IEEE 754 standard; it's a number that resulted from an undefined operation like `0/0` or `float('inf') - float('inf')`. It is not absence — it's a specific numeric signal. SQL `NULL` is a database-side concept meaning "unknown or missing data" — it has its own comparison semantics (SQL `NULL != NULL`) that are entirely separate from Python's object model.
When Python reads a SQL `NULL` from a database cursor, most drivers convert it to `None`. When pandas reads a missing numeric value, it often becomes `NaN`. These conversions are not symmetric, and treating them as equivalent in a null in Python interview answer will get you caught.
What to say when None is a valid business value
Sometimes `None` isn't just "missing" — it's a meaningful input. An API parameter where `None` means "use the server default" is different from a parameter that was never passed. When `None` itself carries business meaning, you need a sentinel: a unique object that can't be confused with any real value or with `None`.
This pattern appears in Python's standard library (`inspect.Parameter.empty` is exactly this) and in well-designed APIs where the distinction between "not provided" and "explicitly set to None" matters.
What this looks like in practice
A mock interview transcript for the follow-up sequence:
Interviewer: "How is `None` different from `NaN`?" Candidate: "`None` is a Python object representing absence. `NaN` is a float representing an undefined numeric result — it's not absence, it's a specific IEEE 754 signal. You'd see `NaN` in NumPy arrays or pandas DataFrames after a division by zero or a missing numeric merge. You'd see `None` in a Python dict where a key wasn't found."
Interviewer: "What about SQL NULL?" Candidate: "SQL `NULL` means unknown or missing at the database level. Most Python database drivers map it to `None` when you fetch results, but the semantics are different — SQL `NULL` doesn't equal itself, which is why SQL uses `IS NULL` rather than `= NULL`. Once it's in Python, you treat it like any other `None`."
Interviewer: "What if `None` is a valid input to your function?" Candidate: "Then I use a sentinel — a unique object created with `object()` — as the default instead of `None`. That way I can distinguish 'caller didn't pass anything' from 'caller explicitly passed `None`'."
That sequence, delivered confidently, closes the interview question completely.
How Verve AI Can Help You Ace Your Coding Interview With Null in Python
The structural problem with technical interview prep isn't knowing the concept — it's that knowing it and being able to explain it under pressure are two different skills. You can read about `None` being a singleton and still stumble when the interviewer asks a live follow-up about `NaN` or sentinel values, because you've never had to reconstruct the answer in real time.
Verve AI Coding Copilot is built for exactly that gap. It reads your screen in real time — whether you're working through a LeetCode problem, a HackerRank challenge, or a live CodeSignal round — and suggests answers live based on what's actually in front of you, not a generic prompt. For a question like this one, where the concept is simple but the follow-ups branch in several directions, having Verve AI Coding Copilot track your performance and surface the right distinction at the right moment changes the dynamic entirely. The Secondary Copilot feature lets you stay locked on one problem without losing context — useful when a single interview question about `None` turns into a five-minute thread about NoneType tracebacks, sentinel patterns, and SQL NULL semantics.
Conclusion
You now have the 30-second answer — say what `None` is, name the singleton, say `is None` — and you can defend every part of it. The identity-versus-equality distinction, the implicit return behavior, the difference between `None` and `NaN` and SQL `NULL`, and the sentinel pattern for when `None` itself is a valid input: none of these are hard once you've thought them through once. The point of this guide was to do that thinking before the interview, not during it.
Before your next technical screen, say the 30-second answer out loud once. Then run through the `is None` follow-up and the `NoneType` traceback scenario. Two minutes of rehearsal turns a concept you understand into an answer you can deliver without fumbling — which is the only version that counts.
Reese Nakamura
Interview Guidance
