Why the Second Question in My SF Interview Made Me Walk Away
The article shares a detailed SF interview experience, covering typical Java interview questions such as self‑introduction, challenging projects, learning paths, abstract class vs interface, HashMap vs Hashtable, insertion steps, red‑black and B+ trees, MySQL and Redis indexing choices, large‑table optimization, JVM memory model, and the purpose of the Survivor space.
Interview Questions Overview
Self‑introduction
Describe a challenging project
How you learn Java
Abstract class vs interface
HashMap vs Hashtable
HashMap element‑addition process
Red‑Black tree characteristics
B+ tree features, layers, capacity
Why MySQL uses B+ trees instead of skip‑lists
Why Redis uses skip‑lists instead of B+ or binary trees
Index creation considerations
Optimizing tables with tens of millions of rows
Fast query for two large tables with a foreign key
JVM memory model
Purpose of the Survivor space
Self‑Introduction
A good self‑introduction should state who you are, your strengths, work experience, awards, technical depth, high‑concurrency or architecture redesign experience, and teamwork.
How to Describe a Challenging Project
For beginners, any project feels challenging; for senior engineers, "challenge" often means how you package the project to impress the interviewer. A project is considered challenging if the interviewer is unfamiliar with its business or technical points, allowing you to showcase solutions they haven't seen.
Key characteristics of a challenging project:
Large data volume
High concurrency
Architecture redesign
Use the following template when answering:
1. I was responsible for the xxx business project, which does xxx. 2. In the early stage we used a simple xxxx solution to iterate quickly. 3. As the business grew, the solution showed xxx technical problems. 4. To solve these issues we adopted xxx solution, comparing alternatives and explaining why it resolved the problems.
Learning Java
Describe your learning journey honestly, emphasizing proactive learning, note‑taking, and continuous practice. Recommended resources include official documentation, books, and videos.
Abstract Class vs Interface
Similarities: Both cannot be instantiated directly; implementing classes must provide method implementations.
Differences:
Interfaces only declare methods (default methods allowed since JDK 8); abstract classes can provide implementations.
Implementation uses implements, inheritance uses extends. A class can implement multiple interfaces but extend only one abstract class.
Interfaces express a capability, abstract classes express an inheritance relationship.
Interface fields are public static final and must be initialized; abstract class fields have default visibility and can be reassigned.
HashMap vs Hashtable
Thread safety: HashMap is not thread‑safe; Hashtable is synchronized (use ConcurrentHashMap for thread safety).
Performance: HashMap is generally faster; Hashtable is largely deprecated.
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 to 2n+1; HashMap defaults to 16 and doubles.
Resize behavior: When a capacity is specified, Hashtable uses it directly; HashMap rounds it to the next power of two via tableSizeFor().
Internal structure: Since JDK 8, HashMap converts long chains (>8) to red‑black trees (if array length > 64); Hashtable never does this.
Although this question is now common, many interviewees still answer poorly; interviewers often probe deeper into hash‑related details.
HashMap Element‑Addition Process
The put operation follows nine steps:
Call putVal().
If the table is empty, trigger resize.
Compute index via (hash & (length‑1)); if 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 a collision occurs in a list, enter collision‑handling loop.
During the loop, if the next node is null, insert the new node.
After insertion, if the list length exceeds 8, convert it to a red‑black tree.
If the table is null or its length < 64, perform resize; otherwise, continue inserting into the tree.
Red‑Black Tree
A specialized balanced binary tree with five properties:
Each node is red or black.
The root is black.
All leaves (NIL nodes) are black.
Red nodes cannot have red children.
Every path from a node to its descendant leaves contains the same number of black nodes.
Interviewers may ask about rotations; few can answer confidently.
B+ Tree
Features:
Non‑leaf nodes store only keys (index), no values.
All leaf nodes form an ordered linked list for range scans.
Typical depth: 1–3 levels. Assuming a 16 KB page size:
1 KB record → 16 records per page.
4 B int key + 6 B pointer → ~1638 entries per index page.
Capacity examples:
2‑level B+ tree: 16 × 1638 = 26208 records.
3‑level B+ tree: 16 × 1638 × 1638 ≈ 42 928 704 records.
Why MySQL Uses B+ Trees Instead of Skip‑Lists
B+ trees are multi‑branch structures with 16 KB pages, giving a high fan‑out; a three‑level tree requires at most three disk I/Os per lookup.
Skip‑lists are linked‑list based; a 2 KB dataset would need about 24 levels, potentially causing up to 24 disk I/Os. Hence B+ trees have fewer I/Os and faster reads.
For writes, skip‑lists avoid page splits and rebalancing, so they can have better write performance than B+ trees.
MySQL storage engines (MyISAM, InnoDB) both use B+ trees for indexes, but engines like Facebook's RocksDB employ skip‑lists, offering superior write speed at the cost of read performance.
Why Redis Uses Skip‑Lists Instead of B+ Trees or Binary Trees
Redis operates entirely in memory, so disk‑I/O concerns that motivate B+ trees disappear. Skip‑lists provide ordered access with logarithmic search time without the overhead of maintaining balanced tree structures.
Index Creation Tips
Best columns are those used in WHERE clauses or join conditions, not merely selected columns.
Higher cardinality yields more selective indexes.
Create 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 tables with limited columns (≈20) and appropriate data types.
Build indexes on columns used in WHERE and ORDER BY, verify usage with EXPLAIN.
Avoid SELECT *; list needed columns.
Use LIMIT for pagination and keep page size reasonable.
Enable slow‑query logging to identify bottlenecks.
Choose storage engine: MyISAM for read‑heavy, InnoDB for write‑heavy workloads.
Consider sharding or partitioning only when other optimizations fail; be aware of added complexity.
Hardware upgrades or migrating to distributed databases (e.g., PolarDB) can provide further gains.
Fast Query for Two Large Tables
Method 1 (continuous tid):
select * from a,b where a.tid = b.id and a.tid > 500000 limit 200;Method 2 (non‑continuous tid): use covering indexes on tid and id:
select * from b, (select tid from a limit 50000,200) a where b.id = a.tid;JVM Memory Model
Components:
Program Counter Register – points to the next bytecode instruction.
Heap – divided into Young (Eden, From/To Survivor) and Old generations; default ratio 8:1:1.
Method Area – stores class metadata, constants, static variables (also called Non‑Heap).
Java Virtual Machine Stack – thread‑local, holds stack frames with local variables, operand stack, dynamic linking, and return address.
Native Method Stack – similar to JVM stack but for native method frames.
Why the Survivor Space Exists
Without Survivor spaces, every object surviving a Minor GC would be promoted to the Old generation, quickly filling it and triggering frequent Full GCs, which are costly. Survivor spaces act as a filter: only objects that survive ~16 Minor GCs are promoted, reducing Full GC frequency.
Interviewers may ask about the impact of long GC pauses.
Increasing Old generation size reduces promotion frequency but makes each Full GC slower; decreasing it speeds up each Full GC but increases their frequency. Survivor spaces balance this trade‑off.
Java Backend Full-Stack
Provides technical guidance, interview coaching, and tech sharing. Follow and reply '77' to receive our self-made 'Interview Cheat Sheet' and interview resources.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
