How Inheritance Works in Python: super(), the MRO & Composition vs Inheritance

Inheritance questions get interesting fast: super() with multiple parents, the method resolution order, the diamond problem, and the senior judgement call of composition versus inheritance. Here's the depth interviewers actually probe.

Basic inheritance and super()

class Animal:
    def __init__(self, name):
        self.name = name
    def speak(self):
        raise NotImplementedError
 
class Dog(Animal):
    def __init__(self, name, breed):
        super().__init__(name)      # run the parent's __init__ — don't reassign self.name by hand
        self.breed = breed
    def speak(self):                # override
        return "Woof!"
 
d = Dog("Rex", "Corgi")
print(d.name, d.breed, d.speak())   # Rex Corgi Woof!

super().__init__(name) delegates to the parent constructor. Skipping it (and setting self.name manually) works for single inheritance but breaks cooperative multiple inheritance — always prefer super().

Multiple inheritance and the MRO

Python allows multiple base classes and resolves lookups through the method resolution order, computed by the C3 linearisation algorithm:

class A:
    def who(self): return "A"
class B(A):
    def who(self): return "B"
class C(A):
    def who(self): return "C"
class D(B, C):
    pass
 
print(D().who())            # "B"
print([c.__name__ for c in D.__mro__])
# ['D', 'B', 'C', 'A', 'object']

D() resolves who to B because the MRO visits D → B → C → A → object. This is the diamond problem (D inherits from A twice via B and C), and the MRO is how Python resolves it consistently — each class appears once, children before parents.

Cooperative inheritance: super() follows the MRO

super() does not mean "my parent" — it means "the next class in the MRO." That's what makes a chain of super().__init__() calls each run exactly once:

class Base:
    def __init__(self): print("Base")
class Left(Base):
    def __init__(self): print("Left");  super().__init__()
class Right(Base):
    def __init__(self): print("Right"); super().__init__()
class Child(Left, Right):
    def __init__(self): print("Child"); super().__init__()
 
Child()      # Child, Left, Right, Base  — each runs once, via the MRO

If Left had called Base.__init__(self) directly instead of super(), Right.__init__ would be skipped. This is the single most common multiple-inheritance bug.

Mixins and abstract base classes

A mixin is a small class that adds focused behaviour via inheritance without being a full parent:

class JsonMixin:
    def to_json(self):
        import json; return json.dumps(self.__dict__)
 
class User(JsonMixin):
    def __init__(self, name): self.name = name
 
User("Ada").to_json()      # '{"name": "Ada"}'

An abstract base class goes the other way — it forces subclasses to implement methods:

from abc import ABC, abstractmethod
 
class Repository(ABC):
    @abstractmethod
    def get(self, id): ...
 
Repository()   # TypeError: can't instantiate abstract class

The senior take: composition over inheritance

Deep inheritance hierarchies are rigid — a change high up ripples everywhere, and a subclass is coupled to its parent's internals. Often you don't need "is-a", you need "has-a":

class Engine:
    def start(self): return "vroom"
 
class Car:
    def __init__(self):
        self.engine = Engine()      # composition: Car HAS an Engine
    def start(self):
        return self.engine.start()  # delegate

Composition is more flexible (swap the Engine at runtime), easier to test (inject a fake), and avoids the MRO gymnastics. "Favour composition over inheritance" is a phrase worth saying — and justifying — in a senior interview.

Common interview traps

• Calling Parent.__init__(self) in multiple inheritance — skips siblings; use super().
• Assuming super() means the literal parent — it's the next class in the MRO.
• Deep hierarchies — the fragile-base-class problem; reach for composition.
• Forgetting super().__init__() — the parent's state never initialises.

Interviewer follow-ups

• "What's the diamond problem and how does Python solve it?" — multiple inheritance from a common ancestor; the MRO (C3) linearises it consistently.
• "How does overriding relate to polymorphism?" — overriding is one way to achieve polymorphism; duck typing is the other.
• "When would you NOT use inheritance?" — when the relationship is "has-a", or when you only want code reuse — use composition.

Related guides

• OOP in Python: classes, objects & the four pillars
• Polymorphism in Python (duck typing, dunder methods, singledispatch)

Sources

• Python docs — Inheritance