What I Learned from My 3 Rounds of ByteDance Interviews: Real Questions & Insights

Background

I graduated with two degrees and have been working as a Java developer for four years, mainly at second‑tier companies. After three job changes and a short break, I started interviewing in mid‑May. Frequent job hopping made internal referrals difficult, and I finally got an interview for a Java position in ByteDance's advertising department.

First Interview

The first interview lasted about 30 minutes, with a brief technical part and a quick algorithm question.

Project introduction: I gave a brief overview, which the interviewer skipped.

Redis ZSET implementation: Explained ziplist, dict, and skiplist, and why skip‑list is used.

Redis persistence: Mentioned RDB and AOF; the interviewer moved on quickly.

Redis clustering: Described sentinel with master‑slave and Redis Cluster for scalability.

MySQL InnoDB and MongoDB index structures: Summarized B‑tree basics.

RR isolation level and phantom reads: Discussed MVCC, lock usage, and why RR needs extra handling.

synchronized principle: Covered lock upgrade, monitor internals (wait‑set, entry‑list, owner, count).

Other registries: Mentioned Nacos, Eureka, Consul and their CP/AP characteristics.

Algorithm question: Started with minimum edit distance, switched to binary‑tree zigzag traversal, spent about 10 minutes.

Second Interview

This round was the toughest, mixing deep technical questions and algorithms.

Project details: Interviewer focused on server count and QPS, then moved to standard questions.

JVM deep dive: Discussed TLB, escape analysis, stack frames, metaspace vs. PermGen, and GC behavior.

Redis AOF handling: I was unfamiliar and could not answer well.

Message queues: Mentioned using RocketMQ (cluster and broadcast modes) and briefly explained dead‑letter queues.

Exchange concepts: Admitted limited experience with RabbitMQ.

ACK mechanism, offset movement, broker replication: Gave shallow answers.

MySQL index optimization and EXPLAIN: Talked about optimizer strategies, then clarified that EXPLAIN does not execute the query.

Two‑phase commit and undo log: Described binlog, redo log, and undo log behavior.

Algorithm: Solved a string‑concatenation problem but failed to produce a correct solution.

Third Interview

The final interview mixed casual chat, technical discussion, and a short algorithm.

Java network I/O stream: Mentioned ring buffers, DMA, soft/hard interrupts.

Zero‑copy: Briefly covered sendfile and mmap.

FTP vs. HTTP: Skipped due to lack of experience.

Protocol for file download: Said UDP is often used for NAT traversal.

Close‑wait vs. time‑wait: Accidentally reversed the explanation.

Keeping long connections: Explained keep‑alive to avoid repeated FD creation.

Log collection at scale: Suggested Kafka, then MapReduce for multi‑machine processing.

Real‑time processing: Mentioned Flink and Spark but admitted no hands‑on experience.

Algorithm – three‑character combinations: Implemented a three‑level for‑loop; interviewer noted the simplistic approach.

Conclusion

The interview process was fast‑paced, especially the algorithm portions, and I felt my performance suffered due to nervousness and lack of preparation for non‑standard questions. Despite reaching the third round, I ultimately did not receive an offer. The experience highlighted the importance of concise, well‑structured answers and solid algorithm fundamentals for future ByteDance candidates.