Interview Q&A

Short answer: The Singleton pattern ensures a class has only one instance and provides a global point of access to it. It’s commonly used when exactly one object is needed to coordinate actions across the system, such as configuration settings, logging, or caching.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: One common thread-safe implementation uses lazy initialization with Lazy<T>: public sealed class Singleton

Example code

{
private static readonly Lazy<Singleton> instance = new
Lazy<Singleton>(() => new Singleton());
private Singleton() { }
public static Singleton Instance => instance.Value;
} This approach ensures thread safety and lazy initialization without locks.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: Global state: Singleton can lead to hidden dependencies and make testing difficult. Tight coupling: Other classes depend on the Singleton instance, reducing flexibility. Concurrency issues: If not implemented thread-safe, it can cause race conditions. Resource contention: Singleton might become a bottleneck if overused in concurrent environments.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: Singletons can hinder unit testing because they introduce global state, making tests dependent on a shared instance. This can cause tests to be flaky or order-dependent. To mitigate this, use interfaces and dependency injection, or design the Singleton to allow resetting its state for tests.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: Eager Initialization: The Singleton instance is created at the time of class loading. It's simple but can waste resources if the instance is never used. Lazy Initialization: The instance is created only when it is first accessed. It saves resources but requires careful implementation for thread safety. Factory pattern Q&A

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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 Factory pattern is a creational design pattern that provides an interface for creating objects but allows subclasses or implementations to decide which class to instantiate.

Explain a bit more

It’s used to encapsulate object creation, promoting loose coupling and flexibility when the exact types of objects aren’t known until runtime. Use case: When a class can’t anticipate the class of objects it needs to create, or when you want to delegate responsibility for object creation to subclasses.

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: Factory Method: Defines an interface for creating an object but lets subclasses decide which class to instantiate. It uses inheritance and relies on subclass overriding. Abstract Factory: Provides an interface to create families of related or dependent objects without specifying their concrete classes. It uses composition and is useful when you need to create multiple related objects together.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: A simple example of Factory Method: // Product interface public interface IAnimal

Example code

{ void Speak(); } // Concrete Products public class Dog : IAnimal
{
public void Speak() => Console.WriteLine("Woof");
}
public class Cat : IAnimal
{
public void Speak() => Console.WriteLine("Meow");
} // Factory public class AnimalFactory
{
public static IAnimal CreateAnimal(string animalType)
{
return animalType.ToLower() switch
{ "dog" => new Dog(), "cat" => new Cat(), _ => throw new ArgumentException("Invalid animal type") }; }
} Usage: var dog = AnimalFactory.CreateAnimal("dog"); dog.Speak(); // Outputs: Woof

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: Encapsulates object creation: Decouples client code from concrete classes. Promotes code reuse: Centralizes object creation logic. Enhances maintainability: Adding new types requires minimal changes to existing code. Supports polymorphism: Clients work with interfaces or base classes rather than concrete types. Improves testability: Can easily mock or swap factory implementations.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: Provide example. Yes! Factory pattern can complement Dependency Injection (DI) by abstracting complex object creation logic, especially when the creation involves runtime parameters or complex setup that DI containers can’t handle easily. Example: Imagine a service that needs different data repositories based on a runtime parameter. public interface IRepository { void Save(); }

Example code

public class SqlRepository : IRepository { public void Save() => Console.WriteLine("Saving to SQL DB"); } public class InMemoryRepository : IRepository { public void Save()
=> Console.WriteLine("Saving in Memory"); }
public interface IRepositoryFactory
{ IRepository CreateRepository(string repoType); }
public class RepositoryFactory : IRepositoryFactory
{
public IRepository CreateRepository(string repoType)
{
return repoType.ToLower() switch
{ "sql" => new SqlRepository(), "memory" => new InMemoryRepository(), _ => throw new ArgumentException("Invalid repository type") }; }
} // Consumer class with DI public class Service
{
private readonly IRepositoryFactory _repositoryFactory;
public Service(IRepositoryFactory repositoryFactory)
{
_repositoryFactory = repositoryFactory;
}
public void SaveData(string repoType)
{
var repo = _repositoryFactory.CreateRepository(repoType); repo.Save(); }
} Here, DI injects the IRepositoryFactory while the factory manages object creation based on runtime input. This promotes loose coupling and flexibility. Strategy Design Pattern

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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! Factory pattern can complement Dependency Injection (DI) by abstracting complex object creation logic, especially when the creation involves runtime parameters or complex setup that DI containers can’t handle easily. Example: Imagine a service that needs different data repositories based on a runtime parameter. public interface… IRepository { void……… Save(); } public class SqlRepository : IRepository { public…

Explain a bit more

void Save() => Console.WriteLine("Saving to SQL DB"); } public class InMemoryRepository : IRepository { public void Save() => Console.WriteLine("Saving in Memory"); } public interface IRepositoryFactory { IRepository CreateRepository(string repoType); } public class RepositoryFactory : IRepositoryFactory { public IRepository CreateRepository(string repoType) { return repoType.ToLower() switch { "sql" => new SqlRepository(), "memory" => new InMemoryRepository(), _ => throw new ArgumentException("Invalid repository type") }; } } // Consumer class with DI public class Service { private readonly… Yes! public class SqlRepository : IRepository { public void Save() => Console.WriteLine("Saving to SQL DB"); } public class InMemoryRepository : IRepository { public void Save()

Example code

=> Console.WriteLine("Saving in Memory"); }
public interface IRepositoryFactory
{ IRepository CreateRepository(string repoType); }
public class RepositoryFactory : IRepositoryFactory
{
public IRepository CreateRepository(string repoType)
{
return repoType.ToLower() switch
{ "sql" => new SqlRepository(), "memory" => new InMemoryRepository(), _ => throw new ArgumentException("Invalid repository type") }; }
} // Consumer class with DI public class Service
{
private readonly IRepositoryFactory _repositoryFactory;
public Service(IRepositoryFactory repositoryFactory)
{
_repositoryFactory = repositoryFactory;
}
public void SaveData(string repoType)
{
var repo = _repositoryFactory.CreateRepository(repoType); repo.Save(); }
} Here, DI injects the IRepositoryFactory while the factory manages object creation based on runtime input. This promotes loose coupling and flexibility. Strategy Design Pattern

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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 Strategy pattern is a behavioral design pattern that defines a family of algorithms, encapsulates each one, and makes them interchangeable at runtime. It allows the algorithm to vary independently from clients that use it. Problem it solves: Avoids large if-else or switch statements when selecting behavior and promotes flexibility by decoupling the algorithm from the client using it.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: Payment strategy selection // Strategy Interface public interface IPaymentStrategy

Example code

{ void Pay(decimal amount); } // Concrete Strategies public class CreditCardPayment : IPaymentStrategy
{
public void Pay(decimal amount) => Console.WriteLine($"Paid {amount} using Credit Card"); }
public class PayPalPayment : IPaymentStrategy
{
public void Pay(decimal amount) => Console.WriteLine($"Paid {amount} using PayPal"); } // Context public class PaymentContext
{
private IPaymentStrategy _paymentStrategy;
public PaymentContext(IPaymentStrategy paymentStrategy)
{
_paymentStrategy = paymentStrategy;
}
public void ExecutePayment(decimal amount)
{ _paymentStrategy.Pay(amount); }
} Usage: var context = new PaymentContext(new PayPalPayment()); context.ExecutePayment(200); // Outputs: Paid 200 using PayPal

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: Payment gateways (Credit Card, PayPal, UPI, etc.) Sorting algorithms (QuickSort, MergeSort, BubbleSort) Authentication strategies (OAuth, JWT, LDAP) Compression algorithms (ZIP, RAR, TAR) Loggers (FileLogger, ConsoleLogger, DatabaseLogger)

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: It promotes the Open/Closed Principle by allowing you to add new strategies (algorithms or behaviors) without modifying the existing code. The context class uses an interface for the strategy, so new behavior can be added just by creating a new class that implements the interface—no need to touch existing logic.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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 Strategy Pattern State Pattern Purpose Encapsulates interchangeable behaviors (algorithms).

Explain a bit more

Encapsulates states and transitions between them. Client Control Client decides which strategy to use. Object changes its own state internally. Behavior Switch Switched externally (e.g., passed as a parameter). Switched internally (e.g., via method call). Example Payment method selection. Document lifecycle (Draft → Published → Archived). Repository Design Pattern

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: Applications? The Repository pattern abstracts the data access layer from the business logic by providing collection-like interface to access domain objects. It helps keep data access logic centralized and makes the codebase easier to maintain, test, and swap out data sources (e.g., switching from EF Core to Dapper or an API). Say this in the… interview

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 Repository pattern abstracts the data access layer from the business logic by providing a collection-like interface to access domain objects. It helps keep data access logic centralized and makes the codebase easier to maintain, test, and swap out data sources (e.g., switching from EF Core to Dapper or an API).

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: Here's a basic example: // Entity public class Product

Example code

{
public int Id { get; set; }
public string Name { get; set; }
} // Generic Repository Interface public interface IRepository<T> where T : class
{ Task<IEnumerable<T>> GetAllAsync(); Task<T> GetByIdAsync(int id); Task AddAsync(T entity); void Update(T entity); void Delete(T entity); Task SaveAsync(); } // EF Core implementation public class Repository<T> : IRepository<T> where T : class
{
private readonly DbContext _context;
private readonly DbSet<T> _dbSet;
public Repository(DbContext context)
{
_context = context;
_dbSet = context.Set<T>();
}
public async Task<IEnumerable<T>> GetAllAsync() => await _dbSet.ToListAsync(); public async Task<T> GetByIdAsync(int id) => await _dbSet.FindAsync(id); public async Task AddAsync(T entity) => await _dbSet.AddAsync(entity); public void Update(T entity) => _dbSet.Update(entity);
public void Delete(T entity) => _dbSet.Remove(entity);
public async Task SaveAsync() => await _context.SaveChangesAsync(); }

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: Separation of concerns between business and data access layers Improved testability (can mock repositories) Centralized query logic for maintainability Easier to switch persistence implementations Promotes cleaner and more organized code

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: Add custom methods in a specialized repository interface (e.g., IProductRepository) Use Specification pattern or LINQ expressions Inject DbContext into repository if needed for advanced queries Optionally, break out complex queries into Query objects or services public interface IProductRepository : IRepository<Product>

Example code

{ Task<IEnumerable<Product>> GetProductsWithLowStockAsync(int threshold); }

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-abstraction: Can add unnecessary complexity for simple apps. Duplication: May duplicate what EF Core already provides (since EF is already a repository/unit-of-work pattern). Hides EF Core features: May obscure advanced capabilities like eager loading or projections. Extra boilerplate: Especially with generic repositories, which may not add much value. Unit of Work

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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 pattern is a design pattern used to maintain a list of operations to be performed within a single transaction. It ensures that all operations either succeed or fail together, providing consistency and managing changes to multiple business objects during a transaction. It coordinates the writing out of changes and resolves potential concurrency 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: The Repository pattern abstracts the data access layer, providing a simplified interface to data operations. The Unit of Work pattern complements it by managing multiple repositories and ensuring that all changes made through these repositories are committed in a single transaction. This combination separates concerns, promotes clean architecture, and maintains transactional integrity across multiple operations.

Real-world example (ShopNest)

ShopNest payment fees use Strategy: IFeeCalculator with UPI/Card implementations chosen at runtime.

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: In a .NET application (especially using Entity Framework), the Unit of Work is typically implemented around the DbContext, as it already tracks changes and handles transactions. Here's a simplified example: // IUnitOfWork.cs public interface IUnitOfWork : IDisposable

Example code

{ IProductRepository Products { get; } ICustomerRepository Customers { get; } int Complete();
} // UnitOfWork.cs public class UnitOfWork : IUnitOfWork
{
private readonly AppDbContext _context;
public IProductRepository Products { get; private set; }
public ICustomerRepository Customers { get; private set; }
public UnitOfWork(AppDbContext context)
{
_context = context;
Products = new ProductRepository(_context);
Customers = new CustomerRepository(_context);
}
public int Complete()
{
return _context.SaveChanges(); // All changes in one transaction }
public void Dispose()
{ _context.Dispose(); }
} Then register it using Dependency Injection in Startup.cs or Program.cs: services.AddScoped<IUnitOfWork, UnitOfWork>();

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.