Interview Q&A

Short answer: How? Yes, DI can be implemented manually without using a DI container. You simply pass dependencies through constructors or methods: public class OrderService

Example code

{
private readonly IOrderRepository _repo;
public OrderService(IOrderRepository repo)
{
_repo = repo;
}
} // Manual injection var repo = new OrderRepository();
var service = new OrderService(repo); This is suitable for small or simple applications, though not scalable for large apps.

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: Yes, DI can be implemented manually without using a DI container.

Explain a bit more

You simply pass dependencies through constructors or methods: public class OrderService { private readonly IOrderRepository _repo; public OrderService(IOrderRepository repo) { _repo = repo; } } // Manual injection var repo = new OrderRepository(); var service = new OrderService(repo); This is suitable for small or simple applications, though not scalable for large apps. Yes, DI can be implemented manually without using a DI container. You simply pass dependencies through constructors or methods: public class OrderService { private readonly IOrderRepository _repo; public OrderService(IOrderRepository repo)

Example code

{
_repo = repo;
}
} // Manual injection var repo = new OrderRepository();
var service = new OrderService(repo); This is suitable for small or simple applications, though not scalable for large apps.

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: Over-injection (too many dependencies in one class – violates SRP) Service locator anti-pattern Incorrect lifetimes, leading to memory leaks or unintended reuse Tight coupling to the DI container (e.g., using container APIs in business logic) Circular dependencies due to poor design Registering services in the wrong order or not at all

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: Inversion of Control (IoC) is a broader principle where control over object creation and dependency resolution is transferred from the class itself to an external framework or container. Dependency Injection is a specific implementation of IoC, where the dependencies are injected into a class rather than the class creating them internally. So, DI is one way to achieve IoC. Single Responsibility Principle (SRP)

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: 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: 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: 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: 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: 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: 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: The Unit of Work coordinates multiple Repositories and commits changes in a single transaction. For example: public interface IUnitOfWork : IDisposable

Example code

{ IProductRepository Products { get; } IOrderRepository Orders { get; } int Complete();
}
public class UnitOfWork : IUnitOfWork
{
private readonly DbContext _context;
public IProductRepository Products { get; }
public IOrderRepository Orders { get; }
public UnitOfWork(DbContext context)
{
_context = context;
Products = new ProductRepository(_context);
Orders = new OrderRepository(_context);
}
public int Complete() => _context.SaveChanges();
public void Dispose() => _context.Dispose();
} This ensures atomic commits across repositories.

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: Testing singletons/statics is tricky due to global state. Best practices include: Refactor to use interfaces and DI instead of static/singletons. Wrap static calls behind interfaces so you can mock them. Use specialized mocking tools (e.g., Microsoft Fakes) if refactoring isn't possible. Avoid static state to improve testability.

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: Define a common interface, e.g., IPaymentStrategy with a method Pay(). Implement concrete strategies for each payment method (CreditCard, PayPal, etc.). Use a context class to invoke the selected strategy at runtime, enabling easy extension without modifying existing 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.