Interview Q&A

Short answer: You can identify SRP violations by asking questions like: Does this class perform more than one function (e.g., data access and business logic)?

Explain a bit more

Does it change for different reasons (e.g., changes in UI and database)? Does it have too many dependencies or too much code? Are there “and”s in the class name or method descriptions? E.g., ReportGeneratorAndPrinter. Common signs: Long classes or large files Many unrelated methods Hard-to-test code

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 (SRP Violation): public class Invoice

Example code

{
public void GenerateInvoice() { /* logic */ }
public void SaveToDatabase() { /* logic */ }
public void SendEmail() { /* logic */ }
} This class has 3 responsibilities: generating, saving, and emailing. After (SRP-compliant): public class InvoiceGenerator
{
public void Generate() { /* logic */ }
}
public class InvoiceRepository
{
public void Save(Invoice invoice) { /* logic */ }
}
public class EmailService
{
public void Send(Invoice invoice) { /* logic */ }
} Now each class has a single reason to change.

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: SRP improves maintainability by: Reducing complexity – Classes are smaller and easier to understand. Easier testing – Each class can be tested in isolation. Better separation of concerns – Business logic, data access, and infrastructure code are kept apart. Lower risk of bugs – Changes in one responsibility don’t affect others. Ultimately, it leads to more modular, flexible, and robust code.

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: If a class has multiple responsibilities: It becomes tightly coupled and harder to change without affecting other parts. Changes are more error-prone and often introduce bugs. Testing becomes harder since the class relies on multiple behaviors. Code reusability and readability suffer due to mixed concerns. You violate SRP, which makes code harder to maintain in the long run. Open/Closed Principle (OCP)

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 Open/Closed Principle (OCP) states that: Software entities (classes, modules, functions) should be open for extension but closed for modification. This means you should be able to add new behavior to a class without changing its existing code, which helps avoid breaking existing functionality.

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: To design classes that follow OCP: Use abstraction (interfaces or abstract classes). Rely on polymorphism and inheritance. Apply composition over inheritance when suitable. Follow design principles like Strategy, Decorator, or Template Method patterns. ✅ Extend behavior through new classes rather than modifying existing code.

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: Several design patterns are built around the idea of making systems extensible without modifying core logic: Pattern How It Helps With OCP Strategy Allows changing behavior by swapping strategies.

Explain a bit more

Decorator Adds new responsibilities dynamically without changing original code. Template Method Allows subclasses to override certain steps in an algorithm. Factory Method Makes it easy to introduce new types without altering existing logic. Observer Extends behavior in reaction to events without altering the source.

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: 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: Interfaces and abstract classes provide a contract that other classes can implement or inherit.

Explain a bit more

They enable polymorphism, which allows behavior to be extended without altering existing code. By programming to abstractions (not concrete implementations), you can easily introduce new behavior (via new implementations) while keeping the core logic unchanged. ✅ OCP encourages extending via new subclasses or interface implementations, not modifying existing ones. Liskov Substitution Principle (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 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: Violating LSP can lead to: Unexpected behavior when a subclass does not honor the contract of the base class. Code that breaks at runtime when substituting a derived class. Tightly coupled code that depends on specific implementations rather than abstractions. Unit tests failing when testing subclasses in place of base classes. Essentially, it defeats the purpose of polymorphism.

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: 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: To ensure subclasses follow LSP: Subclasses should not override behavior in a way that breaks expected behavior.

Explain a bit more

Subclasses should preserve the invariants and preconditions/postconditions of the base class. Avoid overriding methods to throw exceptions for valid base class behavior. Use composition over inheritance if a subclass doesn’t strictly conform to the base class behavior. Write unit tests to verify that the subclass behaves identically to the base class in all valid scenarios. ✅ Ask yourself: Can this subclass be used anywhere the base class is used — without surprises?

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: LSP is fundamentally about correct use of inheritance. While inheritance allows code reuse, LSP ensures that the behavior of subclasses remains consistent with that of the base class. If a subclass changes the meaning or violates the expectations of the base class’s behavior, it's misusing inheritance. Interface Segregation Principle (ISP)

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: Small, specific interfaces: Promote separation of concerns Make classes easier to implement and test Reduce the risk of breaking changes Avoid forcing classes to implement irrelevant methods Increase reusability and readability In contrast, large interfaces force classes to implement methods they may not need — leading to fragile and cluttered code.

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: ISP improves code flexibility by: Allowing classes to only depend on what they actually use Making it easier to extend or replace functionality without affecting unrelated parts Enabling composition over inheritance Making interfaces easier to mock or stub in unit tests Encouraging clean, modular design Smaller interfaces result in lower coupling and better maintainability.

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: Violation Example: public interface IWorker

Example code

{ void Work(); void Eat(); void Sleep(); }
public class Robot : IWorker
{
public void Work() { /* logic */ }
public void Eat() { throw new NotImplementedException(); }
public void Sleep() { throw new NotImplementedException(); }
} ❌ Robot is forced to implement Eat() and Sleep(), which don’t make sense for it.

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: Refactored Using ISP: public interface IWorkable

Example code

{ void Work(); }
public interface IFeedable
{ void Eat(); }
public interface ISleepable
{ void Sleep(); }
public class Human : IWorkable, IFeedable, ISleepable
{
public void Work() { }
public void Eat() { }
public void Sleep() { }
}
public class Robot : IWorkable
{
public void Work() { }
} ✅ Now each class implements only the interfaces it needs — in line with ISP. Inversion Principle (DIP)

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 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: Aspect Dependency Inversion Principle (DIP) Dependency Injection (DI) Definitio A design principle about depending on abstractions A technique for passing dependencies Goal Decouple high-level logic from low-level details Provide dependencies to objects Relation DIP motivates the need for DI DI is a way to implement DIP Focus What to depend on (abstractions) How dependencies are supplied ✅ DIP is a design principle,…

Explain a bit more

while DI is a design pattern/technique to implement that principle.

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: Abstractions (e.g., interfaces or abstract classes): Decouple components so changes in one don’t ripple through others Enable substitution of different implementations easily Allow for easier unit testing with mocks/stubs Promote extensibility and maintainability Serve as contracts that both high- and low-level modules depend on

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: ❌ Without DIP (Tightly Coupled): public class FileLogger

Example code

{
public void Log(string message) => Console.WriteLine("File log: " + message); }
public class OrderService
{
private readonly FileLogger _logger = new FileLogger();
public void ProcessOrder()
{ // Logic _logger.Log("Order processed."); }
} OrderService is tightly coupled to FileLogger. ✅ With DIP (Loosely Coupled via Abstraction): public interface ILogger
{ void Log(string message); }
public class FileLogger : ILogger
{
public void Log(string message) => Console.WriteLine("File log: " + message); }
public class OrderService
{
private readonly ILogger _logger;
public OrderService(ILogger logger)
{
_logger = logger;
}
public void ProcessOrder()
{ // Logic _logger.Log("Order processed."); }
} Now OrderService depends on the abstraction (ILogger), not the concrete FileLogger. You can easily substitute with DatabaseLogger, ConsoleLogger, or a mock in tests.

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: ✅ Key Benefits: Decouples components — changes in low-level modules won’t affect high-level ones Improves testability — you can easily inject mocks/stubs Enhances flexibility — swap implementations without touching core logic Promotes reuse — abstractions can be used across different modules Supports SOLID architecture — especially when combined with DI and IoC containers Advanced & Scenario-Based Questions

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: Design patterns provide structured, reusable solutions that embody SOLID principles. For example, the Strategy pattern supports OCP by allowing behavior extension without modifying existing code; Repository separates data access (SRP); Dependency Injection supports DIP by decoupling high- and low-level modules. Using patterns helps keep code clean, modular, and maintainable.

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.