Interview Q&A

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.

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

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

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

• Abstract Factory: Provides an interface for creating families of related objects

without specifying concrete classes.

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

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

pplications?

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.

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.

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.

• Decorator adds additional responsibilities to objects dynamically without altering

their interface. It wraps the original object to extend behavior.

• Proxy controls access to an object, possibly adding lazy initialization, access control,

or logging, without changing its interface.

• Service Locator anti-pattern: Hides dependencies instead of injecting them

explicitly.

• Overusing Singleton: Leads to hidden global state and testing difficulties.
• Improper Singleton thread safety: Causes race conditions.
• Injecting concrete implementations: Violates DIP.

Template Method defines the skeleton of an algorithm in a base class, deferring some steps

to subclasses. It allows subclasses to redefine parts of the algorithm without changing its

structure. It supports OCP by enabling extensions through inheritance.

Answer: Use interfaces and abstractions (DIP). Apply Dependency Injection. Modularize code into bounded contexts or separate projects. Use events or messaging for decoupled communication. Avoid static state and global variables.

What interviewers expect

• A clear definition tied to SOLID in Design Patterns & SOLID projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Design Patterns & SOLID application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Design Patterns & SOLID architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: Encapsulates a request as an object with methods to execute and possibly undo the operation. The invoker calls commands without knowing the action details, supporting decoupling and flexible request handling.

What interviewers expect

• A clear definition tied to SOLID in Design Patterns & SOLID projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Design Patterns & SOLID application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Design Patterns & SOLID architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Builder separates complex object construction from its representation. For example, building

n HttpRequest with optional headers, query params, and body:

public class HttpRequestBuilder
{
private HttpRequestMessage _request = new HttpRequestMessage();
public HttpRequestBuilder SetMethod(HttpMethod method)
{
_request.Method = method;
return this;
}
public HttpRequestBuilder AddHeader(string key, string value)
{

_request.Headers.Add(key, value);

return this;
}
public HttpRequestMessage Build() => _request;
}

llows building requests step-by-step fluently.