Java Interview Questions for 1 Year Experience

What a 1-year Java interview is really testing

At around one year in, interviewers are not looking for architecture or deep internals — they want proof that your fundamentals are solid and that you genuinely understood the work you shipped. The questions stay close to the core language, everyday collections, and basic exception handling, and then pivot to your project. The candidates who pass are the ones who answer the basics cleanly and can defend the parts of the codebase they actually touched.

Answer plainly, give a short example, and never claim work you cannot explain. A confident, honest "I built this part and here's why" beats a memorized feature list every time.

Q1. What are the four pillars of OOP, with a Java example?

Encapsulation (hide state behind methods), Inheritance (reuse via an is-a relationship), Polymorphism (one interface, many implementations), and Abstraction (expose what, hide how). In Java these show up as private fields with getters, extends, method overriding, and interfaces/abstract classes.

The one interviewers dig into is polymorphism, because it drives real design:

interface Notifier { void send(String msg); }
class EmailNotifier implements Notifier {
    public void send(String msg) { /* email */ }
}
class SmsNotifier implements Notifier {
    public void send(String msg) { /* sms */ }
}
Notifier n = new EmailNotifier();   // same type, swappable behaviour

Interview note: Follow-up: "difference between overloading and overriding?" Overloading is same name, different parameters, resolved at compile time; overriding is a subclass redefining a parent method, resolved at runtime.

Q2. What is the difference between == and equals()?

== compares references (are these the same object?); equals() compares logical value (are these objects meaningfully equal?). For objects you almost always want equals(). String, Integer and the wrappers override equals() to compare content.

String a = new String("hi");
String b = new String("hi");
System.out.println(a == b);       // false — different objects
System.out.println(a.equals(b));  // true — same value

This is the most common junior trip-up, and interviewers plant it deliberately. Mention the String pool nuance: string literals are interned, so "hi" == "hi" is true, but new String("hi") creates a fresh object.

Interview note: Trap: "does Integer a = 1000; Integer b = 1000; a == b?" False — outside the -128..127 cache, autoboxing creates distinct objects.

Q3. Why must you override hashCode() when you override equals()?

Because hash-based collections (HashMap, HashSet) locate objects by hashCode() first, then equals(). If equal objects return different hash codes, they land in different buckets and the collection cannot find or dedupe them.

The rule is: equal objects must have equal hash codes. Breaking it means a key you put cannot be get-ed, or a HashSet stores logical duplicates. This is a fundamentals question at one year because it separates people who use collections from people who understand them.

Interview note: Follow-up: "what makes a good hashCode?" It spreads unequal objects across buckets and stays consistent while the object's equals-relevant fields don't change.

Q4. Why is String immutable in Java?

A String's value cannot change after creation; any "modification" returns a new String. Immutability makes strings safe to share across threads, safe to use as HashMap keys (the hash never changes), and enables the string pool to reuse literals.

Because strings are immutable, repeated concatenation in a loop creates many throwaway objects — use StringBuilder there. This connects a fundamentals fact to a practical performance habit, which is exactly the maturity a one-year interview looks for.

StringBuilder sb = new StringBuilder();
for (String part : parts) sb.append(part);   // one buffer, not N strings
String result = sb.toString();

Interview note: Trap: "does s.concat("x") change s?" No — it returns a new String; the original is unchanged.

Q5. When do you use a List vs a Set vs a Map?

List when order matters and duplicates are allowed (ArrayList). Set when you need uniqueness and don't care about order (HashSet). Map when you store key-value pairs and look up by key (HashMap).

At one year, interviewers want the decision, not internals: "I used a HashSet to dedupe incoming IDs, and a HashMap to look up users by id." Being able to justify the choice from the requirement is the signal.

Interview note: Follow-up: "ArrayList vs LinkedList?" ArrayList is array-backed — fast random access, slower middle insertion; LinkedList is node-based — cheap insertion at ends, slow indexing. Default to ArrayList.

Q6. What is the difference between checked and unchecked exceptions?

Checked exceptions (e.g. IOException) must be caught or declared — the compiler enforces it — and model recoverable conditions. Unchecked exceptions (RuntimeException subtypes like NullPointerException, IllegalArgumentException) are not enforced and usually indicate bugs.

try (var reader = Files.newBufferedReader(path)) {   // may throw IOException (checked)
    return reader.readLine();
}   // try-with-resources closes the reader automatically

Knowing try-with-resources at one year is a plus — it shows you learned the modern, safe way to handle resources rather than a manual finally.

Interview note: Trap: "is NullPointerException checked?" No — it's unchecked; the fix is a null guard or Optional, not a routine catch.

Q7. Explain the static keyword.

static means "belongs to the class, not an instance." A static field is shared across all objects; a static method can be called without an object and cannot access instance fields directly. Use it for constants and stateless utility methods.

class MathUtil {
    static final double PI = 3.14159;
    static int square(int x) { return x * x; }   // no instance needed
}
int r = MathUtil.square(5);

A common junior confusion is calling a static method as if it depends on object state — clarifying that static has no this shows real understanding.

Interview note: Follow-up: "can a static method be overridden?" No — statics are hidden, not overridden; method resolution for statics is by reference type at compile time.

Q8. Walk me through your project — what did you build and why those choices?

Describe the application's purpose, your specific contribution, the stack and why, and one concrete problem you solved. Keep it honest and specific: "I built the order-history endpoint in Spring Boot, backed by a JPA repository, and fixed an N+1 query by adding a fetch join."

Interviewers use the project as a springboard for follow-ups, so prepare to defend the parts you touched: why a List here, why that exception was caught there, why Spring. The goal is to show you made decisions and learned from them, not that you memorized the framework.

Interview note: Follow-up: "what would you do differently now?" Have a genuine answer — a missed test, a better data structure, clearer error handling. Reflection signals growth, which is what a one-year interview rewards.

How to prepare

Master a small set of fundamentals until they are automatic: == vs equals, equals/hashCode, String immutability, collection choice, and checked vs unchecked exceptions. Then write a two-minute project story and rehearse the technical follow-ups on the parts you actually built — that combination carries most one-year interviews. Do not try to fake senior-level internals; interviewers calibrate for your experience and reward honesty over bluffing.

Deepen the exception material with the exception handling questions, and when you're ready to see where the bar moves next, glance at the 4 years experience questions to understand what production-level answers look like. To shore up any shaky fundamentals, work through the Java learning path before your interviews.