Which Design Patterns Do Java Interviews Expect?

The patterns that come up most are strategy, observer, factory, singleton, builder and template method. They come up because each of them solves a shape of problem that recurs: swapping behaviour at runtime, notifying many parties, creating objects of varying types, ensuring a single instance, building complex objects, and fixing the skeleton of an algorithm while varying its steps.

The strategy pattern replaces a conditional with a family of interchangeable implementations behind a common interface. The client holds a reference to the interface and delegates to it, so adding a new behaviour means adding a new class rather than editing the client.

public class Main {
    public static void main(String[] args) {
        PaymentService service = new PaymentService(new CardPayment());
        service.pay(100);

        service.setStrategy(new PayPalPayment());
        service.pay(200);

        service.setStrategy(new CryptoPayment());
        service.pay(300);
    }
}

interface PaymentStrategy {
    void pay(int amount);
}

class PaymentService {
    private PaymentStrategy strategy;

    PaymentService(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    void setStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    void pay(int amount) {
        strategy.pay(amount);
    }
}

class CardPayment implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("paid " + amount + " by card");
    }
}

class PayPalPayment implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("paid " + amount + " by paypal");
    }
}

class CryptoPayment implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("paid " + amount + " in crypto");
    }
}

The output shows the same client handling three different behaviours. The payment service never mentions cards, PayPal or crypto — it only knows the interface.

What makes it a good answer is naming the cost as well as the benefit. A strategy is more classes and more indirection, and the client still has to be told which strategy to use. If you find yourself with three strategies and no sign of more, the pattern is premature.

The observer pattern has one subject that keeps a list of observers and notifies them when something happens. The subject calls a method on each observer, and the observer decides what to do with the notification.

The JDK has several versions of this built in. The observer and observable classes are the old ones, and the observable class is deprecated because it has a design flaw: the notify methods are final and can only be called from inside the observable class itself, and every observer has to extend the abstract class rather than implement an interface. The better built-in is the listener mechanism — a component publishes an event and the container registers a listener — which is the same pattern with the naming reversed.

import java.util.ArrayList;
import java.util.List;
import java.util.function.Consumer;

public class Main {
    public static void main(String[] args) {
        NewsDesk desk = new NewsDesk();
        desk.subscribe(topic -> System.out.println("Alice read: " + topic));
        desk.subscribe(topic -> System.out.println("Bob read: " + topic));

        desk.publish("a major release is out");
    }
}

class NewsDesk {
    private final List<Consumer<String>> subscribers = new ArrayList<>();

    void subscribe(Consumer<String> subscriber) {
        subscribers.add(subscriber);
    }

    void publish(String topic) {
        for (Consumer<String> subscriber : subscribers) {
            subscriber.accept(topic);
        }
    }
}

The output shows both subscribers receiving the topic. Using a functional interface for the observer role keeps the implementation compact, and it is exactly the shape you would use for an event bus.

Two weaknesses of the naive pattern are worth naming in an interview. If a subscriber throws, the remaining subscribers never hear about it — so wrap each notification in a try and catch, or make the notification asynchronous. And a subscriber that unsubscribes during notification causes a concurrent modification error, because the list is being iterated while it changes — so copy the list before iterating, or use a concurrent collection.

Worth knowing properly, because they solve recurring problems and because interviewers ask about them. Strategy for swapping behaviour. Observer for one-to-many notification. Factory method and abstract factory for creating objects of varying types. Builder for objects with many optional parts. Singleton for exactly one instance, though with a caveat below. Template method for a fixed algorithm skeleton with varying steps. And adapter, which is the pattern the JDK uses extensively in its collection and IO APIs.

Usually not worth it, and worth being able to say why. Decorator, in the classic textbook form, is often just a wrapper class you could write more plainly. Flyweight is a genuine optimisation but only pays off with very many shared objects, and the string interning pool already covers the common case. Mediator tends to produce a god object. And Chain of responsibility is often clearer as a plain list of handlers that you loop over.

The singleton caveat is worth spelling out because it is a favourite interview trap. The pattern is easy to get wrong — the naive version is not thread safe, and the synchronised accessor has a performance cost — and in modern Java you rarely need it. A static final field gives you a thread-safe singleton with no ceremony, and for anything more complex a dependency injection container gives you the single instance without the global state. The honest answer is that singletons are easy to implement and easy to regret, because global state makes testing harder.