Skip to content
❌ No design pattern talk❌ No theory lectures❌ No abstraction for abstraction’s sake✅ Inheritance only when the problem forces it✅ Heavy implementation with clear rules
Implement inheritance when requiredShare common data and behavior using a base classOverride methods correctlyUse super() properlyHandle different rules for different subclassesPass machine-coding tests involving parent–child classes
Employee → FullTime / PartTimeAccount → Savings / CurrentVehicle → Bike / Car
Child inherits:VariablesMethodsChild can:Override methodsAdd new behavior
Same method nameDifferent behaviorCaller does NOT need to know type
Use inheritanceOverride area()No prints, only return
Use inheritance only where specifiedDo NOT duplicate common fieldsCall super().__init__() when requiredOverride only the required methodsKeep logic exactly as specified
account numberbalance
Stores account_number and balanceget_balance() returns balancewithdraw() in base class should:Always return False(Base class should not allow withdrawal)Cannot withdraw more than balanceIf amount <= 0 → return FalseIf amount > balance → return FalseElse:Deduct amountReturn TrueCan overdraft up to -1000If amount <= 0 → return FalseIf balance - amount < -1000 → return FalseElse:Deduct amountReturn True
Base class send() should:Always return FalseIf message length == 0 → return FalseElse → return TrueIf message length > 160 → return FalseElse → return True
No actual sendingJust enforce rules via return values
Base class may intentionally do nothingOverride only behavior, not structureUse self.balance inherited from baseDo not add extra fieldsTests will treat objects polymorphically
✅ Correct inheritance hierarchy✅ Proper method overriding✅ Correct use of super() if needed✅ No duplicate fields✅ Correct rule enforcement✅ Passes all test cases
Why does base Account.withdraw() return False?Why not duplicate balance in child classes?What breaks if child does not override method?When should inheritance be avoided?
Zeni Study
- Pages
Share
Explore
Day 4 : Bank account and notification system.
Today we cover Inheritance, but in a strict, interview-realistic way:
🟢 Day 4 — Inheritance & Method Overriding (Machine Coding Style)
🎯 Day 4 Objective
By the end of Day 4, the candidate should be able to:
Today is about reusing structure, not logic guessing.
1️⃣ Teaching Script — What to Say
Start with This Reality
“Most of the time, you do NOT need inheritance. But when the problem says ‘There are multiple types of X’, you almost always do.”
Examples from interviews:
Inheritance exists to share common structure, not to look smart.
2️⃣ Core Idea of Inheritance (Only What’s Needed)
A child class IS A parent class, but with extra or different behavior.
3️⃣ Small Code to Understand (Minimal, Clear)
Example — Employee Base Class
class Employee:
def __init__(self, emp_id: int, salary: int):
self.emp_id = emp_id
self.salary = salary
def calculate_pay(self) -> int:
return self.salary
Child Class
class PartTimeEmployee(Employee):
def calculate_pay(self) -> int:
return self.salary // 2
Key Observations
🧠 Machine coding tests whether you override correctly, not creatively.
4️⃣ Mandatory Warm-up Practice
Task
Implement the following:
Base class: Shape
- area() → int
Child classes:
- Square (side)
- Rectangle (length, width)
Rules:
👉 This ensures candidate understands override mechanics.
5️⃣ Machine Coding Rules (Day 4 Rules)
6️⃣ Main Problem 1 — Account Types (Classic Interview Question)
Problem Statement
You are implementing a banking system with different account types.
All accounts have:
But withdrawal rules differ.
Class Definitions (DO NOT MODIFY)
class Account:
def __init__(self, account_number: str, balance: int):
pass
def withdraw(self, amount: int) -> bool:
pass
def get_balance(self) -> int:
pass
class SavingsAccount(Account):
def withdraw(self, amount: int) -> bool:
pass
class CurrentAccount(Account):
def withdraw(self, amount: int) -> bool:
pass
Requirements (Very Strict)
Account (Base Class)
SavingsAccount
CurrentAccount
Example
sa = SavingsAccount("S1", 500)
sa.withdraw(600) # False
sa.withdraw(200) # True
ca = CurrentAccount("C1", 500)
ca.withdraw(1200) # True (balance becomes -700)
ca.withdraw(500) # False (would exceed overdraft)
7️⃣ Main Problem 2 — Notification System
Problem Statement
You are implementing a notification system.
Different notification types behave differently, but share a common interface.
Class Definitions (DO NOT MODIFY)
class Notification:
def send(self, message: str) -> bool:
pass
class EmailNotification(Notification):
def send(self, message: str) -> bool:
pass
class SMSNotification(Notification):
def send(self, message: str) -> bool:
pass
Requirements
Notification
EmailNotification
SMSNotification
Important Note
8️⃣ No-Guess Hints (Read Only If Stuck)
9️⃣ Evaluation Checklist
A correct solution:
🔟 Reflection (Candidate Must Answer)
⭐ Day 4 Golden Rule
Inheritance is a tool, not a default. Use it only when the problem forces it.
🧪 Day 4 — Test File
📁 Folder Structure
day4/
│
├── solution.py
└── test_day4.py
📄 (Given to Candidate)
class Account:
def __init__(self, account_number: str, balance: int):
pass
def withdraw(self, amount: int) -> bool:
pass
def get_balance(self) -> int:
pass
class SavingsAccount(Account):
def withdraw(self, amount: int) -> bool:
pass
class CurrentAccount(Account):
def withdraw(self, amount: int) -> bool:
pass
class Notification:
def send(self, message: str) -> bool:
pass
class EmailNotification(Notification):
def send(self, message: str) -> bool:
pass
class SMSNotification(Notification):
def send(self, message: str) -> bool:
pass
📄 test_day4.py (Evaluator File)
from solution import (
Account,
SavingsAccount,
CurrentAccount,
EmailNotification,
SMSNotification
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.