Interview Q&A

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

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

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

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

• 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

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.

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.

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.

I use a combination of:

• Simple examples showing before/after code refactoring.
• Pair programming sessions to explain thought processes.
• Encouraging reading and discussing classic books like “Clean Code” and “Design

Patterns”.

• Practical coding exercises and code reviews focused on SOLID principles.
• Showing real project scenarios where principles improved code quality and

maintainability.

• Promoting a culture of continuous learning and curiosity.

Bonus / Miscellaneous

• Inheritance creates an “is-a” relationship, where a subclass inherits behavior and

properties from a parent class. It can lead to tight coupling and fragile hierarchies if

overused.

• Composition creates a “has-a” relationship, where a class contains instances of

other classes and delegates behavior to them. It’s more flexible and promotes loose

coupling.

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

Answer: Adapter converts the interface of a class into another interface clients expect, allowing incompatible interfaces to work together. It promotes Open/Closed Principle (OCP) by enabling new integrations without modifying existing code.

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: Use the Proxy or Virtual Proxy pattern where a placeholder object controls access to the real object and defers its creation until needed. In .NET, Lazy&lt;T&gt; provides built-in lazy loading.

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.

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

SOLID promotes small, single-responsibility services (SRP), clear interfaces (ISP), loose

coupling (DIP), and extendable design (OCP). This aligns well with microservices by

encouraging modular, maintainable, and testable service boundaries.

Answer: The Command Pattern encapsulates requests as objects, allowing operations to be stored, undone, or redone by maintaining command history.

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

• Cohesion: Degree to which elements of a module belong together. High cohesion

means focused, well-defined responsibilities.

• Coupling: Degree of interdependence between modules. Low coupling means

modules are independent and changes in one don’t affect others.

Answer: Use API contracts and versioning. Employ service discovery and load balancing. Prefer asynchronous messaging/event-driven architecture to reduce tight coupling. Apply circuit breakers and retries for fault tolerance.

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.