What ByteDance Interviewers Really Ask: A Detailed Backend Interview Walkthrough

Background

I graduated with two degrees and have four years of Java experience, mainly at second‑tier companies. After three job changes and a short break, I started interviewing in mid‑May. Frequent moves and the off‑season caused many internal referrals to fail, but I finally secured a Java advertising/marketing interview at ByteDance.

First Round

The interviewer was a shy junior; the technical part lasted about 20 minutes and the algorithm question took roughly 10 minutes. The Q&A covered:

Project overview : I gave a brief description and the interview moved on.

Redis ZSET implementation : based on ziplist, dict, and skiplist; explained why skiplist is used.

Redis persistence : RDB and AOF; the interviewer limited further discussion.

Redis clustering : sentinel with master‑slave for reliability, Redis Cluster for scalability.

Cluster communication : mentioned go‑osip but skipped details.

MySQL InnoDB and MongoDB index structures : B‑tree, brief explanation.

RR isolation level and phantom reads : described locking, snapshot reads, and why RR needs extra handling.

synchronized implementation : lock upgrade process and monitor internals (wait set, entry list, owner, count).

Service discovery : used Nacos, Eureka, Consul; noted CP vs AP differences.

Algorithm question : started with minimum edit distance, switched to binary‑tree zigzag traversal.

Summary: the pace was very fast; concise answers were essential.

Second Round

This round split into technical (25 min) and algorithm (25 min) sections. Topics included:

Project details: server count, QPS, brief.

Java/JVM deep dive: TLB, escape analysis, stack‑frame contents.

Metaspace vs PermGen.

System.gc() behavior and full GC relationship.

Redis AOF file size handling and rewrite command (unknown to me).

Message‑queue experience: only RocketMQ (cluster and broadcast), dead‑letter queue.

Exchange concept (confused with RabbitMQ).

ACK mechanism, offset movement, broker replication (shallow answer).

MySQL index optimization and EXPLAIN usage (misunderstood the question).

EXPLAIN does not execute SQL.

Two‑phase commit discussion (binlog, redo log, grouping).

Undo log and rollback behavior.

Algorithm: string concatenation problem (failed to solve).

Summary: many answers were superficial; the algorithm portion caused failure.

Third Round

The interview consisted of chat (10 min), technical (10 min), and algorithm (5 min). Questions were:

Java network I/O stream creation and underlying OS/network mechanisms (ring buffer, DMA, interrupts).

Zero‑copy (sendfile, mmap).

FTP vs HTTP (skipped).

File‑download protocol choice (UDP vs TCP, mentioned NAT traversal).

Close‑WAIT vs TIME‑WAIT (confused the two).

Keeping long connections (keep‑alive).

Log collection at scale (Kafka, MapReduce).

Real‑time processing (mentioned Flink, Spark, not used).

Algorithm: generate all three‑character combinations from a string (implemented three nested loops).

Summary: questions felt random; the final algorithm question led to rejection.

Overall Summary

The interview process was fast and intense. Preparing concise answers and solid algorithm practice is crucial. Despite reaching the third round, the candidate was ultimately not selected.