Master technical and career interviews with structured answers—short definition, real examples, pitfalls, and how to answer in 60–90 seconds.
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; } IO…
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. Us…
Short answer: And why? The Mediator Pattern centralizes communication between components, preventing direct dependencies and reducing complexity. It promotes loose coupling and simplifies interactions. Alternatively, the…
Short answer: The Mediator Pattern centralizes communication between components, preventing direct dependencies and reducing complexity. It promotes loose coupling and simplifies interactions. Alternatively, the Observer…
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 a…
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 en…
Short answer: Identify classes violating SRP and break them down. Introduce abstractions and interfaces to decouple components (DIP). Replace conditional logic with polymorphism to respect OCP. Split large interfaces (IS…
Short answer: Use AOP (Aspect-Oriented Programming) techniques or design patterns like Decorator to separate cross-cutting concerns from business logic. In .NET, middleware, filters, or interceptors can manage concerns l…
Short answer: DI containers use reflection to inspect constructors of requested services, resolve dependencies recursively from their registrations, apply lifecycle scopes (Singleton, Scoped, Transient), and build the fu…
Short answer: Define plugin contracts with interfaces (DIP). Load plugins dynamically using reflection or MEF. Use DI to inject dependencies into plugins. Ensure plugins follow SRP with focused responsibilities. Use Fact…
Short answer: ASP.NET Core MVC has built-in support for Dependency Injection. Explain a bit more Register services in Startup.cs within ConfigureServices method using IServiceCollection: public void ConfigureServices(ISe…
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 res…
Short answer: Register DbContext with DI in Startup.cs: services.AddDbContext<AppDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConne ction"))); Implement Reposito…
Short answer: Use mocking libraries like Moq, NSubstitute, or FakeItEasy. Create mocks of interfaces and inject them into the class under test: var mockRepo = new Mock<IProductRepository>(); mockRepo.Setup(repo =&g…
Short answer: Chain of Responsibility: Middleware components form a pipeline where each decides to pass control or handle the request. Decorator: Middleware wraps around the next component, adding behavior before or afte…
Short answer: Define a caching interface: public interface ICacheStrategy { void Cache(string key, object value); object Retrieve(string key); } Implement strategies like MemoryCacheStrategy, DistributedCacheStrategy. Us…
Short answer: Abstract Factory: Provides an interface for creating families of related objects without specifying concrete classes. Example code Creating UI components for different OS (Windows, Mac). Builder: Focuses on…
Short answer: Apply Single Responsibility Principle (SRP) by splitting responsibilities into smaller classes. Use composition instead of inheritance to delegate behavior. Extract business logic into services or helpers.…
Short answer: Resharper: Provides code analysis and refactoring hints. SonarQube / SonarCloud: Analyzes code quality and reports SOLID violations. FxCop / Roslyn analyzers: Provide static analysis with custom rules. NDep…
Short answer: Mediator decouples components by centralizing communication, supporting SRP and DIP by reducing direct dependencies. It fits DI because the mediator itself can be injected where needed. It supports OCP by a…
Short answer: In a recent project, we had a monolithic service class handling multiple responsibilities, making it hard to maintain and extend. Explain a bit more By applying Single Responsibility Principle (SRP), we spl…
Short answer: Applications? Yes. In one project, a singleton was used without thread safety, causing race conditions when accessed concurrently. This led to inconsistent state and application crashes. We resolved it by i…
Short answer: Yes. In one project, a singleton was used without thread safety, causing race conditions when accessed concurrently. This led to inconsistent state and application crashes. We resolved it by implementing th…
Short answer: I prioritize YAGNI (You Aren’t Gonna Need It) to avoid over-engineering. Explain a bit more SOLID principles guide design for flexibility and maintainability, but I apply them pragmatically: start with simp…
Short answer: Challenges include: Legacy code with tight coupling, making decomposition hard. Risk of introducing bugs while splitting responsibilities or introducing abstractions. Managing dependencies and lifetimes cor…
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: The Unit of Work coordinates multiple Repositories and commits changes in a single transaction. For example: public interface IUnitOfWork : IDisposable
{ 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.
Design Patterns & SOLID Design Patterns in C# · SOLID
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.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: And why? The Mediator Pattern centralizes communication between components, preventing direct dependencies and reducing complexity. It promotes loose coupling and simplifies interactions. Alternatively, the Observer Pattern enables event-driven decoupling, and Facade Pattern provides a simplified interface to complex subsystems. Real-world… example…… (ShopNest) Patterns in ShopNest should solve a real pain…
(swappable payments, test seams)—not be added for decoration.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: The Mediator Pattern centralizes communication between components, preventing direct dependencies and reducing complexity. It promotes loose coupling and simplifies interactions. Alternatively, the Observer Pattern enables event-driven decoupling, and Facade Pattern provides a simplified interface to complex subsystems.
Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.
Design Patterns & SOLID Design Patterns in C# · SOLID
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.
Design Patterns & SOLID Design Patterns in C# · SOLID
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.
ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Identify classes violating SRP and break them down. Introduce abstractions and interfaces to decouple components (DIP). Replace conditional logic with polymorphism to respect OCP. Split large interfaces (ISP). Check inheritance hierarchies to maintain LSP. Inject dependencies instead of direct instantiation. Incrementally refactor with unit tests to ensure behavior remains consistent.
Open/Closed in ShopNest: add a new payment method by adding a class, not by editing a giant switch in CheckoutService.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Use AOP (Aspect-Oriented Programming) techniques or design patterns like Decorator to separate cross-cutting concerns from business logic. In .NET, middleware, filters, or interceptors can manage concerns like logging or authorization, keeping SRP intact.
Open/Closed in ShopNest: add a new payment method by adding a class, not by editing a giant switch in CheckoutService.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: DI containers use reflection to inspect constructors of requested services, resolve dependencies recursively from their registrations, apply lifecycle scopes (Singleton, Scoped, Transient), and build the full object graph to return fully constructed instances.
Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Define plugin contracts with interfaces (DIP). Load plugins dynamically using reflection or MEF. Use DI to inject dependencies into plugins. Ensure plugins follow SRP with focused responsibilities. Use Factory or Strategy patterns to instantiate plugins. Keep core system closed for modification but open for extension (OCP). Separate cross-cutting concerns externally. Practical .NET Questions
Open/Closed in ShopNest: add a new payment method by adding a class, not by editing a giant switch in CheckoutService.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: ASP.NET Core MVC has built-in support for Dependency Injection.
Register services in Startup.cs within ConfigureServices method using IServiceCollection: public void ConfigureServices(IServiceCollection services) { services.AddControllersWithViews(); services.AddScoped<IProductService, ProductService>(); // Example } Inject dependencies via constructor injection in controllers or services: public class HomeController : Controller
{
private readonly IProductService _productService;
public HomeController(IProductService productService)
{
_productService = productService;
}
public IActionResult Index()
{
var products = _productService.GetAll();
return View(products);
}
} The framework resolves and injects dependencies automatically.
Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.
Design Patterns & SOLID Design Patterns in C# · SOLID
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.
Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Register DbContext with DI in Startup.cs: services.AddDbContext<AppDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConne ction"))); Implement Repositories for entities injecting AppDbContext. Implement Unit of Work which holds multiple repositories and calls SaveChanges() on the DbContext: public interface IUnitOfWork : IDisposable
{ IProductRepository Products { get; } int Complete();
}
public class UnitOfWork : IUnitOfWork
{
private readonly AppDbContext _context;
public IProductRepository Products { get; private set; }
public UnitOfWork(AppDbContext context)
{
_context = context;
Products = new ProductRepository(_context);
}
public int Complete() => _context.SaveChanges();
public void Dispose() => _context.Dispose();
} Register UnitOfWork in DI container as Scoped.
ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Use mocking libraries like Moq, NSubstitute, or FakeItEasy. Create mocks of interfaces and inject them into the class under test: var mockRepo = new Mock<IProductRepository>(); mockRepo.Setup(repo => repo.GetAll()).Returns(new List<Product> { ... }); var service = new ProductService(mockRepo.Object); // Act & Assert This allows testing in isolation without hitting real databases or external services.
Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Chain of Responsibility: Middleware components form a pipeline where each decides to pass control or handle the request. Decorator: Middleware wraps around the next component, adding behavior before or after. Factory: Middleware components can be created via factories for configurable pipeline setup.
Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Define a caching interface: public interface ICacheStrategy { void Cache(string key, object value); object Retrieve(string key); } Implement strategies like MemoryCacheStrategy, DistributedCacheStrategy. Use DI or factory to inject the chosen strategy at runtime: public class CacheContext
{
private readonly ICacheStrategy _cacheStrategy;
public CacheContext(ICacheStrategy cacheStrategy)
{
_cacheStrategy = cacheStrategy;
}
public void Cache(string key, object value) => _cacheStrategy.Cache(key, value); } This enables switching caching mechanisms without code changes.
ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Abstract Factory: Provides an interface for creating families of related objects without specifying concrete classes.
Creating UI components for different OS (Windows, Mac). Builder: Focuses on step-by-step construction of a complex object, allowing different representations. Example: Building a complex House with various parts (walls, doors, roof). Summary: Abstract Factory is about families of products, Builder is about complex construction process.
ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Apply Single Responsibility Principle (SRP) by splitting responsibilities into smaller classes. Use composition instead of inheritance to delegate behavior. Extract business logic into services or helpers. Introduce abstractions to isolate concerns. Continuously refactor large classes and add unit tests.
Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Resharper: Provides code analysis and refactoring hints. SonarQube / SonarCloud: Analyzes code quality and reports SOLID violations. FxCop / Roslyn analyzers: Provide static analysis with custom rules. NDepend: Deep architecture and dependency analysis tool. StyleCop: Enforces coding style which indirectly helps maintain SOLID code.
Open/Closed in ShopNest: add a new payment method by adding a class, not by editing a giant switch in CheckoutService.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Mediator decouples components by centralizing communication, supporting SRP and DIP by reducing direct dependencies. It fits DI because the mediator itself can be injected where needed. It supports OCP by allowing new communication routes or handlers without modifying existing components. Helps avoid tight coupling in complex workflows or CQRS patterns. Behavioral / Conceptual Questions
Open/Closed in ShopNest: add a new payment method by adding a class, not by editing a giant switch in CheckoutService.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: In a recent project, we had a monolithic service class handling multiple responsibilities, making it hard to maintain and extend.
By applying Single Responsibility Principle (SRP), we split the class into focused services, each with a clear purpose. This drastically improved readability, reduced bugs, and made it easier to add new features without risking regressions. The project became more testable because each small class could be unit tested independently.
Open/Closed in ShopNest: add a new payment method by adding a class, not by editing a giant switch in CheckoutService.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Applications? Yes. In one project, a singleton was used without thread safety, causing race conditions when accessed concurrently. This led to inconsistent state and application crashes. We resolved it by implementing thread-safe lazy initialization using Lazy<T> in .NET, ensuring the singleton instance was created safely once, even under heavy… parallel…
ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Yes. In one project, a singleton was used without thread safety, causing race conditions when accessed concurrently. This led to inconsistent state and application crashes. We resolved it by implementing thread-safe lazy initialization using Lazy<T> in .NET, ensuring the singleton instance was created safely once, even under heavy parallel access.
ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: I prioritize YAGNI (You Aren’t Gonna Need It) to avoid over-engineering.
SOLID principles guide design for flexibility and maintainability, but I apply them pragmatically: start with simple solutions and refactor as requirements evolve. Writing tests early helps identify pain points justifying additional abstractions. Communication with the team ensures we don’t add complexity prematurely but keep the codebase adaptable.
Patterns in ShopNest should solve a real pain (swappable payments, test seams)—not be added for decoration.
Design Patterns & SOLID Design Patterns in C# · SOLID
Short answer: Challenges include: Legacy code with tight coupling, making decomposition hard. Risk of introducing bugs while splitting responsibilities or introducing abstractions. Managing dependencies and lifetimes correctly when injecting dependencies. Convincing stakeholders that refactoring time is valuable. Balancing between adhering strictly to SOLID vs. keeping code understandable and performant.
Open/Closed in ShopNest: add a new payment method by adding a class, not by editing a giant switch in CheckoutService.