Epic Games Backend Engineer Interview: C++, Networking, and Game Server Architecture Deep Dive

Background

Let me start with my background: 3 years of C++ game backend experience, previously at a mid-size game company doing server development, mainly working on MMO battle servers and room servers. Honestly, before interviewing at Epic Games, I was a bit nervous—their tech stack and business complexity far exceeded my previous company, and game server interviews are completely different from regular backend interviews. Network programming, state synchronization, and frame synchronization are mandatory topics. But I went for it anyway, and it turned out that with thorough preparation, it wasn't that scary.

I applied for Epic Games' Backend Engineer position, based in Cary, NC. Through a referral, it took about 3 days from application to the first round. The entire process consisted of three technical rounds plus an HR round, spanning about 3 weeks. Let me break it down in detail.

Interview Process Review

Round 1: C++ + Network Programming

The Round 1 interviewer was a young-looking guy, but you could tell from his first question that he was technically strong. He said, "This round mainly covers fundamentals, ready when you are," then dove straight into technical questions.

The first question made my heart skip a beat: "What smart pointers does C++11 have? How is shared_ptr's reference counting implemented? Is it thread-safe?" I had prepared for this—unique_ptr, shared_ptr, and weak_ptr. shared_ptr's reference counting is implemented through a control block with two counters: use_count and weak_count. Regarding thread safety, the increment and decrement of reference counts are atomic operations, so they're thread-safe; but the pointed-to object itself is not thread-safe. The interviewer followed up, "What if multiple threads simultaneously modify the object pointed to by shared_ptr?" I said you'd need to use locks or atomic operations. He nodded.

Next came hardcore network programming questions. "Explain the TCP three-way handshake. Why three times and not two?" This is a classic question, and I answered smoothly. The three-way handshake is: client sends SYN, server responds with SYN+ACK, client sends ACK. Two times won't work because the server can't confirm the client received its SYN+ACK, potentially leading to resource waste. The interviewer followed up, "What about the four-way termination? Why does TIME_WAIT wait for 2MSL?" I answered—to ensure the last ACK reaches the other side, and to let all packets from this connection disappear from the network.

Then came a question that left a deep impression: "What's the difference between epoll's LT and ET modes? Which do you use and why?" I said LT is level-triggered, notifying as long as there's data; ET is edge-triggered, notifying only once when the state changes. Our project uses ET mode for better performance, but it requires reading all data at once. The interviewer asked, "What happens if you don't finish reading data in ET mode?" I said there won't be another notification, causing data loss, so you must read in a loop. He then asked, "What if the fd is closed while reading?" I didn't answer this well—only mentioned checking return values. The interviewer added that you also need to handle EINTR and EAGAIN.

C++ also covered some low-level questions: "How are virtual functions implemented? Where is the vtable stored?" I said virtual functions are implemented through a vtable—each class with virtual functions has a vtable, and objects store a vptr pointing to it. The vtable is typically stored in the read-only data segment. The interviewer asked, "Can constructors be virtual?" I said no, because when constructing an object, the vptr hasn't been initialized yet, so you can't find the vtable. He asked, "What about destructors?" I said they must be virtual, otherwise deleting a derived class object through a base class pointer causes memory leaks.

Round 1 ended with a coding challenge: Implement a thread-safe message queue in C++ that supports multiple producers and consumers. I used mutex + condition_variable. The interviewer reviewed it and said, "The basic functionality is fine, but how would you optimize for high performance?" I suggested using a lock-free queue or multiple queues to reduce lock contention. He said, "Good approach."

Round 1 lasted about 1 hour. The interviewer said, "Your fundamentals are solid, wait for the notification."

Round 2: Game Server Architecture + State Synchronization

The Round 2 interviewer was a senior tech expert who jumped straight into project questions. He said, "You've worked on MMO servers before—tell me about your architecture."

I drew an architecture diagram: Gateway Server → Scene Server → Battle Server → Database Server. The gateway handles connection management and message forwarding, the scene server handles AOI and movement synchronization, the battle server handles damage calculation and skill logic, and the database server handles persistence. The interviewer asked, "How does the gateway handle large numbers of connections? How many connections can a single machine support?" I said we use epoll + thread pool, supporting about 50K connections per machine. He followed up, "How do you calculate the memory overhead for 50K connections?" I said each connection uses about 4KB for read/write buffers, so 50K connections is about 200MB, plus other overhead totaling around 500MB.

State synchronization was the main event. "Do you use state synchronization or frame synchronization? Why?" I said our MMO uses state synchronization because MMOs have many players and large view ranges, making frame synchronization's bandwidth cost too high. The interviewer asked, "How do you determine the synchronization frequency? What data do you synchronize?" I said we synchronize position and state every 100ms, only for players within the view range. He followed up, "How do you calculate the view range? How is AOI implemented?" I said we use a nine-grid AOI, dividing the map into cells where players subscribe to cell messages upon entering. He asked, "How do you handle grid boundary issues?" I said players at cell boundaries simultaneously subscribe to adjacent cell messages.

Then came a very practical question: "If two players attack the same monster simultaneously, how is damage calculated? How do you ensure consistency?" I said we use a battle server for centralized calculation—all damage is determined by the battle server, then results are broadcast. The interviewer followed up, "What if the battle server goes down?" I said we have primary-backup failover where the backup takes over battle data. He asked, "What about ongoing battles during failover?" I said we do battle replay—the client caches operation sequences, which are replayed on the new server after failover. He said, "This approach works, but how do you ensure replay consistency?" I said operation sequences include timestamps and are replayed in timestamp order.

Round 2 also covered system design: "If you were to design an MMO server architecture supporting 1 million online players, how would you design it?" I said I'd use a microservices architecture—gateway cluster → scene cluster → battle cluster → data cluster, where each cluster can scale horizontally. Scene servers are partitioned by map, with each scene server responsible for one map area. The interviewer asked, "How do you handle cross-scene player interaction?" I said through a cross-server relay. He then asked, "How do you optimize cross-server latency?" I said using UDP + reliable transport protocol to reduce handshake overhead.

Round 2 lasted about 1.5 hours with very deep questions. The interviewer finally said, "Your architecture understanding is good, but some details need polishing."

Round 3: Deep Project Dive + System Design

Round 3 was with the department director. The atmosphere was more formal. He first asked about my understanding of game server development. I said, "The biggest difference between game servers and regular backends is the high requirements for real-time performance and state consistency, plus handling various network anomalies and cheating." He nodded, then started diving deep into projects.

"What's the most complex feature you've built? What technical challenges did you face?" I described a large-scale guild battle system supporting 200v200 cross-server battles. The biggest challenge was the performance of state synchronization—200 players in one scene, synchronizing state every 100ms, creating enormous bandwidth costs. Our solution: only synchronize changed data (incremental sync), prune synchronized objects by view range, and use UDP to reduce protocol overhead. The interviewer followed up, "How is incremental sync implemented? What happens if packets are lost?" I said we use sequence numbers to mark each sync, and the client requests a full sync if it detects non-consecutive sequence numbers.

Then came an open-ended system design question: "Design a leaderboard system that supports real-time updates and global ranking queries." I said I'd use Redis Sorted Sets—ZADD for score updates, ZREVRANK for ranking queries. The interviewer asked, "If there are 10 million online users, how do you optimize the leaderboard?" I suggested skip lists + sharding, or approximate ranking algorithms. He then asked, "How do you ensure leaderboard real-time performance? How frequently do you update?" I said we use message queues for async updates, refreshing the leaderboard once per second.

Finally, he asked about my thoughts on Epic Games and career plans. I said Epic Games is the top game company with challenging tech stacks and business scenarios, and I hope to deepen my expertise in game server development here. The interviewer said, "Welcome aboard."

The HR round was standard salary and start date discussion—nothing special.

Real Interview Questions

Round 1 Questions

1. What C++11 smart pointers exist? shared_ptr reference counting implementation? Thread safety?
2. TCP three-way handshake process? Why three times?
3. TCP four-way termination process? Why TIME_WAIT waits 2MSL?
4. epoll LT vs ET mode differences?
5. Virtual function implementation? Where is the vtable stored?
6. Can constructors be virtual? Destructors?
7. C++ memory model? Stack vs heap differences?
8. What does std::move do? Perfect forwarding?
9. Implement a thread-safe message queue in C++
10. How to handle TCP packet sticking?

Round 2 Questions

1. MMO server architecture design
2. How does the gateway handle large numbers of connections?
3. State sync vs frame sync? Pros and cons of each?
4. How to implement AOI? Nine-grid approach?
5. Two players attacking the same monster simultaneously—damage calculation?
6. Battle server down—what to do? Primary-backup failover?
7. Design an MMO server architecture for 1M online players
8. Cross-scene player interaction handling?
9. How to implement reliable UDP transport?
10. Where are the performance bottlenecks in game servers?

Round 3 Questions

1. Most complex feature and technical challenges
2. State synchronization for large-scale guild battles
3. How to implement incremental sync? Packet loss handling?
4. Design a leaderboard system (real-time updates + global ranking)
5. Leaderboard optimization for 10M online users
6. Differences between game servers and regular backends
7. How to handle player cheating?
8. How to do server hot updates?
9. Your thoughts on Epic Games
10. Career plans

Key Takeaways

First, C++ fundamentals must be solid. Epic Games' interview demands high C++ proficiency—not just "knowing how to use it" but understanding underlying principles. Smart pointers, virtual functions, and memory models are mandatory topics. I recommend studying "C++ Primer" and "Effective C++" in depth.

Second, network programming is the core of game server development. TCP/UDP differences, epoll usage, and packet sticking handling must be mastered. I recommend writing a simple network framework for practice and understanding epoll's LT and ET modes.

Third, deeply understand state synchronization and frame synchronization. These are high-frequency topics in game server interviews. You need to explain not just concepts but also analyze pros, cons, and applicable scenarios. I recommend studying open-source game server projects like KBEngine.

Fourth, project experience should have highlights. Epic Games interviews value project depth—not what features you built, but what problems you encountered and how you solved them. Pick 1-2 technically challenging projects and explain the optimization process clearly.

Fifth, system design capability is important. Round 3 tests system design—not template questions like "design a XX system" but design questions integrated with game scenarios. I recommend learning about the evolution of game server architectures, from monolithic to microservices.

FAQ

Q1: How deep does Epic Games' C++ interview go?

Very deep. It's not about knowing how to use STL—you need to understand underlying implementation principles. I recommend reading through STL source code at least once, understanding the underlying implementations of vector, map, and unordered_map.

Q2: What if I don't have game server experience?

You can build a simple game server for practice. For example, implement a chat room server (network programming) + a simple battle system (state synchronization). The key is understanding game servers' unique requirements: real-time performance, state consistency, and high concurrency.

Q3: Frame sync or state sync—which should I learn?

Both. Epic Games' MMOs use state sync, MOBAs use frame sync—both may come up in interviews. I recommend learning state sync first (more general), then frame sync (more complex).

Q4: Do game server interviews test algorithms?

Yes, but not LeetCode-style. More game-scenario-related algorithms like AOI algorithms, pathfinding algorithms, and collision detection. I recommend focusing on AOI and A* pathfinding.

Q5: What's the work intensity like at Epic Games?

It depends on the project team. It gets busy before launches but is manageable otherwise. The technical atmosphere is great, and you learn a lot. The game industry overall has a fast pace, but Epic Games' technical expertise and engineering standards are top-notch.