Top 9 Senior Interview Questions

S — Single Responsibility

One class, one reason to change.

// BAD: PaymentService validates, saves, AND sends email
class PaymentService {
    void process(Payment p) { validate(p); save(p); sendEmail(p); }
}

// GOOD: each class has one job
class PaymentValidator  { void validate(Payment p) { ... } }
class PaymentRepository { void save(Payment p)     { ... } }
class PaymentNotifier   { void notify(Payment p)   { ... } }

O — Open/Closed

Open for extension, closed for modification. Add behaviour without changing existing code.

// BAD: adding a new payment type means editing this switch
double getFee(Payment p) {
    switch (p.getType()) {
        case WIRE: return 15.0;
        case ACH:  return 0.5;
    }
}

// GOOD: add new FeeStrategy without touching existing code
interface FeeStrategy { double getFee(Payment p); }
class WireFeeStrategy implements FeeStrategy { ... }
class CryptoFeeStrategy implements FeeStrategy { ... } // new type — no changes elsewhere

L — Liskov Substitution

A subtype must be substitutable for its parent without breaking the program.

// VIOLATION: ReadOnlyAccount extends Account but throws on withdraw()
// Callers who expect Account.withdraw() to work will break.
// Fix: don't extend — use a separate interface or composition.

I — Interface Segregation

Don't force clients to depend on methods they don't use.

// BAD: one fat interface
interface AccountOperations {
    void deposit(); void withdraw(); void generateReport(); void auditLog();
}

// GOOD: split by client need
interface Transactional { void deposit(); void withdraw(); }
interface Reportable    { void generateReport(); }
interface Auditable     { void auditLog(); }

D — Dependency Inversion

Depend on abstractions, not concretions. High-level modules shouldn't depend on low-level modules.

// BAD: PaymentService directly depends on EmailService (concrete)
class PaymentService {
    private final EmailService email = new EmailService(); // hard-coded
}

// GOOD: depends on abstraction, injected by Spring
class PaymentService {
    private final NotificationSender sender; // interface — swap email/SMS/push freely
    public PaymentService(NotificationSender sender) { this.sender = sender; }
}

Intent

Define a family of algorithms, encapsulate each, and make them interchangeable at runtime. Eliminates if/else or switch chains based on type.

Implementation

interface FeeStrategy {
    BigDecimal calculate(Transaction txn);
}

class StandardFee  implements FeeStrategy { ... }   // 1.5%
class PremiumFee   implements FeeStrategy { ... }   // 0.5%
class InternationalFee implements FeeStrategy { ... } // 3% + FX markup

@Service
class TransactionService {
    private final Map<CustomerTier, FeeStrategy> strategies;

    public BigDecimal process(Transaction txn, CustomerTier tier) {
        return strategies.get(tier).calculate(txn); // no if/else — just a map lookup
    }
}

When to use vs when not to

• Use: behaviour varies by type/config at runtime, you're adding new variants frequently.
• Don't use: only 2 variants that never change — it's over-engineering. A simple conditional is clearer.

Factory Method

Defines an interface for creating one type of object. Subclasses decide which class to instantiate.

abstract class PaymentProcessorFactory {
    public abstract PaymentProcessor create();  // subclass decides
}

class StripeProcessorFactory extends PaymentProcessorFactory {
    public PaymentProcessor create() { return new StripeProcessor(apiKey); }
}

Simple static factory (most common in Java)

class PaymentProcessorFactory {
    public static PaymentProcessor create(PaymentType type) {
        return switch (type) {
            case STRIPE -> new StripeProcessor(config);
            case PAYPAL -> new PaypalProcessor(config);
            case WIRE   -> new WireTransferProcessor(config);
        };
    }
}

Abstract Factory

Creates families of related objects. Ensures objects from the same family are used together.

interface PaymentInfraFactory {
    PaymentGateway gateway();
    FraudChecker fraudChecker();
    NotificationSender notifier();
}

class EUPaymentFactory     implements PaymentInfraFactory { ... } // SEPA, EU fraud rules
class USPaymentFactory     implements PaymentInfraFactory { ... } // ACH, US fraud rules
class SandboxPaymentFactory implements PaymentInfraFactory { ... } // mocks for testing

Intent

Subject notifies multiple observers when its state changes. Observers don't know about each other. Subject doesn't know observer details — loose coupling.

Spring ApplicationEvents (in-process)

// 1. Define the event
public record OrderPlacedEvent(Order order) {}

// 2. Publish from the service
@Service
class OrderService {
    @Autowired ApplicationEventPublisher publisher;

    @Transactional
    public void placeOrder(Order order) {
        orderRepo.save(order);
        publisher.publishEvent(new OrderPlacedEvent(order));  // same transaction!
    }
}

// 3. Multiple independent listeners
@Component class NotificationListener {
    @EventListener
    public void onOrder(OrderPlacedEvent e) { notifier.send(e.order()); }
}

@Component class InventoryListener {
    @TransactionalEventListener(phase = AFTER_COMMIT) // fires only if TX commits
    public void onOrder(OrderPlacedEvent e) { inventory.reserve(e.order()); }
}

@TransactionalEventListener — the important detail

• @EventListener: fires immediately, inside the same transaction. If transaction rolls back, the listener has already run.
• @TransactionalEventListener(AFTER_COMMIT): fires only after the transaction successfully commits. Safe for sending emails, calling external APIs, publishing to Kafka.

Scaling to distributed: Kafka

Same pattern, different scope. In-process events → Spring ApplicationEvents. Cross-service events → Kafka topics. Kafka is the Observer pattern at microservice scale: producers publish events, multiple consumer groups subscribe independently.

Intent

Attach additional responsibilities to an object dynamically by wrapping it. Alternative to subclassing — behaviours compose rather than inherit.

Implementation

interface OrderProcessor {
    OrderResult process(Order order);
}

class CoreOrderProcessor implements OrderProcessor {
    public OrderResult process(Order order) { /* core logic */ }
}

class LoggingDecorator implements OrderProcessor {
    private final OrderProcessor delegate;
    public OrderResult process(Order order) {
        log.info("Processing order {}", order.getId());
        OrderResult result = delegate.process(order);
        log.info("Done in {}ms", elapsed);
        return result;
    }
}

class FraudCheckDecorator implements OrderProcessor {
    public OrderResult process(Order order) {
        fraudService.check(order);    // throws if fraud detected
        return delegate.process(order);
    }
}

// Compose: fraud check → logging → core
OrderProcessor processor = new LoggingDecorator(
                              new FraudCheckDecorator(
                                  new CoreOrderProcessor()));

Decorator vs Inheritance

• Inheritance: fixed at compile time. LoggedFraudCheckedOrderProcessor — class explosion with many combinations.
• Decorator: composed at runtime. Mix and match behaviours. Add/remove without modifying classes.

Real examples you can cite in interviews

Java I/O — the canonical example:

// Each layer wraps the next — Decorator in action:
Reader reader = new BufferedReader(          // adds buffering
                  new InputStreamReader(      // converts bytes → chars
                    new FileInputStream("data.txt")));  // raw bytes

// All three implement the same Reader interface.
// BufferedReader doesn't know if it wraps a file, network, or in-memory source.
// Add GZIPInputStream in the middle for transparent decompression — zero changes elsewhere.

Spring Security filter chain: Spring Security's filter chain is a Decorator chain at HTTP level. Each filter wraps the next and adds one concern:

// Conceptually (simplified):
// SecurityContextFilter → wraps →
//   CsrfFilter → wraps →
//     BearerTokenFilter → wraps →
//       AuthorizationFilter → wraps →
//         DispatcherServlet (the core)

// Your filter chain config IS a Decorator composition:
return http
    .csrf(csrf -> csrf.disable())            // remove CsrfFilter from chain
    .addFilterBefore(jwtFilter, BearerTokenAuthenticationFilter.class)  // insert new decorator
    .build();

This is why "adding security" in Spring doesn't require modifying controllers — you add decorators around them.

Problem it solves

Constructor with many parameters is error-prone (easy to swap args of same type), hard to read, and forces you to pass nulls for optional fields.

// HARD to read: what do these booleans mean?
new Order("ORD-1", customerId, items, address, true, false, null, priority);

Builder implementation

Order order = Order.builder()
    .id("ORD-1")
    .customerId(customerId)
    .items(items)
    .shippingAddress(address)
    .expressDelivery(true)
    .priority(Priority.HIGH)
    .build();  // validate required fields here, throw if missing

When to use

• Object has 4+ parameters, especially with optional ones.
• You want immutable objects (all fields set before construction, no setters).
• Multiple valid configurations of the same class.

When it's overkill

• 2–3 parameters, all required → constructor is cleaner.
• Mutable objects with setters → just use setters.

The idea

Core business logic sits at the centre, isolated from external concerns (DB, HTTP, Kafka, external APIs). The domain defines ports (interfaces for what it needs). External systems plug in via adapters (implementations of those interfaces).

Folder structure

src/
  domain/
    model/          Order, Customer, Payment    // pure business objects
    port/
      in/           OrderService (interface)    // what drives the domain
      out/          OrderRepository, PaymentGateway  // what domain needs
    service/        OrderServiceImpl            // business logic — no frameworks

  adapter/
    in/
      web/          OrderController             // REST → calls domain port
      kafka/        OrderEventConsumer          // Kafka → calls domain port
    out/
      persistence/  JpaOrderRepository          // implements domain's out port
      external/     StripePaymentAdapter        // implements PaymentGateway

Key benefit

• Test business logic with zero infrastructure — just instantiate the domain service with mock ports.
• Swap DB (PostgreSQL → MongoDB), or messaging (Kafka → RabbitMQ) without touching domain logic.
• Domain code has no Spring, JPA, or Kafka imports — it's pure Java.

vs Layered Architecture

CQRS — Command Query Responsibility Segregation

Separate the write model from the read model.

// Write side: normalised, ACID, strongly consistent
orderCommandService.placeOrder(command);   // writes to orders DB

// Read side: denormalised, optimised for queries, eventually consistent
orderQueryService.getOrderSummary(id);     // reads from read-optimised view

Sync between them via events (Kafka). Write side publishes OrderPlaced → read side updates its projection.

Event Sourcing

Store all state changes as immutable events. Current state = replay all events from the beginning (or from a snapshot).

// Account event store:
AccountCreated    { accountId, ownerId, timestamp }
MoneyDeposited    { accountId, amount, timestamp }
MoneyWithdrawn    { accountId, amount, timestamp }
AccountFrozen     { accountId, reason, timestamp }

// Current balance = sum of all deposits - sum of all withdrawals
// Full audit trail is free — it's the source of truth.

When to use CQRS

• Read and write loads are dramatically different (heavy reads vs complex writes).
• You need multiple read models of the same data (dashboard, mobile, API).
• Microservices that need data from multiple domains in one query.

When NOT to use

• Simple CRUD — the complexity is not justified.
• When strong consistency is required for reads (users expect to see their write immediately).

The problem: distributed transactions don't work with 2PC

A traditional 2-Phase Commit (2PC) across microservices couples services to a distributed transaction coordinator. Services hold locks during the prepare phase, the coordinator is a single point of failure, and network partitions leave services in uncertainty. In practice, 2PC is almost never the right answer for microservices.

The Saga pattern replaces the distributed ACID transaction with a sequence of local transactions, each publishing an event or message that triggers the next step. If a step fails, the Saga executes compensating transactions to undo the completed steps.

Choreography Saga — event-driven, decentralized

Each service reacts to events from other services and publishes its own events. No central coordinator.

// Order service: creates order, publishes event
@Transactional
public Order placeOrder(OrderRequest req) {
    Order order = orderRepo.save(new Order(req, PENDING));
    eventBus.publish(new OrderCreatedEvent(order.getId(), req.items()));
    return order;
}

// Inventory service: listens, reserves stock
@KafkaListener(topics = "order.created")
public void onOrderCreated(OrderCreatedEvent event) {
    try {
        inventory.reserve(event.items());
        eventBus.publish(new StockReservedEvent(event.orderId()));
    } catch (InsufficientStockException e) {
        eventBus.publish(new StockReservationFailedEvent(event.orderId()));
    }
}

// Order service: listens for failure, compensates
@KafkaListener(topics = "stock.reservation.failed")
public void onStockFailed(StockReservationFailedEvent event) {
    orderRepo.updateStatus(event.orderId(), CANCELLED);  // compensate
    eventBus.publish(new OrderCancelledEvent(event.orderId()));
}

Orchestration Saga — central coordinator

A dedicated Saga Orchestrator (a stateful component or BPMN workflow engine) directs each step, decides what to do on failure, and explicitly manages compensation.

@Component
public class PlaceOrderSaga {  // could use Axon, Temporal, or custom state machine

    public void execute(OrderRequest req) {
        String orderId = orderService.createOrder(req);    // step 1
        try {
            inventory.reserve(orderId, req.items());          // step 2
            try {
                payment.charge(orderId, req.total());         // step 3
                orderService.confirm(orderId);                // step 4
            } catch (PaymentException e) {
                inventory.release(orderId);   // compensate step 2
                orderService.cancel(orderId); // compensate step 1
                throw e;
            }
        } catch (StockException e) {
            orderService.cancel(orderId);     // compensate step 1
            throw e;
        }
    }
}

Choreography vs Orchestration comparison

Critical Saga design rules

• Compensating transactions must be idempotent — a compensation may be triggered multiple times due to retries. Design compensations to be safe to run more than once.
• Not all operations can be compensated — sending an email is irreversible. Use "countermeasures" (send a follow-up email). Design these cases upfront.
• Sagas provide eventual consistency, not isolation — another transaction can see intermediate state (a reserved but not yet paid order). Use semantic locking (mark entities as "PENDING") to prevent concurrent Sagas from interfering.
• The Outbox Pattern prevents dual-write — the local DB write and the event publish must be atomic. Save the event to an outbox table in the same local transaction; a relay process publishes it to Kafka. This is the standard Saga reliability pattern.

// Outbox table — same transaction as the business write
@Transactional
public void createOrder(Order order) {
    orderRepo.save(order);
    outboxRepo.save(new OutboxEvent(
        "order.created",
        JSON.serialize(new OrderCreatedEvent(order.getId()))
    ));
    // Relay process (Debezium or polling) publishes outbox rows to Kafka
}