Java 8 Features Interview Questions and Answers

Why interviewers still ask about Java 8

Java 8 is the release that turned Java functional, and its features — lambdas, streams, Optional, the new date/time API — remain the shared vocabulary of every Java codebase since. Interviewers reach for it because it reliably separates people who write modern, declarative Java from those who translate old habits into new syntax. Even teams on Java 17 or 21 open with Java 8 questions, because everything newer builds on this foundation.

This page covers the Java 8 questions that recur across levels. Answer each by explaining the problem the feature solved, not just how to type it — that framing is what interviewers are grading.

How to answer Java 8 questions

For each feature, lead with the pain it removed: lambdas killed anonymous-class boilerplate, Optional made absence a type, java.time fixed a mutable and error-prone date API. Then show idiomatic use. A candidate who says "default methods let interfaces evolve without breaking implementers" understands the design; one who only recites syntax does not.

Q1. What is a lambda expression and what type does it have?

A lambda is a concise way to implement a functional interface — a single-abstract-method interface — without an anonymous class. Its type is inferred from the target functional interface in context; a lambda has no type on its own.

Runnable r = () -> System.out.println("run");        // Runnable
Comparator<String> byLen = (a, b) -> a.length() - b.length();  // Comparator<String>

The key insight is that the same lambda text can be a Runnable, a Callable, or a custom interface depending on the target type — which is why lambdas are not objects of a fixed "lambda type." Also worth mentioning: a lambda captures effectively-final local variables, not a live reference, so it cannot mutate them.

Interview note: Trap: "the comparator subtracts lengths — any bug?" For lengths it is safe, but subtraction as comparison overflows for arbitrary ints; prefer Integer.compare(a, b).

Q2. What is a functional interface, and name the core ones.

A functional interface declares exactly one abstract method, making it a valid lambda target. The java.util.function package supplies the standard ones: Function<T,R> (transform), Predicate<T> (test), Supplier<T> (produce), Consumer<T> (accept), and BiFunction, UnaryOperator, etc.

@FunctionalInterface is an optional annotation that makes the compiler enforce the single-abstract-method rule — useful for interfaces you intend as lambda targets. Note that default and static methods do not count against the single-abstract-method limit.

Predicate<String> nonEmpty = s -> !s.isBlank();
Function<String, Integer> len = String::length;

Interview note: Follow-up: "is Comparator a functional interface? It has many methods." Yes — it has one abstract method (compare); the rest are default or static, which don't disqualify it.

Q3. What are method references and their four kinds?

A method reference (::) is shorthand for a lambda that just calls one existing method. The four kinds are: static (Integer::parseInt), bound instance (str::length on a specific object), unbound instance (String::length on the parameter), and constructor (ArrayList::new).

They read better than the equivalent lambda when the lambda does nothing but forward its arguments. The subtle one is unbound-instance: String::toUpperCase becomes a Function<String,String> where the receiver is the first argument.

list.forEach(System.out::println);        // bound instance
names.stream().map(String::toUpperCase);  // unbound instance

Interview note: Trap: "when can't you use a method reference?" When the lambda transforms arguments or calls multiple methods — x -> x.trim().toUpperCase() cannot be a single method reference.

Q4. What problem does Optional solve, and how do you use it well?

Optional<T> makes "might be absent" explicit in the type so callers cannot forget the empty case. Use it as a return type for methods that may have no result, and consume it with map, filter, orElse, orElseThrow — not by calling get() after isPresent(), which just reintroduces the null check.

String name = findUser(id)
    .map(User::getName)
    .orElse("unknown");   // no null check, no get()

The anti-patterns matter for the interview: Optional fields, Optional parameters, and Optional.get() without a presence guard all defeat the purpose. It is a return-type tool for optional results.

Interview note: Follow-up: "orElse vs orElseGet?" orElse(compute()) always evaluates its argument; orElseGet(() -> compute()) evaluates the supplier only when empty — important when the default is expensive.

Q5. Why were default methods added, and how is the diamond conflict resolved?

Default methods let an interface provide a method body so new methods can be added without breaking existing implementers — the concrete motivation was adding stream() and forEach() to Collection. If a class inherits conflicting defaults from two interfaces, it must override the method and can pick one with Interface.super.method().

interface A { default String hi() { return "A"; } }
interface B { default String hi() { return "B"; } }
class C implements A, B {
    public String hi() { return A.super.hi(); }   // resolve the conflict
}

This is a limited form of multiple inheritance — of behavior, not state — and the compiler forces you to resolve ambiguity explicitly rather than picking silently.

Interview note: Trap: "class method vs default method — which wins?" A concrete method in a class (including an inherited one) always beats any interface default; "class wins" is the rule.

Q6. What changed with the Stream API compared to loops?

Streams let you express data processing declaratively — filter, map, collect — as a pipeline the library executes, instead of manual loops with mutable accumulators. They are lazy, composable, and can parallelise, and they pair naturally with lambdas and method references.

double avg = employees.stream()
    .filter(e -> e.getDept() == Dept.ENG)
    .mapToInt(Employee::getSalary)
    .average()
    .orElse(0);

The interview point is not that streams replace all loops — a simple index loop is fine — but that they remove boilerplate and reduce mutation bugs for transform-filter-aggregate work.

Interview note: Follow-up: "when is a plain loop better than a stream?" When you need index arithmetic, early break with side effects, or the pipeline would be harder to read than the loop — clarity wins.

Q7. Why did Java 8 introduce a new Date/Time API?

java.util.Date and Calendar were mutable, not thread-safe, zero-indexed for months, and confusingly designed. The java.time package (LocalDate, LocalDateTime, ZonedDateTime, Duration, Period) replaced them with immutable, thread-safe, clearly-named types based on ISO-8601.

LocalDate today = LocalDate.now();
LocalDate due = today.plusDays(30);            // immutable: returns a new date
boolean overdue = due.isBefore(LocalDate.now());

Immutability is the headline: every operation returns a new instance, so these types are safe to share across threads — the exact opposite of the old Calendar. Mentioning Instant for machine timestamps and ZonedDateTime for time zones rounds out a strong answer.

Interview note: Trap: "is LocalDate.plusDays mutating the original?" No — java.time types are immutable; the original is unchanged and you must use the returned value.

Q8. What is the difference between findFirst, findAny, and how do streams relate to parallelism here?

findFirst returns the first element in encounter order; findAny returns any element and is free to return faster in a parallel stream because it need not respect order. Both are short-circuiting and return Optional.

This ties Java 8's stream and Optional features together: absence is modeled with Optional, and the parallel-friendly variant trades ordering for speed. It is a compact way for interviewers to check that you understand encounter order and laziness at once.

Interview note: Follow-up: "on a sequential stream, do they differ?" In practice findAny usually returns the first element too, but you must not rely on it — only findFirst guarantees order.

How to prepare

Convert a small piece of legacy code — anonymous-class comparators, Calendar date math, null-returning lookups — into lambdas, java.time, and Optional, and notice how each feature removes a specific class of bug. Then rehearse explaining why each feature was added, because "default methods exist to evolve Collection" and "Optional makes absence a type" are the sentences that mark you as fluent rather than merely trained.

Pair this with the deeper Java Streams questions and practice writing pipelines live with the coding questions set. If any feature still feels unfamiliar, the Java learning path covers them from the ground up before your next interview.