Interview Q&A

Short answer: Transactional consistency: All changes across repositories are saved in a single transaction.

Explain a bit more

Centralized commit: All changes are committed through one method (Complete()), improving control and readability. Reduced code duplication: Prevents repeated save logic across repositories. Improved testability: Enables better unit testing by mocking a single Unit of Work instead of multiple repositories. Change tracking: Ensures that only modified entities are persisted, reducing unnecessary database operations.

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, combining Unit of Work with Dependency Injection (DI) is a best practice in modern .NET applications. DI allows the Unit of Work to be injected into services or controllers, managing its lifecycle effectively. This improves modularity, promotes loose coupling, and makes the application easier to maintain and test. Example using constructor injection in a service: public class OrderService

Example code

{
private readonly IUnitOfWork _unitOfWork;
public OrderService(IUnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
}
public void PlaceOrder(Order order)
{ _unitOfWork.Orders.Add(order); _unitOfWork.Complete(); }
} Dependency Injection (DI)

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: .NET Core has a built-in DI container that's tightly integrated into the framework. When you create a new ASP.NET Core project, DI is configured automatically and used in controllers, middleware, services, etc. You register dependencies in the Program.cs or Startup.cs file using IServiceCollection.

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: Services are registered in the Program.cs or Startup.cs file using the IServiceCollection interface.

Example code

builder.Services.AddTransient<IProductService, ProductService>(); builder.Services.AddScoped<IOrderService, OrderService>(); builder.Services.AddSingleton<ILoggingService, LoggingService>();

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: Circular dependencies occur when two or more services depend on each other, creating an infinite loop. To handle them: Refactor the code to remove tight coupling. Use interfaces or events to break the cycle. Consider using property injection carefully (not recommended as a first choice). Rethink your design – circular dependencies often indicate architectural 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: Easier mocking of dependencies using frameworks like Moq or NSubstitute. No need to instantiate real implementations (e.g., database access) for tests. Improved isolation of the unit under test. Faster, more reliable tests due to lack of external dependency reliance.

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: 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: 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: 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.