Object-Oriented Programming
Dataclasses
Simplified class definitions with auto-generated boilerplate
Interview: Modern Python (3.7+) — tests knowledge of dataclass features, field options, and when to use vs regular classes
Dataclasses (introduced in Python 3.7 via @dataclass) automatically generate boilerplate code like __init__, __repr__, __eq__, and __hash__. They're ideal for classes that primarily store data, reducing code while maintaining type hints and IDE support.
What Gets Auto-Generated
__init__: Constructor from field definitions__repr__: Human-readable representation__eq__: Value-based equality comparison__hash__: Hashing (if frozen or eq=True)__lt__,__le__, etc.: Ordering (withorder=True)
Field Options
The field() function provides fine-grained control: default factories for mutable defaults, excluding fields from repr/compare, and setting field metadata.
Frozen Dataclasses
Setting frozen=True makes instances immutable — perfect for value objects, configuration, and thread-safe data. Frozen dataclasses are also hashable by default.
Interview Tip
Know the difference between @dataclass and NamedTuple: dataclasses are mutable by default and more flexible; NamedTuples are immutable and lighter. Also compare with TypedDict for dict-like data.
Use Cases
Data transfer objects (DTOs) for APIs and microservices
Configuration classes with validation in __post_init__
Value objects in domain-driven design (frozen dataclasses)
Replacing dictionaries with typed, validated structures
Database models and ORM entities with auto-generated methods
Common Mistakes
Using mutable default values directly (use field(default_factory=list) instead)
Forgetting that dataclass fields without defaults must come before fields with defaults
Not using __post_init__ for derived/computed fields that depend on __init__ values
Confusing frozen=True with regular dataclass — frozen instances can't be modified
Using dataclass when a simple dict or NamedTuple would suffice (overengineering)