Interview Q&A

Short answer: The Singleton pattern ensures a class has only one instance and provides a global point of access to it. It’s commonly used when exactly one object is needed to coordinate actions across the system, such as configuration settings, logging, or caching.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: The Factory pattern is a creational design pattern that provides an interface for creating objects but allows subclasses or implementations to decide which class to instantiate.

Explain a bit more

It’s used to encapsulate object creation, promoting loose coupling and flexibility when the exact types of objects aren’t known until runtime. Use case: When a class can’t anticipate the class of objects it needs to create, or when you want to delegate responsibility for object creation to subclasses.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: The Strategy pattern is a behavioral design pattern that defines a family of algorithms, encapsulates each one, and makes them interchangeable at runtime. It allows the algorithm to vary independently from clients that use it. Problem it solves: Avoids large if-else or switch statements when selecting behavior and promotes flexibility by decoupling the algorithm from the client using it.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Applications? The Repository pattern abstracts the data access layer from the business logic by providing collection-like interface to access domain objects. It helps keep data access logic centralized and makes the codebase easier to maintain, test, and swap out data sources (e.g., switching from EF Core to Dapper or an API). Say this in the… interview

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: The Repository pattern abstracts the data access layer from the business logic by providing a collection-like interface to access domain objects. It helps keep data access logic centralized and makes the codebase easier to maintain, test, and swap out data sources (e.g., switching from EF Core to Dapper or an API).

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: The Unit of Work pattern is a design pattern used to maintain a list of operations to be performed within a single transaction. It ensures that all operations either succeed or fail together, providing consistency and managing changes to multiple business objects during a transaction. It coordinates the writing out of changes and resolves potential concurrency issues.

Real-world example (ShopNest)

Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Dependency Injection (DI) is a design pattern that allows an object to receive its dependencies from an external source rather than creating them itself. This promotes loose coupling, enhances testability, and simplifies code maintenance. Benefits: Improves modularity Enables easier unit testing (via mock dependencies) Promotes adherence to SOLID principles (especially the Dependency Inversion Principle)

Real-world example (ShopNest)

Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Transient: A new instance is created every time it is requested. Scoped: A single instance is created per request/HTTP request. Singleton: A single instance is created and shared across the application lifetime. Lifetime Created Per Use Case Transient Every injection Lightweight, stateless services Scoped HTTP Request Web services handling per-request data Singleton App lifetime Logging, configuration, cache

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: The Single Responsibility Principle (SRP) states that a class should have only one reason to change. In other words, it should have only one responsibility or job. Each class should do one thing, and do it well. For example, a class that handles user authentication should not also be responsible for logging or sending emails.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Before (OCP Violation): public class DiscountCalculator If you need to support a new customer type, you must modify this method — violating OCP. After (OCP Compliant): public interface IDiscountStrategy

Example code

{
public decimal CalculateDiscount(string customerType)
{
if (customerType == "Regular") return 10;
if (customerType == "Premium") return 20;
if (customerType == "VIP") return 30;
return 0;
}
}
{ decimal GetDiscount(); }
public class RegularCustomerDiscount : IDiscountStrategy
{
public decimal GetDiscount() => 10;
}
public class PremiumCustomerDiscount : IDiscountStrategy
{
public decimal GetDiscount() => 20;
}
public class VipCustomerDiscount : IDiscountStrategy
{
public decimal GetDiscount() => 30;
} Now you can add new customer types without modifying existing code — just create a new strategy.

Real-world example (ShopNest)

Open/Closed in ShopNest: add a new payment method by adding a class, not by editing a giant switch in CheckoutService.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: The Liskov Substitution Principle (LSP) states that: Subtypes must be substitutable for their base types without altering the correctness of the program. In other words, if class S is a subclass of class T, then objects of type T should be replaceable with objects of type S without breaking the application. This ensures that inheritance models is-a relationships correctly.

Real-world example (ShopNest)

Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Example (Violation of LSP): public class Rectangle

Example code

{
public virtual int Width { get; set; }
public virtual int Height { get; set; }
public int Area() => Width * Height;
}
public class Square : Rectangle
{
public override int Width
{
set { base.Width = base.Height = value; }
}
public override int Height
{
set { base.Width = base.Height = value; }
}
} Now if you substitute Rectangle with Square: Rectangle rect = new Square();
rect.Width = 5;
rect.Height = 10; Console.WriteLine(rect.Area()); // Outputs 100, but logically expected 50 ❌ The behavior is incorrect — this is a violation of LSP.

Real-world example (ShopNest)

Open/Closed in ShopNest: add a new payment method by adding a class, not by editing a giant switch in CheckoutService.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: The Interface Segregation Principle (ISP) states that: Clients should not be forced to depend on interfaces they do not use. This means that interfaces should be small and focused, containing only the methods that are relevant to the implementing class. It prevents "fat" or "bloated" interfaces.

Real-world example (ShopNest)

Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: The Dependency Inversion Principle (DIP) states that: High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. In other words: High-level business logic shouldn't depend on concrete implementations. Instead, both high- and low-level components should depend on interfaces or abstract classes.

Real-world example (ShopNest)

Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: DAO (Data Access Object) focuses on low-level database operations and CRUD, typically mapping tables to objects. Repository abstracts data access at the domain level, working with aggregates/entities and encapsulating business logic. Repository often uses DAO internally but is more aligned with domain-driven design.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: IServiceCollection: A container used during app startup to register services and their lifetimes (Scoped, Transient, Singleton). It acts as a service registry. IServiceProvider: The built container that resolves and provides instances of registered services at runtime. It uses the registrations to create and inject dependencies.

Real-world example (ShopNest)

Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Inheritance creates an “is-a” relationship, where a subclass inherits behavior and properties from a parent class. It can lead to tight coupling and fragile hierarchies if overused. Composition creates a “has-a” relationship, where a class contains instances of other classes and delegates behavior to them. It’s more flexible and promotes loose coupling.

Real-world example (ShopNest)

Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Cohesion: Degree to which elements of a module belong together. High cohesion means focused, well-defined responsibilities. Coupling: Degree of interdependence between modules. Low coupling means modules are independent and changes in one don’t affect others.

Real-world example (ShopNest)

Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.