What to Expect in the CD Projekt Red System Design Interview

Public sources do not show a system design round at CD Projekt Red in the form large technology companies run it. No candidate report describes an hour spent designing a distributed web service. The studio publishes its hiring as four steps, and the technical screening happens in a test assignment and an interview with senior programmers. Candidates report a C++ coding challenge, a take-home task, and a call covering C++, programming fundamentals, and live coding. Architecture is still judged, but inside those rounds: the subjects are engine systems, gameplay systems, and performance in a large open world, not load balancers and database replicas.

What Replaces the System Design Round

CD Projekt Red makes story-driven role-playing games, so its engineering problems are game problems. The studio builds its new projects in Unreal Engine 5, in a technology partnership with Epic Games. Its programmers extend that engine for very large open worlds, and published work covers world streaming, crowds, animation, and dense foliage. An architecture question here concerns memory, frame time, and tools for the content team. Frame time is the number of milliseconds available to draw one frame, and that limit is fixed.

The Test Assignment Is Where Architecture Is Judged

The studio says some roles need an assignment, because it wants to see specific skills used in action. Candidate reports give deadlines of five days, one week, and two weeks. One programming candidate reported five C++ tasks at easy to medium difficulty. A quest designer reported a game demo task with two weeks to finish it. Your design decisions are visible in that submission, so make each one deliberate. Write modern C++, keep the structure clear, add tests where they help, and include a short note on what you would add with more time.

The Technical Interview

Candidates report a call with senior technical staff, sometimes with two lead programmers present, covering C++, programming fundamentals, and a live coding exercise. Reported questions include move semantics and which modern C++ features you use. Move semantics is the C++ feature that transfers ownership of data instead of copying it. Expect follow-up questions about cost: memory layout, allocation, and threading. State the cost of each choice out loud as you write.

Engine and Gameplay Architecture Topics

The studio's own job ads for engine roles name the areas it works in: fluent C++, professional Unreal Engine knowledge, data structures, streaming workflows, multithreaded programming, and low level profiling. Reported interview questions match those areas. Wider subjects such as open world performance and dialogue tools appear on third party question lists, not in candidate reports, so treat them as likely topics rather than confirmed questions.

A Walkthrough: Design a Dialogue System for an RPG

A dialogue system is a central problem in a story-driven role-playing game, so it makes a fair rehearsal. No candidate report names it as an interview question here. The plan below is high level.

1. Requirements (about five minutes). Thousands of conversations, many languages, full voice acting, and player choices that change later scenes. Writers, not programmers, must author the content.

2. Data model. A conversation is a graph of lines and choices, and a graph is a set of nodes joined by links. Each node holds one line, a speaker, its conditions, and the effects it applies.

3. Authoring and build. Writers work in a tool that exports data, not code. The build step validates every node, checks that every voice file exists, and reports an error when a link is broken.

4. Runtime. Load only the conversations near the player, evaluate conditions against the saved game state, and stream the audio for the current line and the next one, so playback never pauses.

5. Choice and consequence. Store player decisions as flags in the save file, with names that do not change when you patch the game. Define a default for every missing flag, because old saves must still load.

6. Localization and limits. Line length differs by language, so lay out subtitles for the longest case. Cap the conditions checked per node, and profile that cost per frame.

7. Failure cases. A missing voice file, a cut line, or a damaged save must not crash the game. Define the fallback for each one before the interviewer asks.

What the Interviewer Grades

Practical judgment counts for more than a large diagram. State the constraints first, including memory, frame time, and the workflow of the content team. Name the trade-off in each choice, and say who pays for it: the player, the writer, or the artist. Interviewers here work on shipped games, so they will ask what broke on your last project. One specific failure, described honestly, scores better than a flawless story.

Common Mistakes

• Answering with web architecture. Load balancers and sharded databases are the wrong vocabulary for a gameplay role. Online services do exist in the studio's games, but the default subject is the game client.
• Ignoring the content team. Designers and writers use your system every day. A design that only a programmer can operate fails.
• Skipping the budget. Every answer needs a number for memory or for frame time.
• No failure plan. Shipped games handle missing assets and old save files, so say how yours does.
• Overstating engine knowledge. Honesty is one of the studio's stated values, and a live coding exercise shows a guess quickly.

How to Prepare

• Build the design vocabulary. Grokking the System Design Interview teaches how to state requirements and trade-offs, which transfers directly to an engine discussion.
• Practice failure handling. Advanced System Design Interview, Volume II covers isolation and recovery, both of which appear in game tools and online features.
• Rehearse the walkthrough. Say the seven steps above out loud in under 30 minutes.
• See where this round sits. Read what the CD Projekt Red interview process is like, prepare the motivation question, and check the waiting times after each stage.