Python OOP MRO Failure — Fix super().__init__ in Mixins

Python interviews at companies like Google, Stripe, and mid-sized startups almost always include OOP questions — not because the interviewers want you to recite definitions, but because how you talk about OOP reveals whether you actually design software or just write scripts. A candidate who can explain why encapsulation exists (not just what it is) stands out immediately from the crowd who memorised a textbook definition the night before.

OOP solves the problem of code that grows into an unmanageable tangle. Without it, adding a new feature means hunting through hundreds of lines of procedural code, hoping you don't break something else. With OOP, you model your problem as a collection of objects that each own their own data and behaviour — so changes stay contained, reuse becomes natural, and testing gets easier.

By the end of this article you'll be able to explain the four pillars of OOP with real examples, write and debug class hierarchies in Python, spot the classic mistakes candidates make under pressure, and answer the follow-up questions that actually trip people up in interviews.

Why Python's MRO Fails in Mixins — And How super() Actually Works

Python's Method Resolution Order (MRO) determines which method gets called when you invoke super() in a class hierarchy. It's not just a linear parent search — it uses the C3 linearization algorithm to produce a consistent, monotonic order that respects all inheritance chains. For single inheritance, MRO is trivial; for multiple inheritance, it's the only thing preventing ambiguous or skipped method calls.

In practice, MRO is computed at class definition time and stored as __mro__. When you call super().__init__(), Python walks the MRO from the current class to the next class in the chain — not the parent class. This means super() in a mixin doesn't call the mixin's parent; it calls the next class in the MRO, which could be another mixin or the final base class. The order is determined by the child class's inheritance declaration, not the mixin's own bases.

You rely on MRO correctness every time you compose behaviors via mixins — logging, authentication, serialization. If you break the linearization (e.g., by introducing a diamond pattern with inconsistent base class ordering), Python raises TypeError: Cannot create a consistent method resolution order (MRO). This is not a warning — it's a hard failure at class definition time, preventing runtime ambiguity.

The Four Pillars — What They Are and Why They Exist

Every OOP interview starts here. Interviewers don't just want the names — they want to see you connect each pillar to a real problem it solves.

Encapsulation bundles data and the methods that act on it into one unit, and hides the messy internals. Think of a TV remote: you press a button, the TV changes channel. You don't need to know about the infrared signal. The remote encapsulates that complexity.

Inheritance lets a new class reuse behaviour from an existing one. Instead of copy-pasting a send_email method into five classes, you put it in a base Notification class and let the others inherit it. Changes in one place propagate everywhere.

Polymorphism means different objects can respond to the same method call in their own way. You call .render() on a Button and on a Chart — Python figures out which version to run. Your calling code doesn't need an if-else chain.

Abstraction hides what the implementation does and exposes only what it accomplishes. An abstract PaymentProcessor class forces every subclass (Stripe, PayPal) to implement .charge(), but callers never care which one they're using.

from abc import ABC, abstractmethod

# ABSTRACTION: Defining the interface. 
# We don't care HOW a gateway works, only that it can authorize and capture.
class PaymentGateway(ABC):
    @abstractmethod
    def authorize(self, amount: float) -> bool:
        pass

    @abstractmethod
    def capture(self, transaction_id: str) -> bool:
        pass

# INHERITANCE: Specific implementation of the abstraction.
class StripeGateway(PaymentGateway):
    def __init__(self, api_secret: str):
        # ENCAPSULATION: Internal credential hidden from the public API
        self.__api_secret = api_secret

    def authorize(self, amount: float) -> bool:
        print(f"[Stripe] Authorizing ${amount}...")
        return True

    def capture(self, transaction_id: str) -> bool:
        print(f"[Stripe] Capturing {transaction_id}")
        return True

# POLYMORPHISM: The caller treats all gateways the same.
def process_order(gateway: PaymentGateway, amount: float):
    if gateway.authorize(amount):
        gateway.capture("tx_123")

gateway = StripeGateway(api_secret="sk_test_4eC39HqLyj")
process_order(gateway, 99.99)

Inheritance vs Composition — The Question That Trips Everyone Up

Interviewers love asking 'when would you use inheritance over composition?' because most candidates either go blank or recite 'favour composition over inheritance' without knowing why.

Inheritance models an is-a relationship. A Dog is an Animal. That relationship is rigid — once you inherit from a class, you're locked into its interface and any side-effects of its implementation changes.

Composition models a has-a relationship. A Car has an Engine. You can swap the engine (electric vs petrol) without rewriting the car. This is why composition is usually more flexible.

The practical rule: use inheritance when the child genuinely is a specialised version of the parent and you want to enforce a shared contract. Use composition when you want to combine behaviours, because it keeps each piece small, testable, and swappable.

The classic trap is building deep inheritance chains (six levels deep) only to find that a change in the grandparent breaks three grandchildren in unpredictable ways. Composition avoids that cascade entirely.

import uuid

# COMPOSITION: Behaviours as separate components
class Logger:
    def log(self, message: str):
        print(f"[LOG] {message}")

class Repository:
    def save(self, data: dict):
        print(f"[DB] Saving {data['id']}")

# The Application Service HAS-A logger and HAS-A repository
class UserService:
    def __init__(self, logger: Logger, repo: Repository):
        self.logger = logger
        self.repo = repo

    def create_user(self, username: str):
        user_id = str(uuid.uuid4())
        self.logger.log(f"Creating user {username}")
        self.repo.save({"id": user_id, "username": username})

# Usage
logger = Logger()
repo = Repository()
service = UserService(logger, repo)
service.create_user("dev_forge")

Dunder Methods, Properties, and Class vs Static Methods

These three topics show up constantly in Python OOP interviews because they reveal whether you understand Python's OOP model specifically — not just OOP in general.

Dunder (magic) methods let your objects integrate with Python's built-in syntax. Define __str__ so print(my_object) shows something meaningful. Define __eq__ so order_a == order_b compares the right fields. Define __len__ so len(my_cart) works naturally. They're called 'dunder' because they have Double UNDERscores on each side.

Properties (via @property) let you expose a clean attribute interface while hiding validation logic behind it. You read employee.salary like an attribute, but under the hood Python calls a getter method. The caller never sees the implementation change if you add validation later.

Class methods vs static methods trip up almost everyone. A @classmethod receives the class itself as its first argument (cls) — it can create instances, so it's perfect for alternative constructors. A @staticmethod receives nothing special — it's just a utility function that logically belongs inside the class namespace but doesn't need access to the class or instance.

class DatabaseConnection:
    _instances = 0

    def __init__(self, connection_string: str):
        self._connection_string = connection_string
        self.__class__._instances += 1

    # Dunder for debugging
    def __repr__(self):
        return f"DatabaseConnection('{self._connection_string}')"

    # Property for controlled access
    @property
    def status(self) -> str:
        return "Connected" if self._connection_string else "Disconnected"

    # Class Method: Alternative Constructor
    @classmethod
    def from_env(cls):
        # In real world: fetch from os.getenv
        return cls("postgres://localhost:5432/forge")

    # Static Method: Pure utility
    @staticmethod
    def is_valid_uri(uri: str) -> bool:
        return uri.startswith("postgres://")

conn = DatabaseConnection.from_env()
print(f"Status: {conn.status}")
print(f"Representation: {repr(conn)}")
print(f"Is Valid? {DatabaseConnection.is_valid_uri('http://bad.uri')}")

MRO, super(), and Multiple Inheritance — Python's Hidden Complexity

Multiple inheritance is rare in practice but almost always shows up in Python OOP interviews because it exposes whether you understand Python's Method Resolution Order (MRO).

When a class inherits from two parents that both define the same method, Python needs a rule for which one wins. That rule is the C3 linearisation algorithm, and the result is visible via ClassName.__mro__. Python reads it left to right — the first class in the MRO that defines the method wins.

super() doesn't just mean 'call the parent class'. In a multiple-inheritance chain, super() calls the next class in the MRO — which might not be the direct parent. This is the cooperative inheritance pattern, and it's why every class in a diamond hierarchy should call super().__init__() if it wants all initialisers to run correctly.

In practice, you'll see multiple inheritance most often with mixins — small classes that add a single, specific behaviour (like LoggingMixin or SerializableMixin) without being a full standalone class. It's composition-flavoured inheritance, and it's elegant when kept small.

class Base:
    def __init__(self):
        print("Base init")

class MixinA(Base):
    def __init__(self):
        print("MixinA init")
        super().__init__()

class MixinB(Base):
    def __init__(self):
        print("MixinB init")
        super().__init__()

class Diamond(MixinA, MixinB):
    def __init__(self):
        print("Diamond init")
        super().__init__()

# Triggering the diamond
d = Diamond()
print(f"MRO: {[c.__name__ for c in Diamond.mro()]}")

Abstract Base Classes, Duck Typing, and Protocols

Python's OOP interviews often probe how you handle interfaces without a formal interface keyword. The answer involves Abstract Base Classes (ABCs), duck typing, and the newer Protocol class from typing.

Abstract Base Classes force subclasses to implement certain methods. Use abc.ABC and @abstractmethod to define contracts. If a subclass doesn't implement all abstract methods, it cannot be instantiated — great for enforcing a shared API across a family of classes.

Duck Typing is Python's runtime philosophy: 'If it walks like a duck and quacks like a duck, it's a duck.' No explicit interface needed — just implement the expected methods. This is powerful but fragile: an object lacking a method only fails at runtime when that method is called.

Protocols (from typing.Protocol) are structural subtyping. You define a protocol class with method signatures, and any object that implements those methods satisfies the protocol — at type-check time via mypy or other tools. This is Python's answer to static duck typing.

The interview trick: when asked 'How does Python handle interfaces?' you can say: 'Python uses duck typing at runtime, ABCs for explicit contracts, and Protocols for static structural typing. I pick ABCs when I need runtime enforcement, Protocols when I want static checking without forcing inheritance.'

from abc import ABC, abstractmethod
from typing import Protocol

# ABSTRACT BASE CLASS
class Serializable(ABC):
    @abstractmethod
    def to_json(self) -> str:
        pass

    @abstractmethod
    def from_json(self, data: str) -> None:
        pass

class User(Serializable):
    def __init__(self, name: str):
        self.name = name

    def to_json(self) -> str:
        return f'{{"name": "{self.name}"}}'

    def from_json(self, data: str) -> None:
        import json
        self.name = json.loads(data)["name"]

# PROTOCOL for static structural typing
class Drawable(Protocol):
    def draw(self) -> None:
        ...

class Circle:
    def draw(self) -> None:
        print("Draw circle")

class Square:
    def draw(self) -> None:
        print("Draw square")

def render(obj: Drawable) -> None:
    obj.draw()

# Both work without inheriting Drawable
render(Circle())
render(Square())

Instance Variables vs Class Variables — Where Most Junior Devs Get Burned

A common disaster scenario: a shared list on a class gets mutated by one instance, and suddenly every object in the system has corrupted data. That's the difference between class variables (shared across all instances) and instance variables (unique per object). Class variables are defined directly in the class body—like Dog.species = 'Canine'. Instance variables get set inside __init__ with self.name = name. The trap: mutable class variables, like lists or dicts. When you append to self.items and items is a class variable, you're modifying the class, not the instance. Python's name resolution follows a simple chain: instance → class → parent classes. Understanding this chain prevents that 3 AM PagerDuty call where a list of 'pending tasks' is shared across all users because someone forgot to initialize it inside __init__. Always put mutable defaults inside __init__, never in the class body.

// io.thecodeforge
class TaskManager:
    tasks = []  # Class variable — shared by all instances

    def __init__(self, name):
        self.name = name

    def add_task(self, task):
        self.tasks.append(task)  # Mutates the class variable

# Two instances sharing the same list:
alice = TaskManager('Alice')
bob = TaskManager('Bob')
alice.add_task('Fix login bug')
bob.add_task('Deploy hotfix')
print(alice.tasks)  # ['Fix login bug', 'Deploy hotfix']
print(bob.tasks)    # Same list, same corruption

Method Overloading in Python — It Doesn't Exist, So Don't Fake It

Overloaded methods sound great: same function name, different parameters, handling multiple behaviors. But Python doesn't support traditional method overloading like Java or C++. If you define def greet(self, name) and then def greet(self, name, age), the second definition silently overwrites the first. No compile error. No warning. Just a runtime surprise. The Pythonic alternative: default arguments, variable-length args (args and *kwargs), or dispatch logic with isinstance(). Or use @singledispatchmethod from the functools module for single-argument dispatch. The deeper lesson: Python's dynamic nature means the last definition wins, and overloading is a static-typing workaround. We solve the same problem differently. When you're tempted to overload, ask: 'Am I handling multiple input types or multiple behaviors?' For types, use type hints and dispatch. For behaviors, split into separate methods. Your team's code review will thank you.

// io.thecodeforge
from functools import singledispatchmethod

class Reporter:
    @singledispatchmethod
    def log(self, arg):
        raise NotImplementedError('Unsupported type')
    
    @log.register(int)
    def _(self, arg: int):
        print(f'Int log: {arg}')
    
    @log.register(str)
    def _(self, arg: str):
        print(f'String log: {arg}')

r = Reporter()
r.log(42)    # Int log: 42
r.log('err') # String log: err