Java interview questions, with the answers worked out.

Java interviews lean on object-oriented design and the standard collections. Here’s one question on each.

Free question 1 (design): Interface or abstract class?

You’re building checkout for an online store. Customers can pay by credit card, debit card or gift card, and more methods will be added later. Would you use an interface or an abstract class? Show a sketch.

Model answer

Start with the difference:

• An interface says what a class can do. A class can implement many interfaces. Since Java 8, interfaces can have default methods, but they can’t hold instance fields.
• An abstract class can hold shared fields and code. A class can only extend one class.

Then the decision: “I’d make PaymentMethod an interface, because every payment type needs to do the same thing, pay, but they don’t share much data. Credit and debit cards do share data, like the last four digits, so I’d add an abstract class just for cards.”

public interface PaymentMethod {
    boolean pay(BigDecimal amount);

    default String receiptLabel() {
        return getClass().getSimpleName();
    }
}

public abstract class CardPayment implements PaymentMethod {
    protected final String lastFour;

    protected CardPayment(String lastFour) {
        this.lastFour = lastFour;
    }

    @Override
    public String receiptLabel() {
        return "Card ending " + lastFour;
    }
}

public class CreditCard extends CardPayment {
    public CreditCard(String lastFour) {
        super(lastFour);
    }

    @Override
    public boolean pay(BigDecimal amount) {
        // call the card processor here
        return true;
    }
}

public class GiftCard implements PaymentMethod {
    private BigDecimal balance;

    public GiftCard(BigDecimal balance) {
        this.balance = balance;
    }

    @Override
    public boolean pay(BigDecimal amount) {
        if (balance.compareTo(amount) < 0) return false;
        balance = balance.subtract(amount);
        return true;
    }
}

Points to say out loud:

• Checkout code only ever uses PaymentMethod, so adding a new method later means a new class, not changes to checkout.
• Money uses BigDecimal, not double, because double can’t store amounts like 0.10 exactly.
• If the gift card could be used by two checkouts at once, the balance update would need to be thread safe or handled in the database.

What interviewers listen for: you explain both options before choosing, your choice follows from the problem, and you spot details like BigDecimal.

Free question 2 (collections): Why do equals and hashCode have to agree?

You use a Point class as a key in a HashMap. You put new Point(1, 2) in the map, then call map.get(new Point(1, 2)) and get null. Why, and how do you fix it?

Model answer

Why: HashMap first uses hashCode() to pick a bucket, then equals() to find the match inside it. If Point doesn’t override them, Java uses the default versions, which compare object identity. Two separate Point(1, 2) objects then usually land in different buckets and are never equal, so get returns null.

The fix: override both, using the same fields.

public final class Point {
    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Point)) return false;
        Point p = (Point) o;
        return x == p.x && y == p.y;
    }

    @Override
    public int hashCode() {
        return Objects.hash(x, y);
    }
}

The rule to state: if two objects are equal, they must have the same hash code. Overriding equals without hashCode breaks HashMap and HashSet.

Extra points:

• Keys should be immutable. If you change a key’s fields after putting it in a map, its hash changes and the map can’t find it. That’s why the fields are final.
• On Java 16 or later, a record does this for you: public record Point(int x, int y) {} gets equals and hashCode based on both fields.

What interviewers listen for: you explain how HashMap uses both methods, you state the contract, and you mention immutability.