What I Learned From My Go Backend Engineer Interview at Tencent

After six months of preparation and filling gaps in MySQL, Redis, and distributed systems, I regained confidence and attended an interview at Tencent (referred to as “Goose Factory”).

Tencent

Interview position: Go backend development engineer, transitioning from Java.

The company focuses heavily on C++ and expects strong OS and networking knowledge, unlike Java‑centric roles that emphasize data structures, frameworks, and databases.

First round: Basic technical interview

The phone interview covered a range of topics, ending with a medium‑level LeetCode problem.

Redis: data structures, usage scenarios, hash implementation, rehash process vs. Java HashMap, cluster high‑availability, persistence limitations.

TCP/UDP: definitions, three‑way handshake, four‑way termination, ordered transmission, fast retransmit, congestion control, TIME_WAIT and its relevance to QUIC.

Design a reliable algorithm over UDP.

Differences between HTTP and HTTPS, HTTPS handshake process.

etcd: purpose, high‑availability, consistency mechanisms.

Raft algorithm basics, handling split‑brain, comparison with Paxos and Zookeeper ZAB.

Database persistence, sharding, partitioning strategies.

Index implementations, MySQL storage engines, InnoDB indexing, clustered vs. non‑clustered indexes.

Coroutines vs. threads.

Offer problem: find duplicate numbers in an array.

My answers: Redis concepts were solid; I recalled progressive rehash but missed some details. TCP TIME_WAIT explanation was weak, and I lacked knowledge of QUIC. HTTPS discussion was adequate. Raft answer was passable, though I was unfamiliar with Paxos and ZAB. My MySQL knowledge, including indexes, locks, MVCC, was strong. I explained Go goroutine vs. Java thread differences, noting user‑mode scheduling.

Second round: Project technical interview

Describe project architecture, data models, technology stack, peak QPS, latency analysis, and potential improvements.

How to locate issues when a request hangs.

Handling TCP packet sticking (粘包).

Cache update patterns, problems, and mitigation strategies.

Contributions to well‑known projects beyond the company.

The discussion was smooth; the only critique was that my project experience seemed slightly weak.

Third round: Comprehensive technical interview

The interview became chaotic, with deep OS questions that exposed gaps in my knowledge, such as the cost of thread‑vs‑goroutine switching and kernel‑mode vs. user‑mode transitions.

Additional topics included diagnosing a server CPU at 100 % (using top to find the offending process and thread, then examining stack traces) and a system‑design question about designing a social‑feed service, where I initially presented a generic architecture without tailoring it to read‑heavy workloads.

Summary

Master TCP/UDP, HTTP/HTTPS, and networking models (select, poll, epoll).

Have concrete project experience you can discuss in depth, including design trade‑offs and data modeling.

Be proficient with distributed systems concepts.

Develop clear problem‑diagnosis methodologies.

Operating system fundamentals are crucial—study them repeatedly.

System‑design thinking must be structured and clear.

Regularly reflect on and synthesize knowledge from blogs and articles rather than merely consuming them.