OOP & Programming Foundations

1Why OOP exists

Before you can defend object-orientation, you have to remember the pain it was invented to cure.

Picture a program written as a pile of functions over a pile of shared data — early procedural code. At a thousand lines it's fine. At a hundred thousand, a quiet catastrophe sets in: any function might touch any data, so to change one structure safely you'd have to read the entire codebase to find every place that depends on it. The data and the logic that owns it have drifted apart, and nobody can hold the whole thing in their head anymore.

Object-orientation is one disciplined response to that. The core move is almost embarrassingly simple: keep data and the behaviour that operates on it in the same place, behind a boundary. An Account object owns its balance and the rules for changing it. Nothing outside can reach in and set the balance to a negative number, because the only way in is through methods that enforce the rules.

Everything else — the famous four pillars — is a consequence of taking that boundary seriously. Encapsulation is the boundary. Abstraction is what you choose to show through it. Inheritance and polymorphism are how related objects share and vary behaviour across that boundary. Hold onto that framing: the pillars aren't four unrelated vocabulary words, they're four views of "manage complexity by drawing boundaries around state and behaviour."

2Encapsulation — the boundary itself

Encapsulation is two things at once: bundling state with the methods that act on it, and hiding that state behind a controlled interface. The hiding is the part that earns its keep.

Think of a class as a sealed appliance. There are buttons on the front — the public methods — and wiring inside that you never touch. As long as the buttons keep behaving the same way, the manufacturer can completely redesign the internals and you'd never know. That's the entire value proposition: callers depend on the public contract, never on the internals, so the internals stay free to change.

The opposite — exposing raw fields — quietly poisons a codebase. The moment a field is public, anyone might read or write it, and you've lost the ability to validate, to compute it lazily, to log access, or to change its representation. You've also lost the single place where an invariant could be enforced. Encapsulation gives every object exactly one doorway, so the rules live at the doorway.

class Account {
    private long balanceCents;            // hidden state

    public void withdraw(long cents) {    // the only doorway
        if (cents <= 0) throw new IllegalArgumentException("amount must be positive");
        if (cents > balanceCents) throw new IllegalStateException("insufficient funds");
        balanceCents -= cents;            // invariant enforced in one place
    }
    public long balance() { return balanceCents; }
}

3Abstraction — deciding what to show

Encapsulation and abstraction are cousins that get muddled constantly, so pin the distinction now: encapsulation hides internals to protect them; abstraction hides them to simplify what you have to think about. One is about safety, the other is about cognitive load.

Abstraction is the art of deciding what to leave out. A PaymentGateway exposes one meaningful capability — charge(amount) — and hides whether that involves Stripe, a retry loop, currency conversion, or a fraud check. The caller depends on the promise ("this charges money") and never on the mechanism. Because the surface is small and stable, you can wield something genuinely complex without studying its guts.

The discipline that makes abstraction work is naming by intent, not by mechanism. Call it PaymentGateway, not StripeHttpClientWrapper. The first name survives when you switch providers; the second leaks the very detail abstraction was supposed to hide. Good abstractions read like a vocabulary of what your system does, with the how tucked safely behind each word.

4Inheritance vs composition

Inheritance lets one type declare it is a kind of another and inherit its fields and behaviour for free. A SavingsAccount is an Account, so it reuses the balance and deposit logic and only specialises how interest accrues. Used on a genuine "is-a" relationship, it removes duplication and lets you treat a whole family of types uniformly.

The problem is that inheritance is seductive as a code-reuse shortcut, and that's where it turns toxic. The instant you extend a class just because it happens to have a method you want, you've welded your type to its parent's entire shape. A change three levels up the hierarchy can break a child that looked unrelated — the "fragile base class" problem. Deep inheritance trees become the kind of code people are afraid to touch.

The senior default is "favour composition over inheritance." Instead of being a thing to reuse its behaviour, hold a thing and delegate to it. Composition models a "has-a" relationship, keeps coupling loose, and lets you swap the held object at runtime — exactly the flexibility a rigid hierarchy denies you.

5Polymorphism

Polymorphism — "many forms" — is the pillar that makes the others pay off. The idea: one call, many behaviours, resolved at runtime. You ask every Shape for its area(); the circle runs circle maths, the square runs square maths, and the calling code never asks which one it's holding.

That indifference is the whole prize. Your logic is written once, against the abstract type, and it keeps working when you add a Triangle next month — without editing a single line of the caller. New behaviour arrives by adding a class, not by editing existing code. If that sounds familiar, it should: polymorphism is the engine behind "open for extension, closed for modification."

It's worth distinguishing the flavours so you can speak precisely. Runtime (subtype) polymorphism is the dynamic dispatch above — the interviewer almost always means this. Compile-time polymorphism covers method overloading and generics, resolved before the program runs. Mentioning that you know the difference is a small, cheap seniority signal.

6SOLID — five smells, one idea

SOLID is five design principles, but underneath they collapse into one goal: reduce coupling so a change in one place doesn't ripple through the whole system. Treat them as smells and warning signs, not laws to obey mechanically.

S — Single Responsibility

A class should have one reason to change. If your Report class both computes numbers and formats them as PDF, a change to either concern forces you to reopen the same file and risks breaking the other. Split by reason-to-change, and each piece stays small and testable.

O — Open/Closed

Software should be open to extension but closed to modification. Concretely: you should be able to add new behaviour by adding code, not by editing working code. Polymorphism (§5) is how you achieve it — a new subtype instead of another branch in a growing switch.

L — Liskov Substitution

A subtype must be usable anywhere its parent is, without surprises. The Square extends Rectangle trap breaks this: substituting a square where a rectangle is expected can violate the caller's assumptions. If a subclass has to weaken a guarantee, it isn't really a subtype.

I — Interface Segregation

Many small, focused interfaces beat one fat one. Don't force a Printer to implement scan() and fax() just because some machines do all three. Clients should depend only on the methods they actually use.

D — Dependency Inversion

Depend on abstractions, not concretions. High-level policy shouldn't import a specific database class; both should depend on an interface. This is what makes code testable (swap in a fake) and flexible (swap in a new implementation).

7Design patterns — a shared vocabulary

A design pattern is a named, reusable solution to a problem that keeps recurring across many systems. Their value is twofold: you skip reinventing (and re-debugging) a solution someone already refined, and you gain a shared vocabulary — "let's use a Strategy here" communicates an entire design in three words.

The trap is treating patterns as a goal. Reaching for them to look sophisticated adds ceremony and indirection without buying anything. The discipline is to recognise the recurring problem first; the pattern is the answer to it, never the starting point. Here are the four you'll be asked about most.

Strategy — swap an algorithm

When behaviour needs to vary — different pricing rules, different sort orders — Strategy puts each variant behind a common interface and lets you inject the one you want. It kills the sprawling if/else and lets behaviour change at runtime.

Factory — centralise creation

A Factory hides object creation behind a method, so callers say create(type) instead of hard-coding which concrete class to new. Adding a new type touches one place. Factory decides what to build; Strategy decides how to behave — a clean pair to contrast.

Observer — decouple events from reactions

Observer lets objects subscribe to another's events. The publisher fires "something changed" and never knows who's listening; subscribers react independently. That decoupling of "it happened" from "who cares" is the real prize — it's the backbone of event systems and UI frameworks.

Singleton — exactly one instance

Singleton guarantees a single shared instance — reasonable for a genuinely global resource like configuration or a connection pool. Treat it with suspicion everywhere else: global mutable state is hard to test and easy to abuse. Knowing when not to use it is the senior signal.

8DRY · KISS · YAGNI — and pragmatism

These three are the everyday hygiene of clean code. They're quick to state, but the senior version is knowing their limits.

• DRY — Don't Repeat Yourself. Every piece of knowledge should have one authoritative home; duplication is a future bug waiting for someone to update one copy and forget the other.
• KISS — Keep It Simple. The simplest solution that works beats the clever one that impresses. Cleverness is a tax your future teammates pay.
• YAGNI — You Aren't Gonna Need It. Don't build for imagined future requirements; you'll usually guess wrong and carry the complexity forever.

9Complexity & data-structure awareness

You won't be inventing algorithms in most interviews outside a dedicated coding screen — but freezing when asked "what's the cost of that?" reads as junior. The goal here is fluent awareness, not mastery.

Big-O describes how cost grows as input grows, ignoring constants. O(1) is flat, O(log n) barely moves, O(n) scales linearly, O(n log n) is good sorting, and O(n²) is the nested-loop smell that melts at scale. You're judged less on perfect analysis than on whether you think about cost at all.

Every data structure trades one operation for another — pick by access pattern:

10Concurrency & thread safety

Almost every concurrency bug traces back to a single villain: shared mutable state. When two threads read and write the same data without coordination, the result depends on who happened to get there first — a race condition. The reason they're so vicious is that they're intermittent: the code passes a thousand times and corrupts data on the thousand-and-first.

Interviewers aren't fishing for lock-free wizardry. They want to hear that you understand the danger and reach for the right tool. And the senior instinct is to remove the villain before fighting it:

• Don't share what you don't have to — give each thread its own data.
• Make it immutable where you can — data that never changes is trivially thread-safe.
• Guard the rest with locks or atomics when shared mutation is unavoidable — and keep the guarded section small.
• Prefer higher-level tools — thread pools, concurrent collections, message queues — over hand-rolled locking, which is where deadlocks breed.

11Everyday language fluency

These aren't deep topics, but fumbling them reads as rust — so be crisp. Each exists to let the language carry correctness you'd otherwise hand-write and get wrong.

Exceptions

Exceptions signal the genuinely exceptional and separate error-handling from the happy path. The rule: don't use them for ordinary control flow (that's both slow and confusing), and catch only what you can meaningfully handle — swallowing exceptions silently is how bugs go dark.

Generics

Generics let you write reusable, type-safe containers and functions — a List<Account> the compiler guarantees holds accounts. The payoff is that type errors are caught at compile time instead of blowing up at runtime, and you stop casting and praying.

Streams & lambdas

Lambdas are inline functions; streams (or LINQ, or comprehensions) let you express operations on data declaratively — map, filter, reduce — instead of hand-writing the loop. You say what you want, not the bookkeeping of how to iterate, and the intent reads off the page.