Use the Python private variables interview 20-second answer: single underscore convention, double underscore name mangling, and when to mention @property.
Most candidates who stumble on Python private variables interview questions already know the answer. They've read it. They can type it. What they can't do is say it cleanly under pressure without veering into a five-minute detour about object-oriented design principles that nobody asked for.
The short version is this: Python has no true private variables. Single and double underscores are signals — one a convention, one a mechanism — and name mangling is about collision avoidance, not secrecy. That's the answer. The rest of this guide is about how to say it well, defend it under follow-up, and avoid the three mistakes that make otherwise solid candidates sound uncertain.
Start with the Answer Interviewers Actually Want
The 20-second answer
Here is the exact answer, shaped for a python private variables interview, that you can practice aloud until it sounds natural:
"Python doesn't have true private variables. A single leading underscore is a naming convention that signals 'internal use' — it's a social contract, not enforcement. A double leading underscore triggers name mangling, where Python renames the attribute from `__var` to `_ClassName__var`. That's not privacy — it's collision avoidance in inheritance hierarchies. If you genuinely need controlled access, `@property` is usually the cleaner tool."
That's it. Twenty seconds. Accurate, complete, and honest about Python's design. The answer earns points not because it's clever but because it demonstrates that the candidate understands the distinction between convention and enforcement — which is exactly what the question is probing.
Why people ramble here
The failure mode isn't ignorance. It's conflation. Candidates mix up three distinct ideas — privacy, encapsulation, and naming conventions — and then try to explain all three simultaneously because they're not sure which one the interviewer actually wants.
So they start with "well, in Python, privacy is more of a convention," then pivot to "but encapsulation is still possible," then loop back to "double underscores do something special," and by the time they get to name mangling, they've lost the thread and the interviewer has mentally moved on. The Python data model documentation treats these as separate, well-defined mechanisms — and the cleanest interview answers mirror that separation.
The fix is to commit to the short answer first, then wait. If the interviewer wants depth, they'll ask. Most of the time, they will.
Treat Single Underscore and Double Underscore as Two Different Signals
Single underscore means 'don't poke this' — not 'you can't'
The single underscore Python convention is a gentleman's agreement. When you see `_cache` or `_internal_state` in a class, the author is telling you: this is an implementation detail, not part of the public API, and you shouldn't depend on it staying stable. Python won't stop you from accessing it. No error is raised. No warning is issued. The only enforcement is social.
This matters in real codebases because public API boundaries are mostly maintained through discipline, not locks. A library author marks `_parse_response` with a single underscore to communicate that this method may change between versions. Callers who ignore that signal and call it directly are accepting the risk. The convention is surprisingly effective at scale — teams that respect it consistently produce more maintainable code than teams that treat every attribute as fair game.
Double underscore is about collision avoidance, not secrecy
Double underscore does something mechanically different. When Python sees an identifier like `__token` inside a class definition, it rewrites it. The attribute doesn't get stored as `__token` — it gets stored as `_ClassName__token`. This transformation is name mangling in Python, and its primary purpose is to reduce the chance that a subclass accidentally overrides an attribute it didn't know existed.
It is not a lock. It is not encryption. It is a rename. Anyone who knows the mangled name can access the attribute directly. Saying "double underscore makes an attribute private" in an interview is technically inaccurate and signals that you've memorized the term without understanding the mechanism.
What this looks like in practice
The `_cache` attribute is marked internal by convention. A teammate reading this code understands not to build logic that depends on its structure. The `__token` attribute gets mangled so that if a subclass of `APIClient` also defines a `__token`, they won't silently collide. Neither of these is secret. Both serve a real engineering purpose.
Show Name Mangling in Python, Not Just the Definition
What Python actually renames
Name mangling in Python applies to any identifier with two or more leading underscores and at most one trailing underscore, defined inside a class body. Python rewrites `__var` to `_ClassName__var` at compile time — before the code even runs. The transformation is deterministic and documented in the Python language reference.
Most candidates can repeat "double underscore triggers name mangling" correctly. Fewer can describe the transformation cleanly. The cleanest way to say it in an interview: "Python prefixes the attribute with an underscore and the class name, so `__token` in class `APIClient` becomes `_APIClient__token`." That sentence is specific enough to demonstrate real understanding without requiring a whiteboard.
What this looks like in practice
The `__dict__` output is the clearest demonstration you can give. The attribute is right there — renamed, not hidden. Showing this in an interview, or describing it accurately when no whiteboard is available, signals that you've actually run this code, not just read about it.
Answer the Follow-Up Before the Interviewer Asks It
Can you still access it from outside the class?
Yes, and you should say so directly. A strong Python encapsulation interview answer doesn't dodge this. You access the mangled attribute by using the transformed name: `obj._ClassName__attr`. It works. No exception. Python makes it slightly inconvenient, not impossible.
That's the point. The mechanism is designed to prevent accidental access — a subclass that happens to define the same name, a caller who doesn't realize they're touching an internal detail. It is not designed to prevent intentional access by someone who knows what they're doing. Claiming otherwise in an interview is the kind of overclaim that makes interviewers skeptical of everything else you say.
Why use __ at all if it's not private?
The steelman argument is straightforward: name mangling solves a real inheritance problem. Without it, a subclass that defines `__token` would silently shadow the parent class's `__token`, producing bugs that are genuinely hard to trace. The mangling ensures each class's double-underscore attributes live in a namespace that includes the class name, so collisions become visible rather than silent.
The secondary reason is intent signaling. When a library author uses double underscore, they're communicating: this is not just internal, it's specifically off-limits for subclassing purposes. That's a stronger signal than single underscore, reserved for attributes where accidental override in a subclass would be a real problem.
What this looks like in practice
Without mangling, `Child.__id` would overwrite `Base.__id` silently. With mangling, they coexist. This is the practical reason the mechanism exists — not secrecy, but safe inheritance in frameworks and libraries where you can't predict every subclass someone might write.
Use @property When You Want Control, Not Pretend Secrecy
When properties beat private-looking attributes
In a Python private variables interview, the @property question often comes up as a follow-up: "If you want to control access to an attribute, how do you actually do it?" The honest answer is `@property`, not double underscore.
A property gives you a stable public interface while letting the implementation change underneath. You can validate input on write, compute a value on read, or log access without the caller knowing or caring. Double underscore doesn't give you any of that — it just renames the attribute and makes it slightly harder to reach.
What this looks like in practice
The caller sees `account.balance` throughout. If you later decide to store the balance differently — say, in cents as an integer — you change the internal implementation without touching the public interface. That's the engineering value. The Python documentation on properties describes this pattern as the idiomatic way to manage attribute access in Python, precisely because it separates interface from implementation without pretending the language has access modifiers it doesn't have.
A practical refactoring note: if you start with a raw attribute `self.balance = balance` and later need validation, adding `@property` is backward-compatible — existing callers don't change. Switching from `self.__balance` with getter methods is messier because you've already leaked the naming convention into the codebase.
Separate Strong Answers from Weak Ones in One Minute
What a strong answer signals
What strong Python knowledge sounds like in this context is accuracy, restraint, and comfort with tradeoffs. A strong candidate says "Python doesn't have true private variables" without hedging it into "well, sort of, kind of, it depends." They distinguish convention from enforcement. They explain name mangling as a rename, not a lock. And when the follow-up comes, they don't get defensive — they answer it directly and move on.
Restraint is underrated here. The candidate who gives a 20-second answer and waits for the follow-up signals more confidence than the one who preemptively covers every edge case to prove they've studied. Interviewers ask follow-ups specifically to see how candidates handle depth — and a candidate who's already exhausted every angle has nowhere to go.
What weak answers give away
Weak answers usually do one of three things. They claim double underscore makes data "secure" or "truly private" — which is wrong. They conflate privacy with encapsulation, treating them as synonyms when they describe different concepts. Or they answer the direct question, then panic when the follow-up arrives and start backtracking on what they just said.
The conflation between privacy and encapsulation is the most common tell. Encapsulation is about bundling state and behavior together. Privacy is about restricting access. Python has strong encapsulation support. It has no enforced privacy. Candidates who treat these as the same thing are answering a language-design question as if it were a security question — and the mismatch is immediately apparent to anyone who has written production Python.
What this looks like in practice
Weak answer: "Python has private variables using double underscore, which makes the attribute private so you can't access it from outside the class. It's Python's way of doing encapsulation."
Strong answer: "Python doesn't enforce privacy — single underscore is a convention for internal use, double underscore triggers name mangling which renames the attribute to avoid subclass collisions. You can still access the mangled name if you know it. If I actually need controlled access, I'd use a property."
The difference isn't vocabulary. It's the candidate's willingness to say what Python does and doesn't do, plainly, without overselling the mechanism.
Stop Making the Three Mistakes That Sink This Answer
Mistaking name mangling for security
The double underscore in Python is not a security feature. It does not prevent access. It does not encrypt data. It renames the attribute in a predictable, documented way that anyone can reverse by looking at the class name. Calling it "private" in an interview is an overclaim that signals you've read about the feature without testing it. The one-sentence correction: mangling makes accidental access less likely and intentional access slightly more verbose. That's the full scope of what it does.
Overusing double underscore in everyday code
Name mangling has a specific use case: protecting attributes in base classes from accidental collision in subclasses. Outside of that context — in a simple class with no inheritance concerns — double underscore makes code harder to inspect, harder to debug, and harder to refactor. A code review note worth internalizing: if you're using `__attr` in a class that will never be subclassed, you're adding friction without adding value. Single underscore is almost always the right choice for marking internal attributes.
Forgetting the difference between privacy and encapsulation
This is the root of most confused answers, and it's worth absolving the reader of blame: the confusion is structural, not a sign of weak Python knowledge. Python's design deliberately prioritizes convention over enforcement, which means the language looks like it has privacy mechanisms when it actually has communication mechanisms. The mistake is treating a naming convention as a language feature — answering a question about Python's design philosophy as if it were a question about access control.
If you've been thinking about double underscore as "Python's version of private," you were answering the wrong question. The right question is: what does Python use instead of enforced privacy, and why? The answer — conventions, name mangling for inheritance safety, and properties for controlled access — is a much more interesting one.
FAQ
Q: Does Python have private variables in classes, or only private-looking conventions?
Python has conventions, not enforced privacy. Single underscore signals internal use by agreement; double underscore triggers name mangling, which renames the attribute but does not block access. There is no access modifier in Python that prevents a caller from reaching an attribute if they know its name.
Q: How should I explain single underscore, double underscore, and name mangling in an interview?
Treat them as three separate things. Single underscore: convention for internal use, no enforcement. Double underscore: triggers name mangling, which renames `__attr` to `_ClassName__attr` to avoid subclass collisions — not to create privacy. Name mangling: a compile-time rename, fully reversible, documented behavior. Saying all three clearly and distinctly is the answer interviewers are listening for.
Q: If Python doesn't enforce privacy, why use __ or _ at all?
Because communication matters in codebases. Single underscore tells teammates and API consumers "don't depend on this." Double underscore tells Python itself "protect this attribute from accidental override in subclasses." Both serve real engineering purposes — they just don't serve the security purpose that people sometimes assume they do.
Q: Can private variables still be accessed from outside the class, and should you ever do that?
Yes, they can. A mangled attribute `__token` in class `APIClient` is accessible as `client._APIClient__token` from anywhere. Whether you should: rarely, and deliberately. Accessing a mangled name from outside the class is a signal that either the class's API is incomplete, or you're doing something that the original author didn't intend to support. In testing or debugging contexts, it's occasionally justified — but it should always feel like a deliberate choice, not a workaround.
Q: When is @property a better choice than a double-underscore attribute?
Whenever you need to validate input, compute a derived value, or maintain a stable public interface while the underlying storage changes. `@property` gives you a real API boundary — callers use `obj.balance` and never know or care what happens underneath. Double underscore gives you a renamed attribute and nothing else. If the goal is controlled access rather than collision avoidance, `@property` is almost always the cleaner answer.
Q: What answer would signal strong Python knowledge to a hiring manager?
An answer that draws the line between convention and enforcement clearly, explains name mangling as a rename rather than a lock, and mentions `@property` as the idiomatic tool for controlled access. Equally important: the candidate doesn't over-explain, doesn't backpedal when the follow-up arrives, and doesn't claim Python has features it doesn't have. Accuracy and restraint together are the signal.
How Verve AI Can Help You Ace Your Coding Interview With Python Private Variables
The structural problem this question exposes isn't Python knowledge — it's the gap between knowing something and explaining it under live pressure. That gap doesn't close by reading more documentation. It closes by practicing the answer out loud, hearing a follow-up you didn't expect, and adjusting in real time. That's a performance skill, and it requires a tool that can respond to what you actually say, not a canned prompt.
Verve AI Coding Copilot is built for exactly this. It's screen-aware, which means it can see the code you're working through and the question on the screen — whether that's a LeetCode problem, a HackerRank challenge, a CodeSignal round, or a live technical interview. Verve AI Coding Copilot doesn't just surface definitions; it tracks what you've said and what the interviewer is likely to probe next, so you're not rehearsing in isolation. The Secondary Copilot feature keeps you focused on a single problem without context-switching, which matters when a Python encapsulation question turns into a 20-minute deep dive on inheritance and you need to hold the thread. When you're practicing the name mangling explanation and you want to know whether your answer actually landed, Verve AI Coding Copilot gives you feedback in real time — not after the session ends. That's the difference between interview prep and interview readiness.
The Answer Is Already in Your Head
You don't need a new mental model for Python private variables. You need to be able to say the right thing once, calmly, in about 20 seconds — and then hold your ground when the follow-up comes.
Practice the short version out loud: Python has no true private variables, single underscore is convention, double underscore triggers name mangling which is a rename not a lock, and `@property` is the right tool when you actually need controlled access. Say it until it sounds like something you believe, not something you memorized.
Then practice the follow-up: yes, you can access the mangled name from outside the class, and here's why that proves it's about collision avoidance, not secrecy. That second answer is what separates candidates who know the language from candidates who know the glossary. The interviewer will notice the difference immediately.
Alex Chen
Interview Guidance
