In some languages one instance can read another instance's private state as long as both are the same class; in others privacy is per-object and even a sibling instance cannot reach it. Name concrete languages on each side, say exactly what rule each one enforces, and explain what the choice changes about how you design a type's operations.

## The word "private" answers two different questions "Private" is supposed to answer *who may touch this?* — but there are two defensible answers, and languages have picked both. One answer is **this class's code**: any method written inside `Account` may read the representation of any `Account`, including one it was handed as an argument. The other answer is **this object**: a method may only reach the state of the object it is running on, and a sibling instance is as opaque as a stranger. Most people learn exactly one of these, from their first language, and mistake it for the definition of the word. ## Camp one: privacy belongs to the class Java, C#, C++ and TypeScript's compile-time `private` all scope access to the *class body* (in Java, to the whole top-level class including its nested classes). Inside a method of `Account`, the expression `other.balance` is legal for any `other` of static type `Account`. The consequence is structural, not cosmetic. A type can implement operations that involve two of its own instances — `equals`, `compareTo`, `merge`, `difference`, a copy constructor — entirely inside its own code, reading the other operand's representation directly. Nothing has to be published for the type to do its own work, so the public surface can stay as narrow as the *domain* requires rather than as wide as the *implementation* requires. ## JavaScript's twist: class-level privacy with a runtime brand JavaScript joined this camp with `#` private fields, and added a property none of the older languages have: the access is **branded** at run time. Inside the class body `other.#bal` works on any object that was constructed with that private name — so it is class-level — but on an object that was not, it throws a `TypeError` instead of quietly yielding `undefined`. That is why `#bal in other` exists: it is the standard, non-throwing way to ask "is this really one of mine?", and it doubles as a genuine identity check that no forger can imitate, because private names are not properties and cannot be created from outside the class body. ## Camp two: privacy belongs to the object Smalltalk takes the other side. Instance variables belong to the object; only the receiver's own methods can name them, and there is no syntax at all for reaching into a sibling. Every binary operation must send a message to the other object and work with whatever comes back. The result is a culture of small accessors and message passing, and a very clean substitutability story: a comparison written this way depends only on the other operand's protocol, never on its representation, so any object that answers the same messages can be passed in. The cost is that a type cannot keep a pairwise operation's data private — whatever the operation needs must be published in some form. ## Ruby: a rule about receivers, not about objects Ruby is the instructive case, because it looks like camp two and is not. Ruby's `private` constrains the **call form**, not the object graph: a private method may not be called with an explicit receiver *other than a literal `self`*. Since Ruby 2.7 (2019) `self.bal` is permitted for any private method — before 2.7 the only allowed explicit receiver was the setter form `self.foo = x` — while a receiver naming a *different* object is still rejected. So `other.bal` raises `NoMethodError` even though `other` is the same class. That reads like per-object privacy but is really a syntax rule about receivers. To get sibling access Ruby gives you `protected`, whose entire reason to exist is to allow `other.bal` from within the same class or a subclass. Note the trap: in Java and C#, `protected` means something else entirely — subclasses, plus the package in Java — so the same keyword carries incompatible meanings across the two ecosystems. ## Python: no answer at all Python has no access control. A single leading underscore is etiquette. A double leading underscore triggers **name mangling**: `self.__bal` inside `class Account` compiles to the attribute `_Account__bal`. Two things follow. First, the boundary is class-level by construction, because the same mangling applies to `other.__bal` written inside `Account`. Second, the feature's purpose is to stop a subclass accidentally colliding with a base class's attribute name — not to stop access, since anyone outside can write `acct._Account__bal`. ## What the choice changes in design - **Where pairwise operations live.** With class-level privacy, comparison, merging and diffing can be implemented against the raw representation inside the type. With object-level privacy those operations force a published protocol, so the representation choice leaks into the interface and becomes harder to change later. - **How wide the public surface gets.** Class-level privacy lets a type stay narrow; the Smalltalk answer trades a wider surface for stricter per-object isolation. - **The axis is not the inheritance axis.** Privacy answers *whose code*; `protected` answers *which relatives* (and in Ruby, *which receiver form*); module/package/assembly modifiers answer *which compilation unit*. Conflating them is the usual error. - **Compile time versus run time.** Java, C#, C++ and TypeScript check at compile time and nothing survives into the running program. JavaScript's `#` fields are checked at run time, which is why a foreign object raises an exception rather than returning `undefined`. ## Answering it in an interview Name both camps with concrete languages, state each rule precisely, then show the axis is independent of inheritance. Ruby's `protected` and Java's `protected` being different mechanisms with one spelling is the detail that proves you have actually worked in more than one of them.