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.

Java Backend Full-Stack
Java Backend Full-Stack
Java Backend Full-Stack
Why the Second Question in My SF Interview Made Me Walk Away

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.

JavaJVMRedisMySQLinterviewHashMapData Structuresdatabases
Java Backend Full-Stack
Written by

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.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.