Question 1

What is the Singleton pattern and what are its drawbacks?

Accepted Answer

The Singleton pattern restricts a class to a single instance and provides a global access point to it. The canonical implementation makes the constructor private, stores the instance in a static field, and exposes a static `getInstance()` method that either creates or returns the existing instance.

In Python, the pattern is often implemented via `__new__`, a module-level object (Python modules are singletons by nature), or a metaclass. In languages like Java or C#, double-checked locking or initialization-on-demand holder idioms handle thread safety.

Common legitimate use cases include: database connection pools (one shared pool across the app), configuration objects loaded once at startup, logging systems where all components write to the same logger, and thread pool managers. The shared resource argument is the strongest justification.

The drawbacks are significant and worth understanding deeply. First, Singleton introduces hidden global state. Any code anywhere can call `getInstance()` and mutate shared state, making execution order unpredictable and bugs hard to reproduce. Second, it creates tight coupling — callers depend on a concrete class, not an interface, making the dependency invisible in function signatures. Third, testability suffers severely: unit tests cannot easily substitute a mock or reset state between test runs. A singleton database connection in tests bleeds state across test cases unless you add explicit reset hooks — which is a smell. Fourth, in multi-threaded environments, lazy initialization requires careful synchronization to avoid double initialization. Fifth, in distributed systems, a 'single instance' guarantee is meaningless — multiple processes or pods each have their own instance.

The modern alternative in most codebases is dependency injection. Pass the shared resource as a constructor parameter rather than having classes reach out to a global. This makes dependencies explicit, allows substitution in tests, and keeps the single-instance guarantee at the composition root (where the DI container or main function wires things together). You still have one instance — you just don't enforce it inside the class itself.

When you see Singleton in a codebase, it often signals that dependency injection wasn't available or wasn't considered. It's a pragmatic tool, but one with real costs that compound as a codebase grows.

Question 2

What is the Factory pattern and when would you use it?

Accepted Answer

The Factory pattern is a creational design pattern that encapsulates object creation logic behind an interface, so callers don't need to know which concrete class they're instantiating. The term covers two related patterns: Factory Method (a method that subclasses override to produce objects) and Abstract Factory (an interface for creating families of related objects).

The core problem it solves: when you write `new ConcreteClass()` throughout a codebase, you've hardcoded a dependency on that specific class. If the class changes, or you need to swap in a different implementation (different database driver, different payment provider, different notification channel), you must find and change every instantiation site. A factory centralizes that decision.

A practical example: an application supports multiple notification channels — email, SMS, Slack. Rather than scattering `if channel == 'email': return EmailNotifier()` logic throughout the codebase, a `NotifierFactory.create(channel)` method owns that conditional. Callers only work with the `Notifier` interface. Adding push notifications means touching one file.

When to use it: when the type to create is determined at runtime (from config, user input, or a strategy name); when you want to isolate object construction from business logic for testability; when constructing an object is complex enough that you want to hide the details; and when you anticipate needing to swap implementations. It pairs naturally with dependency injection — factories are often what DI containers call to build objects.

Abstract Factory extends this: instead of creating one type of object, it creates a family. A UI toolkit factory might produce buttons, checkboxes, and dialogs that all share a visual theme. Swapping the factory swaps the entire family consistently.

A Python-idiomatic approach often skips the class entirely and uses a dictionary mapping strings to classes, or a registration pattern where subclasses register themselves. This achieves the same decoupling without ceremony.

The tradeoff: factories add a layer of indirection. For simple, stable object creation that will never change, they add complexity without value. Use them when variability is real, not hypothetical.

Question 3

What is the Strategy pattern and when would you use it?

Accepted Answer

The Strategy pattern is a behavioral design pattern that defines a family of algorithms, encapsulates each one, and makes them interchangeable. The key insight is that the algorithm is extracted from the context that uses it and placed behind an interface, so the context can switch algorithms at runtime without knowing the details of any specific implementation.

**Structure:**
- **Context:** holds a reference to a Strategy object and delegates the work to it
- **Strategy interface:** defines the method signature all concrete strategies must implement
- **Concrete Strategies:** implement the algorithm variations

Python example (payment processing):

```python
from abc import ABC, abstractmethod

class PaymentStrategy(ABC):
    @abstractmethod
    def charge(self, amount: float) -> bool: ...

class StripeStrategy(PaymentStrategy):
    def charge(self, amount: float) -> bool:
        # call Stripe API
        return True

class PayPalStrategy(PaymentStrategy):
    def charge(self, amount: float) -> bool:
        # call PayPal API
        return True

class Checkout:
    def __init__(self, payment: PaymentStrategy):
        self._payment = payment

def process(self, amount: float):
        if not self._payment.charge(amount):
            raise PaymentError('Charge failed')
```

The `Checkout` context doesn't know or care whether it's using Stripe or PayPal — it only calls `charge()`. Adding a new payment provider requires implementing the interface and injecting it, without modifying `Checkout`.

**When to use:**
- You have multiple variations of an algorithm that differ only in behavior (sorting algorithms, compression codecs, pricing strategies, authentication mechanisms)
- You want to eliminate conditionals that select algorithm variants (`if payment_type == 'stripe': ... elif payment_type == 'paypal': ...`)
- You need to swap algorithms at runtime based on configuration or user selection
- You want to test each algorithm in isolation

**Python-specific note:** In Python, first-class functions often replace full Strategy classes for simple cases. Passing a callable is idiomatic when the strategy has a single method:

```python
def checkout(amount, charge_fn):
    return charge_fn(amount)

checkout(100.0, stripe_charge)  # just pass the function
```

Full class-based Strategy is warranted when the strategy needs state (e.g., maintaining a connection) or multiple related methods.

The Open/Closed Principle is the direct motivation: the system is open for extension (new strategies) but closed for modification (context unchanged).

Question 4

What is the Observer pattern and when would you use it?

Accepted Answer

The Observer pattern (also called Publish-Subscribe or Event Listener) defines a one-to-many dependency between objects: when the **subject** (publisher/observable) changes state, all registered **observers** (subscribers/listeners) are notified and updated automatically.

The core problem it solves: how do you avoid tight coupling between an object that produces events and the objects that react to those events? Without Observer, the subject would need to know about every interested party and call them directly.

**Structure:**
- **Subject/Observable:** maintains a list of observers, provides `subscribe(observer)` and `unsubscribe(observer)` methods, calls `notify()` on all observers when state changes
- **Observer interface:** defines the `update(event)` method all observers implement
- **Concrete Observers:** implement specific reactions

Python example (stock price monitor):

```python
from abc import ABC, abstractmethod
from typing import List

class Observer(ABC):
    @abstractmethod
    def update(self, price: float): ...

class StockTicker:
    def __init__(self):
        self._observers: List[Observer] = []
        self._price: float = 0.0

def subscribe(self, obs: Observer):
        self._observers.append(obs)

def set_price(self, price: float):
        self._price = price
        for obs in self._observers:
            obs.update(price)

class AlertObserver(Observer):
    def update(self, price: float):
        if price > 100:
            print(f'Alert: price is {price}')
```

**When to use:**
- One object's change requires updating an unknown number of other objects (GUI event systems, event buses, reactive programming)
- Decoupling is more important than call-graph clarity (different subsystems reacting to domain events)
- Real-world examples: Django signals, `EventEmitter` in Node.js, `Observable` in RxJS, `UIControl` target-action in iOS, pytest hooks

**Pitfalls:**
- **Memory leaks:** If observers hold strong references to the subject (or vice versa), neither can be garbage collected. Use `weakref` for observer lists in long-lived subjects.
- **Unexpected notification order:** Observers are notified in registration order by default. Don't write code that depends on this ordering.
- **Cascading updates:** An observer that modifies the subject triggers another notification cycle — can cause infinite loops or hard-to-trace bugs.
- **Synchronous blocking:** In Python's standard Observer, `notify()` is synchronous. A slow observer blocks the subject. For high-throughput systems, push to a message queue instead.
- **Debugging difficulty:** The implicit call graph makes stack traces hard to follow. Structured logging in observers and subjects is essential.

Distinguish from Strategy: Observer is about communication between objects; Strategy is about swappable algorithms.

Question 5

What is Inversion of Control and Dependency Injection?

Accepted Answer

Inversion of Control (IoC) is a design principle where the control of object creation and dependency management is transferred from the object itself to an external entity (a framework or container). The name describes what is inverted: traditionally, a class is in control of constructing its own dependencies; with IoC, that control is inverted — the class declares what it needs, and something else provides it.

Dependency Injection (DI) is the most common technique for implementing IoC. Instead of a class instantiating its dependencies with `new`, those dependencies are "injected" (passed in) from outside — typically via constructor parameters, setter methods, or an interface.

**Without DI (tight coupling):**
```python
class OrderService:
    def __init__(self):
        self.db = PostgresDatabase(host='prod-db')  # hardcoded
        self.email = SendgridEmailClient(api_key='...')  # hardcoded
```

**With DI (loose coupling):**
```python
class OrderService:
    def __init__(self, db: Database, email: EmailClient):
        self.db = db
        self.email = email
```

Now `OrderService` depends on abstractions (`Database`, `EmailClient` interfaces), not concrete implementations. In tests, you inject mocks. In production, you inject the real implementations. The class doesn't know or care which.

**Types of injection:**
- **Constructor injection** (preferred): dependencies passed in `__init__` / constructor. Makes dependencies explicit and the object always valid after construction.
- **Setter injection**: dependencies set via methods after construction. Allows optional dependencies but leaves objects in a partially-initialized state.
- **Interface injection**: the dependency provides an injector interface the class implements. Rare and more complex.

**DI containers** (Spring, Angular, .NET DI, Guice) automate the wiring. You register types with the container, and it resolves the full dependency graph automatically. This removes manual wiring boilerplate but adds framework coupling.

The core benefits: **testability** (inject mocks/stubs), **replaceability** (swap implementations without changing the dependent class), **separation of concerns** (construction logic moved to the composition root), and **adherence to the Dependency Inversion Principle** (depend on abstractions, not concretions — the D in SOLID).

Question 6

What is high cohesion and loose coupling and why do they matter?

Accepted Answer

**Cohesion** measures how strongly related the responsibilities inside a single module or class are. High cohesion means everything in the unit works toward one clear purpose. A class that handles user authentication and also formats PDF reports has low cohesion — its responsibilities are unrelated. High cohesion makes units easier to understand, test, and reuse because there is a single axis of change.

**Coupling** measures how much one module depends on the internal details of another. Tight coupling means a change in module A forces changes in module B. Loose coupling means modules interact only through stable, narrow interfaces — they know what the other module does, not how it does it.

The two principles are complementary: high cohesion pushes related behavior together, loose coupling pushes unrelated modules apart. Together they minimize the blast radius of change.

**Practical forms of coupling to reduce:**
- **Data coupling**: pass only the data a function needs, not entire objects
- **Control coupling**: don't pass flags that change internal behavior — split into two functions
- **Content coupling**: never access another module's private state directly
- **Common coupling**: avoid shared global mutable state

**Techniques for loose coupling:**
- Depend on interfaces/abstract classes rather than concrete implementations (Dependency Inversion)
- Inject dependencies rather than instantiating them internally
- Use events or message queues to decouple producers from consumers
- Define clear module boundaries with versioned contracts (APIs)

In a microservices context, a service with high cohesion owns one business domain end-to-end. Loose coupling means services communicate over APIs, not shared databases. A change to the Order service's database schema should not require the Inventory service to be redeployed.

The interview signal: candidates who can cite a real refactoring — 'we extracted a notification module because it was tangled with billing' — demonstrate they have lived the tradeoff, not just memorized the definition.

Design Principles Interview Questions — What Senior Engineers Need to Know

All 6 Questions

How to Prepare

Related Topics

Test Your Knowledge