Comprehensive Java Backend Interview Guide: Data Structures, JVM, MySQL, Redis, and Performance Optimization

First Look at Questions

Self‑introduction

Describe a project you consider challenging

How do you learn Java?

Explain abstract classes and interfaces

Compare HashMap and Hashtable

Process of adding an element to a HashMap

What is a Red‑Black tree and its features?

Characteristics of B+‑tree, its levels and maximum capacity

Why MySQL indexes use B+‑tree instead of skip‑list?

Why Redis uses skip‑list instead of B+‑tree or binary tree?

Things to note when creating indexes

How to optimize a table with tens of millions of rows

Fast query for a range of rows from two large tables joined by a foreign key

JVM memory model

Why a Survivor space is needed

Any questions you want to ask the interviewer?

Question Analysis

Self‑introduction

A good self‑introduction should cover who you are, your strengths, work experience, any awards, deep‑dive technologies, high‑concurrency system design experience, and involvement in large projects, highlighting the most relevant strengths for the position.

Describe a challenging project

For junior candidates, a simple project implementation can be considered challenging; for senior candidates, the challenge often lies in project packaging, stakeholder management, and solving problems the interviewer has not encountered. Emphasize large data volume, high concurrency, and architectural refactoring to raise the project’s level.

How do you learn Java?

Show a proactive learning habit: read official documentation, books, and videos; take notes; practice constantly; reflect and summarize.

Abstract classes vs. interfaces

Abstract classes are extended; interfaces are implemented.

Abstract classes can have constructors; interfaces cannot.

Abstract classes can contain ordinary fields; interface fields are public static final constants.

A class can implement multiple interfaces but extend only one (which may be abstract).

Abstract classes may contain both method declarations and implementations; interfaces may have default methods.

Hierarchy: interface > abstract class > concrete class.

Keywords: abstract for classes, interface for interfaces.

HashMap vs. Hashtable

Key differences:

Thread safety: Hashtable is synchronized; HashMap is not (use ConcurrentHashMap for thread safety).

Performance: HashMap is faster due to lack of synchronization.

Null support: HashMap allows one null key and multiple null values; Hashtable rejects null keys/values.

Initial capacity and growth: Hashtable defaults to 11 and grows by 2n+1; HashMap defaults to 16 and doubles each resize. When a custom capacity is supplied, Hashtable uses it directly, while HashMap rounds it to the nearest power of two using tableSizeFor().

Underlying structure: Since JDK 8, HashMap converts long collision chains (>8) into red‑black trees; Hashtable never does.

Adding an element to a HashMap

The put() call delegates to putVal() and follows these steps:

Resize if the internal table is null.

Compute index via hash & (length‑1).

If the slot is empty, insert a new node.

If the key exists, replace the value and return the old one.

If the bucket is a tree, insert using tree logic.

If it is a linked list, traverse the list.

Insert at the end of the list if the next node is null.

If the list length exceeds 8, convert it to a red‑black tree.

Resize if the table is empty or its length is below the tree‑conversion threshold (64).

Red‑Black tree

A balanced binary search tree with five properties: each node is red or black; the root is black; all leaves (NIL) are black; red nodes cannot have red children; every path from a node to its descendant leaves contains the same number of black nodes.

B+‑tree characteristics

Non‑leaf nodes store only keys (index role); leaf nodes store keys and values and are linked in order. Typically a three‑level tree. In InnoDB a page is 16 KB; with a 1 KB record, a leaf page holds ~16 rows. An index entry of int(4B)+pointer(6B) fits ~1638 entries per page. Thus:

Two‑level B+‑tree capacity ≈ 16 × 1638 = 26 208 records.

Three‑level B+‑tree capacity ≈ 16 × 1638 × 1638 ≈ 42 928 704 records.

Why MySQL indexes use B+‑tree instead of skip‑list?

B+‑tree is a multi‑branch tree where each node corresponds to a 16 KB disk page, giving a high fan‑out and typically only three I/O operations to locate a record. Skip‑list would need ~24 levels, resulting in ~24 I/O operations for the same data size, making B+‑tree faster for reads. However, skip‑list writes are cheaper because they avoid page splits and rebalancing.

Why Redis uses skip‑list instead of B+‑tree or binary tree?

Redis stores data in memory, so disk‑I/O concerns disappear. Skip‑list provides ordered traversal with O(log N) average search, while B+‑tree’s advantage of reducing disk reads is irrelevant in memory.

Creating indexes – what to watch out for

Index columns that appear in WHERE clauses or join conditions, not merely in SELECT.

Higher cardinality yields better selectivity.

Use composite indexes when queries filter on multiple columns.

Avoid excessive indexes; they increase storage and slow writes.

Prefer short primary‑key types to reduce index size.

For string columns, define a prefix length to save space.

Optimizing tables with tens of millions of rows

Design considerations: limit column count, create targeted indexes, use EXPLAIN to verify index usage, choose appropriate data types, and avoid SELECT *. Use pagination with reasonable LIMIT. Enable slow‑query logs to find bottlenecks.

Storage engine choice: InnoDB for write‑heavy workloads, MyISAM for read‑heavy workloads.

Scaling strategies: read/write splitting, sharding (horizontal or vertical), but sharding adds significant development cost and should be planned early.

Hardware upgrades or migrating to cloud‑native distributed databases (e.g., PolarDB) can also improve performance.

Fast range query on two large tables joined by a foreign key

Method 1 (continuous tid in table a):

select * from a, b where a.tid = b.id and a.tid > 500000 limit 200;

Method 2 (non‑continuous tid): use a covering index and sub‑query:

select * from b, (select tid from a limit 50000,200) a where b.id = a.tid;

JVM memory model

Components: Program Counter register, Heap (young and old generations), Method Area (class metadata, constants, static variables), Java stack, and native method stack.

Young generation is split into Eden, From‑Survivor, and To‑Survivor spaces, typically in an 8:1:1 ratio.

Why a Survivor space is needed?

Without Survivor spaces, every object surviving a Minor GC would be promoted directly to the old generation, causing frequent and costly Full GCs. Survivor spaces act as a filter, allowing only objects that survive many Minor GCs to be promoted, thus reducing Full GC frequency.

Any questions for the interviewer?

Ask about training programs, promotion paths, or technical challenges to demonstrate enthusiasm and fit.