<h1>From HashMap to RAG — What a 15-Minute Interview Taught Me About AI-Powered Search</h1>
<blockquote>
<p>Some interview questions feel like trick questions until you realize they're not — they're just designed to see how far you can think. This one started with cricket and ended with AI agents.</p>
</blockquote>
<p>This was a round with a well-known company, and it was short — maybe fifteen minutes on this one question — but it packed in more than rounds twice its length.</p>
<h2>The setup</h2>
<p>The interviewer described a system: a collection of articles, each with a unique article ID, covering cricket match events — centuries scored, wickets taken, IPL match results, player milestones, and so on. Think CricInfo-style content, but stored as articles in a database.</p>
<p>The question was simple on the surface:</p>
<blockquote>
<p>"If a user wants to search for articles about Virat Kohli, how would you do it?"</p>
</blockquote>
<p>My instinct was to reach for a classic CS answer: an <strong>inverted index</strong>. Build a lookup table where every player name, team name, or keyword maps to a list of article IDs. Search for "Virat Kohli" → get back a list of IDs in O(1) time. Fast, clean, efficient.</p>
<p>The interviewer nodded, then pushed further:</p>
<blockquote>
<p>"But our goal isn't just speed. What if the user searches for 'centuries scored by Virat Kohli in knockout matches' — or 'total wickets in the last 5 overs'?"</p>
</blockquote>
<p>That's when I realized the question wasn't about indexing at all. It was about <strong>understanding intent</strong>.</p>
<p><strong>The trap:</strong> keyword search solves "find articles containing these words." But user queries are rarely that simple. Real questions carry context, relationships, and nuance that no inverted index can handle alone.</p>
<h2>The real answer: RAG + tool calling</h2>
<p>After a beat, I arrived at the architecture that actually solves this — one that's become a standard pattern in production AI systems. It combines three ideas.</p>
<h3>1. LLM as the query interpreter</h3>
<p>Instead of trying to pattern-match the user's query to keywords, you hand it to a large language model. The LLM understands what the user actually wants — batting stats, bowling figures, match results — even when they phrase it naturally or ambiguously.</p>
<h3>2. Tools as the data layer</h3>
<p>LLMs are stateless. They don't have access to your database. So you give them <strong>tools</strong> — functions they can call to fetch real data. In this cricket system, those tools might look like:</p>
<pre><code class="language-javascript">// Tools exposed to the LLM
const tools = [
  {
    name: "get_batting_stats",
    params: { player: "string", match_type: "string?" }
  },
  {
    name: "get_bowling_figures",
    params: { player: "string", match_id: "string?" }
  },
  {
    name: "get_match_summary",
    params: { match_id: "string" }
  },
  {
    name: "get_player_info",
    params: { player: "string" }
  }
];
</code></pre>
<h3>3. The agentic loop</h3>
<p>The full flow — what's often called <strong>Retrieval-Augmented Generation (RAG)</strong> with tool use — looks like this:</p>
<pre><code>User query
   │
   ▼
LLM + system prompt
   │
   ▼
Tool-call decision  ──►  Your MCP / API server
                              │
                              ▼
                         Tool results (data)
                              │
                              ▼
                    LLM synthesizes the answer
</code></pre>
<p><strong>Why this works:</strong> the LLM handles intent parsing and response synthesis. Your tools handle data fetching. Neither tries to do both jobs, and neither has to.</p>
<p>A user query like <em>"How many centuries has Kohli scored in IPL playoffs?"</em> becomes a structured call to <code>get_batting_stats({ player: "Virat Kohli", match_type: "IPL playoff" })</code>. The result comes back, the LLM formats a coherent answer, and the user sees exactly what they asked for — not a list of article IDs.</p>
<p>This is the pattern behind most production AI assistants today. When you use a tool like Perplexity, or a customer-support bot that can actually check your order, this is roughly what's happening under the hood.</p>
<h2>On MCP servers</h2>
<p>I mentioned MCP (Model Context Protocol) in my answer. MCP is a standardized protocol — developed by Anthropic — for exposing tools to LLMs in a consistent, interoperable way. Rather than hardcoding tool interfaces per model or per system, MCP gives you a uniform layer: your server exposes tools, the LLM connects and discovers them, and you don't have to reinvent the plumbing for every new model you integrate.</p>
<p>In the cricket article system, you'd build an MCP server that exposes your data-fetching functions. The LLM agent connects to it, sees the available tools, and calls them as needed — all without bespoke integration work per query type.</p>
<h2>The HashMap curveball</h2>
<p>After the main question, the interviewer pivoted to something that felt like a pop quiz:</p>
<blockquote>
<p>"You mentioned HashMap a lot. What's the lookup time for a HashMap?"</p>
</blockquote>
<p>I said O(log n) first. Wrong. The interviewer's response was perfect: <em>"If it's O(log n), why don't we just use a tree?"</em></p>
<p>That nudge was enough. Here's the correct answer:</p>
<table>
<thead>
<tr>
<th align="left">Case</th>
<th align="left">Time complexity</th>
<th align="left">Why</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Average (no collision)</td>
<td align="left"><strong>O(1)</strong></td>
<td align="left">Hash function maps key directly to a bucket index</td>
</tr>
<tr>
<td align="left">Collision, small bucket</td>
<td align="left"><strong>O(n)</strong> within bucket</td>
<td align="left">Linked-list traversal within the bucket</td>
</tr>
<tr>
<td align="left">Collision, large bucket (Java)</td>
<td align="left"><strong>O(log n)</strong></td>
<td align="left">Bucket converts to a red-black tree when size ≥ 8</td>
</tr>
<tr>
<td align="left">All keys collide (worst case)</td>
<td align="left"><strong>O(n)</strong></td>
<td align="left">Everything ends up in one bucket</td>
</tr>
</tbody>
</table>
<p>The O(log n) I initially mentioned isn't the average case — it's what Java's <code>HashMap</code> uses <em>inside a single bucket</em> once the collision count exceeds a threshold (default: 8). At that point, the linked list within the bucket is converted to a <strong>red-black tree</strong> for better worst-case performance within that bucket.</p>
<p>But across the whole map, under a good hash function with low collision rates, HashMap lookup is O(1). That's the whole point of the data structure, and why it's almost always preferred over a tree when you need key-value lookup.</p>
<p><strong>The lesson under the lesson:</strong> self-correcting under pressure is a good signal. Interviewers often know you'll slip up — they're watching to see if you can catch yourself and reason your way back.</p>
<h2>What I'd say if I could go back</h2>
<ul>
<li>Name the pattern upfront: "This is a RAG + tool-calling architecture."</li>
<li>Mention embeddings + vector search for semantic retrieval, not just keyword indexing.</li>
<li>Clarify that MCP is a protocol for tool discovery and standardization, not just a server.</li>
<li>On HashMap: lead with O(1), then explain the collision edge cases as bonus depth.</li>
<li>When you slip on a basic, correct yourself quickly and move on — don't spiral.</li>
</ul>
<h2>The bigger picture</h2>
<p>What made this question good was that it started with something concrete — cricket articles, search — and forced a chain of realizations: keyword search isn't semantic search, semantic search isn't enough without intent parsing, intent parsing at scale means LLMs, and LLMs need structured access to your data via tools.</p>
<p>That chain — from a simple indexing question to a full agentic AI architecture — is increasingly the kind of systems thinking companies look for when hiring for AI-adjacent engineering roles. The inverted index isn't wrong; it's just the first step, not the whole answer.</p>
<p>And sometimes, the best interviews are the ones that force you to keep going until you get there.</p>



# From HashMap to RAG — What a 15-Minute Interview Taught Me About AI-Powered Search

> Some interview questions feel like trick questions until you realize they're not — they're just designed to see how far you can think. This one started with cricket and ended with AI agents.

This was a round with a well-known company, and it was short — maybe fifteen minutes on this one question — but it packed in more than rounds twice its length.

## The setup

The interviewer described a system: a collection of articles, each with a unique article ID, covering cricket match events — centuries scored, wickets taken, IPL match results, player milestones, and so on. Think CricInfo-style content, but stored as articles in a database.

The question was simple on the surface:

> "If a user wants to search for articles about Virat Kohli, how would you do it?"

My instinct was to reach for a classic CS answer: an **inverted index**. Build a lookup table where every player name, team name, or keyword maps to a list of article IDs. Search for "Virat Kohli" → get back a list of IDs in O(1) time. Fast, clean, efficient.

The interviewer nodded, then pushed further:

> "But our goal isn't just speed. What if the user searches for 'centuries scored by Virat Kohli in knockout matches' — or 'total wickets in the last 5 overs'?"

That's when I realized the question wasn't about indexing at all. It was about **understanding intent**.

**The trap:** keyword search solves "find articles containing these words." But user queries are rarely that simple. Real questions carry context, relationships, and nuance that no inverted index can handle alone.

## The real answer: RAG + tool calling

After a beat, I arrived at the architecture that actually solves this — one that's become a standard pattern in production AI systems. It combines three ideas.

### 1. LLM as the query interpreter

Instead of trying to pattern-match the user's query to keywords, you hand it to a large language model. The LLM understands what the user actually wants — batting stats, bowling figures, match results — even when they phrase it naturally or ambiguously.

### 2. Tools as the data layer

LLMs are stateless. They don't have access to your database. So you give them **tools** — functions they can call to fetch real data. In this cricket system, those tools might look like:

```javascript
// Tools exposed to the LLM
const tools = [
  {
    name: "get_batting_stats",
    params: { player: "string", match_type: "string?" }
  },
  {
    name: "get_bowling_figures",
    params: { player: "string", match_id: "string?" }
  },
  {
    name: "get_match_summary",
    params: { match_id: "string" }
  },
  {
    name: "get_player_info",
    params: { player: "string" }
  }
];
```

### 3. The agentic loop

The full flow — what's often called **Retrieval-Augmented Generation (RAG)** with tool use — looks like this:

```
User query
   │
   ▼
LLM + system prompt
   │
   ▼
Tool-call decision  ──►  Your MCP / API server
                              │
                              ▼
                         Tool results (data)
                              │
                              ▼
                    LLM synthesizes the answer
```

**Why this works:** the LLM handles intent parsing and response synthesis. Your tools handle data fetching. Neither tries to do both jobs, and neither has to.

A user query like *"How many centuries has Kohli scored in IPL playoffs?"* becomes a structured call to `get_batting_stats({ player: "Virat Kohli", match_type: "IPL playoff" })`. The result comes back, the LLM formats a coherent answer, and the user sees exactly what they asked for — not a list of article IDs.

This is the pattern behind most production AI assistants today. When you use a tool like Perplexity, or a customer-support bot that can actually check your order, this is roughly what's happening under the hood.

## On MCP servers

I mentioned MCP (Model Context Protocol) in my answer. MCP is a standardized protocol — developed by Anthropic — for exposing tools to LLMs in a consistent, interoperable way. Rather than hardcoding tool interfaces per model or per system, MCP gives you a uniform layer: your server exposes tools, the LLM connects and discovers them, and you don't have to reinvent the plumbing for every new model you integrate.

In the cricket article system, you'd build an MCP server that exposes your data-fetching functions. The LLM agent connects to it, sees the available tools, and calls them as needed — all without bespoke integration work per query type.

## The HashMap curveball

After the main question, the interviewer pivoted to something that felt like a pop quiz:

> "You mentioned HashMap a lot. What's the lookup time for a HashMap?"

I said O(log n) first. Wrong. The interviewer's response was perfect: *"If it's O(log n), why don't we just use a tree?"*

That nudge was enough. Here's the correct answer:

| Case | Time complexity | Why |
| :--- | :--- | :--- |
| Average (no collision) | **O(1)** | Hash function maps key directly to a bucket index |
| Collision, small bucket | **O(n)** within bucket | Linked-list traversal within the bucket |
| Collision, large bucket (Java) | **O(log n)** | Bucket converts to a red-black tree when size ≥ 8 |
| All keys collide (worst case) | **O(n)** | Everything ends up in one bucket |

The O(log n) I initially mentioned isn't the average case — it's what Java's `HashMap` uses *inside a single bucket* once the collision count exceeds a threshold (default: 8). At that point, the linked list within the bucket is converted to a **red-black tree** for better worst-case performance within that bucket.

But across the whole map, under a good hash function with low collision rates, HashMap lookup is O(1). That's the whole point of the data structure, and why it's almost always preferred over a tree when you need key-value lookup.

**The lesson under the lesson:** self-correcting under pressure is a good signal. Interviewers often know you'll slip up — they're watching to see if you can catch yourself and reason your way back.

## What I'd say if I could go back

- Name the pattern upfront: "This is a RAG + tool-calling architecture."
- Mention embeddings + vector search for semantic retrieval, not just keyword indexing.
- Clarify that MCP is a protocol for tool discovery and standardization, not just a server.
- On HashMap: lead with O(1), then explain the collision edge cases as bonus depth.
- When you slip on a basic, correct yourself quickly and move on — don't spiral.

## The bigger picture

What made this question good was that it started with something concrete — cricket articles, search — and forced a chain of realizations: keyword search isn't semantic search, semantic search isn't enough without intent parsing, intent parsing at scale means LLMs, and LLMs need structured access to your data via tools.

That chain — from a simple indexing question to a full agentic AI architecture — is increasingly the kind of systems thinking companies look for when hiring for AI-adjacent engineering roles. The inverted index isn't wrong; it's just the first step, not the whole answer.

And sometimes, the best interviews are the ones that force you to keep going until you get there.


From HashMap to RAG — What a 15-Minute Interview Taught Me About AI Search

<h1>Building a Blazing-Fast Kanban Board UI with IndexedDB</h1>
<p>Most Kanban boards I've used have a tiny but persistent friction: you drag a card, and there's a quarter-second pause while it waits for the server to bless the move. It's small, but it adds up. After a few hundred drags you start to feel it in your shoulders.</p>
<p>I wanted to build one where dragging a card felt like dragging an icon on your desktop — zero latency, zero "is it saved?" anxiety. The way to get there isn't a faster API. It's to stop waiting for the API at all.</p>
<p>This post walks through the architecture I landed on: an IndexedDB-backed frontend that owns the source of truth locally, paired with a Linear-inspired sync engine on the backend that reconciles changes in the background.</p>
<h2>Why IndexedDB, and not just React state</h2>
<p>The obvious first instinct is "throw it in Redux and persist to localStorage." That works until it doesn't:</p>
<ul>
<li><strong>localStorage is synchronous</strong> and blocks the main thread. A board with a few thousand cards starts hitching.</li>
<li><strong>localStorage is ~5MB</strong> and stringified. IndexedDB is orders of magnitude larger and stores structured data.</li>
<li><strong>You can't query localStorage.</strong> With IndexedDB you get indexes, cursors, and range queries — basically a real database in the browser.</li>
</ul>
<p>The mental shift is treating IndexedDB as the <em>primary</em> store, not a cache. The UI reads from IndexedDB. The UI writes to IndexedDB. The server is just another peer that the sync engine talks to.</p>
<h2>The frontend architecture</h2>
<p>Three layers, top to bottom:</p>
<h3>1. The UI layer</h3>
<p>React components subscribe to a thin reactive store. When you drag a card from "In Progress" to "Done," the component dispatches a mutation. That's it from the UI's perspective. No await, no spinner, no error boundary for network failures.</p>
<h3>2. The local store (IndexedDB)</h3>
<p>Every mutation is written to IndexedDB immediately and synchronously from the UI's point of view. I use a small wrapper around the native IndexedDB API — Dexie works well, but a hand-rolled one is maybe 200 lines if you only need a few object stores.</p>
<p>The schema is intentionally boring: <code>boards</code>, <code>columns</code>, <code>cards</code>, and a <code>mutations</code> store that acts as an outbox.</p>
<p>Every mutation gets two things written in a single transaction:</p>
<ol>
<li>The new state of the entity (the card with its new column)</li>
<li>An entry in the <code>mutations</code> outbox describing what changed</li>
</ol>
<p>That transactional guarantee is the whole game. If the tab crashes mid-write, either both happened or neither did. You never end up with a UI that thinks the card moved but no record to send to the server.</p>
<h3>3. The sync worker</h3>
<p>A background loop (I run it in a Web Worker so it doesn't compete with the UI for the main thread) reads from the <code>mutations</code> outbox and ships entries to the server. On success, it deletes the entry. On failure, it backs off and retries. On a 409 conflict, it asks the server for the authoritative state and reconciles.</p>
<p>The UI never knows or cares whether the sync worker is caught up. It just reads from IndexedDB.</p>
<h2>The backend: a Linear-inspired sync engine</h2>
<p>The backend is where it got fun. I read everything I could find about how Linear handles sync — their model is excellent and surprisingly approachable once you strip the marketing.</p>
<p>The core ideas:</p>
<h3>Mutations, not REST</h3>
<p>The client doesn't <code>POST /cards/:id</code> with the new column. It sends a <em>mutation</em>: a typed message like <code>{ type: "moveCard", cardId, fromColumn, toColumn, position, clientTimestamp }</code>.</p>
<p>The server applies the mutation against current state and returns the resulting transaction. If the mutation is impossible (the card was deleted by someone else), the server rejects it with enough information for the client to roll back.</p>
<h3>A global sync log</h3>
<p>Every successful mutation gets appended to a per-workspace log with a monotonically increasing version number. Clients track the last version they've seen. When they reconnect, they ask for everything since that version. This is essentially a tiny replication log, and it makes catch-up sync embarrassingly simple.</p>
<h3>Optimistic by default, reconciled when needed</h3>
<p>Because the client already applied the mutation locally and moved on, the server's job is just to make the global log consistent. Most of the time it's a rubber stamp. When conflicts happen — two people drag the same card to different columns — last-writer-wins is fine for a Kanban board. The loser sees the card snap to the winning position next sync tick. Anything more sophisticated is overkill for this domain.</p>
<h2>What this feels like in practice</h2>
<p>Dragging a card is instantaneous because it's a local IndexedDB write — no network in the critical path. Offline works for free, because offline is just "the sync worker is having a bad time, but the UI doesn't notice." Page loads are fast because the initial render comes from IndexedDB, and the sync worker catches up to the server in the background.</p>
<p>The first time I closed my laptop mid-drag, reopened it on a different network, and watched the board reconcile silently, I knew the architecture was right.</p>
<h2>What I'd do differently</h2>
<ul>
<li><strong>Start with the mutation types, not the schema.</strong> I spent too long modeling tables. The mutation vocabulary is the real API.</li>
<li><strong>Build the outbox first.</strong> Everything else hangs off it. If your outbox is solid, your offline story is solid.</li>
<li><strong>Don't ship your own conflict resolution if you don't have to.</strong> Last-writer-wins covered ~99% of cases. The remaining 1% I solved with UI affordances ("this card was moved while you were offline — undo?") instead of CRDT machinery.</li>
</ul>
<h2>Takeaway</h2>
<p>Local-first isn't a feature you bolt on. It's an architectural choice that ripples through every layer — but the payoff is a UI that feels like a native app and a sync story that's honestly simpler than the REST CRUD app I would have built otherwise.</p>
<p>The server stops being a bottleneck and becomes what it should have been all along: a reconciliation point, not a gatekeeper.</p>



# Building a Blazing-Fast Kanban Board UI with IndexedDB

Most Kanban boards I've used have a tiny but persistent friction: you drag a card, and there's a quarter-second pause while it waits for the server to bless the move. It's small, but it adds up. After a few hundred drags you start to feel it in your shoulders.

I wanted to build one where dragging a card felt like dragging an icon on your desktop — zero latency, zero "is it saved?" anxiety. The way to get there isn't a faster API. It's to stop waiting for the API at all.

This post walks through the architecture I landed on: an IndexedDB-backed frontend that owns the source of truth locally, paired with a Linear-inspired sync engine on the backend that reconciles changes in the background.

## Why IndexedDB, and not just React state

The obvious first instinct is "throw it in Redux and persist to localStorage." That works until it doesn't:

- **localStorage is synchronous** and blocks the main thread. A board with a few thousand cards starts hitching.
- **localStorage is ~5MB** and stringified. IndexedDB is orders of magnitude larger and stores structured data.
- **You can't query localStorage.** With IndexedDB you get indexes, cursors, and range queries — basically a real database in the browser.

The mental shift is treating IndexedDB as the *primary* store, not a cache. The UI reads from IndexedDB. The UI writes to IndexedDB. The server is just another peer that the sync engine talks to.

## The frontend architecture

Three layers, top to bottom:

### 1. The UI layer

React components subscribe to a thin reactive store. When you drag a card from "In Progress" to "Done," the component dispatches a mutation. That's it from the UI's perspective. No await, no spinner, no error boundary for network failures.

### 2. The local store (IndexedDB)

Every mutation is written to IndexedDB immediately and synchronously from the UI's point of view. I use a small wrapper around the native IndexedDB API — Dexie works well, but a hand-rolled one is maybe 200 lines if you only need a few object stores.

The schema is intentionally boring: `boards`, `columns`, `cards`, and a `mutations` store that acts as an outbox.

Every mutation gets two things written in a single transaction:
1. The new state of the entity (the card with its new column)
2. An entry in the `mutations` outbox describing what changed

That transactional guarantee is the whole game. If the tab crashes mid-write, either both happened or neither did. You never end up with a UI that thinks the card moved but no record to send to the server.

### 3. The sync worker

A background loop (I run it in a Web Worker so it doesn't compete with the UI for the main thread) reads from the `mutations` outbox and ships entries to the server. On success, it deletes the entry. On failure, it backs off and retries. On a 409 conflict, it asks the server for the authoritative state and reconciles.

The UI never knows or cares whether the sync worker is caught up. It just reads from IndexedDB.

## The backend: a Linear-inspired sync engine

The backend is where it got fun. I read everything I could find about how Linear handles sync — their model is excellent and surprisingly approachable once you strip the marketing.

The core ideas:

### Mutations, not REST

The client doesn't `POST /cards/:id` with the new column. It sends a *mutation*: a typed message like `{ type: "moveCard", cardId, fromColumn, toColumn, position, clientTimestamp }`.

The server applies the mutation against current state and returns the resulting transaction. If the mutation is impossible (the card was deleted by someone else), the server rejects it with enough information for the client to roll back.

### A global sync log

Every successful mutation gets appended to a per-workspace log with a monotonically increasing version number. Clients track the last version they've seen. When they reconnect, they ask for everything since that version. This is essentially a tiny replication log, and it makes catch-up sync embarrassingly simple.

### Optimistic by default, reconciled when needed

Because the client already applied the mutation locally and moved on, the server's job is just to make the global log consistent. Most of the time it's a rubber stamp. When conflicts happen — two people drag the same card to different columns — last-writer-wins is fine for a Kanban board. The loser sees the card snap to the winning position next sync tick. Anything more sophisticated is overkill for this domain.

## What this feels like in practice

Dragging a card is instantaneous because it's a local IndexedDB write — no network in the critical path. Offline works for free, because offline is just "the sync worker is having a bad time, but the UI doesn't notice." Page loads are fast because the initial render comes from IndexedDB, and the sync worker catches up to the server in the background.

The first time I closed my laptop mid-drag, reopened it on a different network, and watched the board reconcile silently, I knew the architecture was right.

## What I'd do differently

- **Start with the mutation types, not the schema.** I spent too long modeling tables. The mutation vocabulary is the real API.
- **Build the outbox first.** Everything else hangs off it. If your outbox is solid, your offline story is solid.
- **Don't ship your own conflict resolution if you don't have to.** Last-writer-wins covered ~99% of cases. The remaining 1% I solved with UI affordances ("this card was moved while you were offline — undo?") instead of CRDT machinery.

## Takeaway

Local-first isn't a feature you bolt on. It's an architectural choice that ripples through every layer — but the payoff is a UI that feels like a native app and a sync story that's honestly simpler than the REST CRUD app I would have built otherwise.

The server stops being a bottleneck and becomes what it should have been all along: a reconciliation point, not a gatekeeper.


Building a Blazing-Fast Kanban Board UI with IndexedDB


# Rakuten Java Interview Experience

This was a Java-heavy round at Rakuten. The questions moved from core language features into OOP, collections internals, Spring Boot, Hibernate, concurrency, and a few tricky language behaviour questions. Below is the full set of questions with the answers I gave.

## 📋 Java Interview — Complete Answers

### 1. Major Features in Java That Changed Coding

Java has evolved a lot over the years. The most impactful release was **Java 8**, which introduced a completely functional style of programming.

**Lambdas** allowed us to write anonymous functions in a single line instead of creating whole anonymous classes:

```java
// Before Java 8
Runnable r = new Runnable() {
    public void run() { System.out.println("Hello"); }
};

// After Java 8 with Lambda
Runnable r = () -> System.out.println("Hello");
```

**Stream API** changed how we process collections:

```java
List<Integer> nums = Arrays.asList(1, 2, 3, 4, 5);

// Filter even numbers and collect
List<Integer> evens = nums.stream()
    .filter(n -> n % 2 == 0)
    .collect(Collectors.toList());
```

**`var` keyword (Java 10)** reduced boilerplate:

```java
var list = new ArrayList<String>(); // no need to repeat type
```

**Records (Java 16)** eliminated boilerplate data classes:

```java
// Instead of class with getters/setters/constructor
public record Merchant(String name, Double balance) {}
```

**Virtual Threads (Java 21)** made handling millions of concurrent requests easy without consuming OS threads.

### 2. OOP Features in Java

Java is built on 4 pillars:

**Encapsulation** — hide internal data, expose only what's needed:

```java
public class BankAccount {
    private Double balance; // hidden
    public Double getBalance() { return balance; } // exposed
    public void setBalance(Double b) { this.balance = b; }
}
```

**Inheritance** — child class reuses parent class code:

```java
class Animal {
    public void eat() { System.out.println("Eating..."); }
}
class Dog extends Animal {
    public void bark() { System.out.println("Barking..."); }
}
// Dog can now eat() AND bark()
```

**Polymorphism** — same method, different behavior:

```java
// Overloading (compile time)
void print(String s) {}
void print(Integer i) {}

// Overriding (runtime)
class Animal { void sound() { System.out.println("..."); } }
class Dog extends Animal {
    @Override
    void sound() { System.out.println("Bark"); }
}
```

**Abstraction** — hide complexity, show only essentials:

```java
// Using interface
interface Payment {
    void pay(Double amount); // no implementation
}
class UPIPayment implements Payment {
    public void pay(Double amount) {
        System.out.println("Paid via UPI: " + amount);
    }
}
```

> **Interview tip:** Java is not 100% OOP because it has primitive types like `int`, `char`, `float` etc.

### 3. Method Overriding

When a subclass provides its own implementation of a method already defined in the parent class.

```java
class Animal {
    public void sound() {
        System.out.println("Animal makes sound");
    }
}
class Dog extends Animal {
    @Override
    public void sound() {
        System.out.println("Dog barks");
    }
}

// At runtime
Animal a = new Dog();
a.sound(); // prints "Dog barks" → runtime polymorphism!
```

**Rules to remember:**
- Same method name, same parameters, same return type
- Access modifier can be same or wider (never more restrictive)
- Cannot override `static`, `final`, or `private` methods

> **Trick question:** "Can we override static methods?" — No! That's called **Method Hiding**, not overriding.

### 4. Multiple Inheritance in Java

Java does **NOT** support multiple inheritance with classes because of the **Diamond Problem**:

```java
class A { void show() { System.out.println("A"); } }
class B { void show() { System.out.println("B"); } }

// This causes compile error!
class C extends A, B {} // ❌ Java gets confused which show() to call
```

**Solution — use Interfaces:**

```java
interface A {
    default void show() { System.out.println("A"); }
}
interface B {
    default void show() { System.out.println("B"); }
}
class C implements A, B {
    @Override
    public void show() {
        System.out.println("C"); // must override to resolve conflict
        A.super.show(); // can still call specific interface method
        B.super.show();
    }
}
```

> **Key answer:** "Java avoids multiple inheritance with classes to prevent the Diamond Problem, but achieves it through interfaces where the implementing class must resolve any conflicts."

### 5. Checked vs Unchecked Exceptions

**Checked Exception** — compiler forces you to handle it. Use when the caller can recover from the error:

```java
// Extends Exception
class InsufficientFundsException extends Exception {
    public InsufficientFundsException(String msg) {
        super(msg);
    }
}

// Usage — must handle!
public void withdraw(Double amount) throws InsufficientFundsException {
    if (balance < amount)
        throw new InsufficientFundsException("Low balance!");
}
```

**Unchecked Exception** — runtime error, no forced handling. Use when it's a programming mistake:

```java
// Extends RuntimeException
class InvalidMerchantException extends RuntimeException {
    public InvalidMerchantException(String msg) {
        super(msg);
    }
}

// Usage — no need to declare throws
public void process(String merchantId) {
    if (merchantId == null)
        throw new InvalidMerchantException("Merchant ID is null!");
}
```

| | Checked | Unchecked |
|---|---|---|
| Extends | `Exception` | `RuntimeException` |
| Handling | Mandatory | Optional |
| When to use | External factors (file, DB, network) | Programming bugs |

### 6. ArrayList vs LinkedList

**ArrayList** is backed by a dynamic array — great for reading:

```java
List<String> list = new ArrayList<>();
list.add("A");
list.get(0); // O(1) - direct index access, very fast!
```

**LinkedList** is backed by a doubly linked list — great for inserting/deleting:

```java
LinkedList<String> list = new LinkedList<>();
list.add("A");
list.addFirst("B"); // O(1) - just update pointers, very fast!
list.get(0);        // O(n) - must traverse from start, slow!
```

| | ArrayList | LinkedList |
|---|---|---|
| Access by index | O(1) fast | O(n) slow |
| Insert/Delete middle | O(n) slow | O(1) fast |
| Memory | Less | More (stores pointers) |
| Use when | Read heavy | Write/Insert heavy |

> **Interview tip:** "In most real cases, ArrayList is preferred because CPU cache works better with contiguous memory — making it faster even for some insertions."

### 7. HashMap Internal Working

HashMap uses an **array of buckets** internally. Each bucket holds a linked list (or tree in Java 8+).

**How `put(key, value)` works:**

```java
map.put("merchant", "IRCTC");
```

1. Calls `"merchant".hashCode()` → gets a number
2. That number is used to find the bucket index
3. If bucket is empty → insert directly
4. If bucket has items → check using `.equals()`
   - Same key → update value
   - Different key → add to chain (collision!)

**Java 8 improvement:**
- If chain length > 8 → converts LinkedList to Red-Black Tree
- This improves worst case from O(n) to O(log n)

**Resizing:**
- Default capacity = 16
- Load factor = 0.75
- When entries > 16 × 0.75 = 12 → HashMap doubles size and rehashes

> **Critical rule:** "If you override `equals()`, you MUST override `hashCode()` too — otherwise HashMap will break and you'll never find your keys!"

### 8. What is Spring Boot

Spring Boot is built on top of Spring framework and removes all the painful configuration that Spring required.

**Traditional Spring problems:**
- Tons of XML configuration
- Had to set up external Tomcat server
- Complex dependency management

**Spring Boot solves all of this:**

```java
@SpringBootApplication // just this one annotation bootstraps everything!
public class MyApp {
    public static void main(String[] args) {
        SpringApplication.run(MyApp.class, args);
    }
}
```

**Key annotations:**

```java
@RestController    // this class handles REST API requests
@RequestMapping    // maps URL paths
@Autowired         // injects dependencies automatically
@Service           // business logic layer
@Repository        // database layer
```

**Architecture always flows like this:**

```
Request → Controller → Service → Repository → Database
```

> **Key answer:** "Spring Boot follows Convention over Configuration — it auto-configures everything based on what dependencies you add, so developers focus on business logic not setup."

### 9. Merchant API — Build an API to Credit Amount

```java
// 1. Request DTO
public class TransactionRequest {
    @NotNull
    private String merchantAccountNumber;
    @NotNull @Positive
    private Double amount;
}

// 2. Entity
@Entity
public class Transaction {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String merchantAccountNumber;
    private Double amount;
    private String status;
    private LocalDateTime createdAt;
}

// 3. Service
@Service
public class TransactionService {
    @Autowired
    private TransactionRepository repository;

    public Transaction createTransaction(TransactionRequest req) {
        Transaction txn = new Transaction();
        txn.setMerchantAccountNumber(req.getMerchantAccountNumber());
        txn.setAmount(req.getAmount());
        txn.setStatus("SUCCESS");
        txn.setCreatedAt(LocalDateTime.now());
        return repository.save(txn);
    }
}

// 4. Controller
@RestController
@RequestMapping("/api/transactions")
public class TransactionController {
    @Autowired
    private TransactionService service;

    @PostMapping("/create")
    public ResponseEntity<Transaction> create(
        @RequestBody @Valid TransactionRequest req) {
        return ResponseEntity
            .status(HttpStatus.CREATED)
            .body(service.createTransaction(req));
    }
}
```

### 10 & 11. Thread Safety — Multiple Merchants & Concurrent Updates

The key insight here is — IRCTC transactions should block only IRCTC, not Amazon or Flipkart. So we lock at **merchant level**, not globally.

```java
@Service
public class TransactionService {
    // One lock per merchant
    private final ConcurrentHashMap<String, ReentrantLock>
        merchantLocks = new ConcurrentHashMap<>();

    public Transaction createTransaction(TransactionRequest req) {
        String merchantId = req.getMerchantAccountNumber();

        // Get existing lock or create new one for this merchant
        ReentrantLock lock = merchantLocks.computeIfAbsent(
            merchantId, k -> new ReentrantLock()
        );

        lock.lock();
        try {
            // Read FRESH balance after acquiring lock
            Merchant merchant = merchantRepository.findById(merchantId);
            merchant.setBalance(merchant.getBalance() + req.getAmount());
            merchantRepository.save(merchant);
        } finally {
            lock.unlock(); // ALWAYS unlock in finally block!
        }
    }
}
```

**What happens when two people pay same merchant simultaneously:**

```
Thread 1 → acquires lock for IRCTC 🔒
           reads balance = 10,000
           adds 1,000 → saves 11,000
           releases lock 🔓

Thread 2 → was waiting ⏳
           now acquires lock 🔒
           reads FRESH balance = 11,000 ✅
           adds 1,000 → saves 12,000 ✅
           releases lock 🔓

Final = 12,000 ✅ Correct!
```

**Extra DB level safety using Optimistic Locking:**

```java
@Entity
public class Merchant {
    @Version
    private Long version; // DB throws error if stale update sneaks through
}
```

### 12. What is Hibernate

Hibernate is an **ORM (Object Relational Mapping)** framework. It maps your Java classes directly to database tables so you never write raw SQL.

```java
// Without Hibernate — painful!
Connection con = DriverManager.getConnection(url, user, pass);
PreparedStatement ps = con.prepareStatement(
    "INSERT INTO merchant(name, balance) VALUES (?,?)");
ps.setString(1, merchant.getName());
ps.setDouble(2, merchant.getBalance());
ps.executeUpdate();

// With Hibernate — just this!
session.save(merchant); // ✅
```

**Caching — very important:**

```
1st Level Cache → per Session, always ON by default
                  same query in same session → won't hit DB twice

2nd Level Cache → across all Sessions, must enable manually
                  uses Redis or EhCache
```

**Lazy vs Eager Loading:**

```java
// Lazy (DEFAULT) — loads related data only when you access it
@OneToMany(fetch = FetchType.LAZY)
private List<Transaction> transactions;

// Eager — loads everything immediately with parent
@OneToMany(fetch = FetchType.EAGER)
private List<Transaction> transactions;
```

Always prefer **Lazy** — Eager can cause performance issues by loading unnecessary data.

**N+1 Problem:**

```
Fetching 10 merchants = 1 query
Then fetching each merchant's transactions = 10 more queries
Total = 11 queries ❌ Very bad!
```

Fix: use `JOIN FETCH` in your query to get everything in 1 query ✅

### 13. Where Are Authentication Tokens Stored

```
ACCESS TOKEN
├── Lives in → Memory (JS variable) or HttpOnly Cookie
├── TTL → Short (15 mins to 1 hour)
├── Used for → Sent with every API request
└── Server stores in Redis to validate session

REFRESH TOKEN
├── Lives in → HttpOnly Cookie (secure, JS cannot read it)
├── TTL → Long (7 to 30 days)
├── Used for → Getting a new access token when old one expires
└── Server stores in Redis/DB with TTL

BEARER TOKEN
├── Sent in → Authorization header of every request
├── Format → "Bearer <token>"
└── Used for → Proving identity to protected APIs
```

> **Critical point:** "Never store tokens in `localStorage` — it's vulnerable to XSS attacks. Always use HttpOnly Cookies which JavaScript cannot access at all."

### 14. String `intern()` — s1==s2 and s2==s3

```java
String s1 = new String("ABC"); // creates object in HEAP
String s2 = s1.intern();       // looks up String Pool, returns pool reference
String s3 = "ABC";             // directly points to String Pool

System.out.println(s1 == s2); // FALSE ❌ (s1=heap, s2=pool)
System.out.println(s2 == s3); // TRUE  ✅ (both point to pool)
```

**Memory picture:**

```
Heap Memory          String Pool
┌──────────┐        ┌──────────┐
│ s1="ABC" │        │  "ABC"   │ ← s2 and s3 both point here
└──────────┘        └──────────┘
```

Remember: `==` compares references (memory address), `.equals()` compares actual content. `s1.equals(s2)` would be TRUE for all three!

### 15. Method Overloading with `null`

```java
public static void print(Object o) {
    System.out.println("Object method");
}
public static void print(String s) {
    System.out.println("String method");
}

public static void main(String[] args) {
    print(null); // Output → "String method" ✅
}
```

**Why String wins:**

```
Object
  └── String  ← String is child of Object
                Java always picks the most specific type
                So String wins over Object!
```

**Tricky follow up — what if you add Integer too:**

```java
public static void print(Integer i) {}
public static void print(String s) {}

print(null); // COMPILE ERROR ❌
// Both String and Integer are equally specific
// Java cannot decide → Ambiguous method call!
```

> **Key rule:** "Java resolves overloading at compile time and always picks the most specific applicable type in the class hierarchy."

## 🎯 Quick Cheat Sheet — Things to Remember

| Topic | One Line to Remember |
|---|---|
| Java 8 | Lambdas + Streams changed everything |
| OOP | Encapsulation, Inheritance, Polymorphism, Abstraction |
| Overriding | Same signature, child class, runtime decision |
| Multiple Inheritance | Not with classes (Diamond Problem), yes with interfaces |
| Exceptions | Checked = recoverable, Unchecked = programming bug |
| ArrayList vs LinkedList | Read = ArrayList, Write = LinkedList |
| HashMap | Array of buckets, hashCode→bucket, equals→match, tree after 8 nodes |
| Spring Boot | Auto config, embedded server, convention over configuration |
| Thread Safety | Lock per merchant using `ReentrantLock` + `ConcurrentHashMap` |
| Hibernate | ORM, 1st/2nd level cache, Lazy vs Eager, N+1 problem |
| Tokens | HttpOnly Cookie, never localStorage, Redis server side |
| `intern()` | Returns String Pool reference |
| Overloading `null` | Most specific type wins (String over Object) |


Latest Blog Posts

From HashMap to RAG — What a 15-Minute Interview Taught Me About AI Search

Building a Blazing-Fast Kanban Board UI with IndexedDB

Rakuten Java Interview Experience

Get In Touch

Let's Connect

Currently Working With

Send Message