Articles
Unreal Engine Interview Questions: UObject Lifetimes, Gameplay Framework, and Replication
Prepare for Unreal Engine interviews with UObject reachability, gameplay state lifetimes, authority, owning connections, and replicated health reasoning.
A pickup works in a single-player test, then fails in multiplayer: the client sees an object, an RPC does nothing, and inventory state disappears after respawn. The symptoms look related, but a pointer repair alone can leave the multiplayer failure unresolved. For Unreal Engine interview questions, trace object reachability, gameplay-state lifetime, server authority, and the owning connection separately before changing code.
Official evidence: Epic documents UObject pointers, the gameplay framework, and network replication as distinct systems. This guide uses those UE5 documentation pages and an original gameplay exercise. It makes no claim about Epic Games' hiring stages or a fixed interview question set. Epic gameplay framework
Then explain how Unreal's reflected object system changes the lifetime discussion.
What makes a UObject reference safe?
A UObject is an object managed through Unreal's object system, which supports reflection and garbage collection. A pointer gives code a way to refer to the object; its pointer type and storage determine whether the engine tracks that reference.
Official fact: Epic's object-pointer guide describes a UPROPERTY-marked TObjectPtr as a strong reference for garbage collection. TWeakObjectPtr provides a non-owning reference and must be checked for validity before use. A bare TObjectPtr without the reflected property does not establish the same GC protection. Object pointers
Here is an original documentary member sketch inside a reflected UObject-derived class:
UPROPERTY()
TObjectPtr<UInventoryModel> InventoryModel;
TWeakObjectPtr<AActor> HighlightedPickup;
The intended contract is different for each field. The inventory model should remain reachable while its live owner needs it. Highlighting a pickup should not prolong that pickup's lifetime.
Before changing either field, identify the owner and whether that owner remains reachable. A strong reference inside an unreachable object is not a substitute for a valid path from a live owner. Conversely, a weak reference is appropriate when “the target may disappear” is part of the feature's contract.
The snippet omits class declarations, generated headers, and initialization. It has not been compiled or run in Unreal; its purpose is to explain the two member contracts.
Diagnose reachability instead of counting pointer variables
Official fact: Unreal's object-handling documentation explains that an untracked raw object pointer does not prevent garbage collection. It also describes validity-aware weak references. Do not assume that a non-null ordinary pointer proves an object is still usable. Unreal object handling
Use this original lifetime ledger for the pickup exercise:
| Reference or state | Intended lifetime | Observation to inspect |
|---|---|---|
| PlayerState's reflected InventoryModel reference | Current player state remains live | The owning instance and reflected field |
| Pawn's temporary pickup interaction | This pawn's current interaction | Cancellation when the pawn is replaced |
| UI's weak pickup highlight | Only while that pickup remains valid | Validity check when reading it |
| Cached ordinary pointer in a delayed callback | No automatic lifetime promise | Whether the target can disappear before the callback |
Now change the scenario: the player respawns before a delayed interaction completes. Identify which pawn and pickup the callback refers to. Even if the callback can still access some object, it may belong to the previous interaction.
Your proposed repair should cover validity and meaning. A fresh pawn reference alone cannot prove that an old interaction should be applied to the new pawn. For this exercise, cancel the obsolete request or associate it with the interaction that created it.
If an interviewer asks whether a standard C++ shared pointer solves this problem, explain the system boundary. Unreal's UObject lifetime is managed through its object mechanisms; ordinary resource ownership is a separate topic. Epic objects overview
Put state where its required lifetime belongs
Official fact: The gameplay framework separates GameInstance, GameMode, GameState, PlayerState, Controller, and Pawn. GameInstance persists across level loads and exists separately on server and clients; it is not replicated. Controller and Pawn separate control from the physical player representation. Gameplay framework
For the original exercise, define these requirements first: match score is shared, inventory survives replacement of the pawn during this match, a pickup highlight is local, and health belongs to the currently controlled pawn.
Choose GameState for the shared match score and PlayerState for the match-level inventory record so replacing a pawn does not erase the inventory by design. Choose the Pawn for the current body's health and local presentation code for the highlight. These are design choices under the stated requirements, not a declaration that every game must store inventory identically.
Official fact: GameMode exists on the server, while GameState can replicate the state clients need to observe. If a client UI needs a changing match score, storing it only in the GameMode instance leaves the client without that replicated instance. Game Mode and Game State
Add a follow-up: the player reconnects after leaving the match. Our earlier “survives pawn replacement” requirement does not establish persistence across disconnection or server restart. State the new retention requirement and design the appropriate recovery path instead of claiming PlayerState supplies permanent storage.
Authority and ownership answer different questions
Authority identifies the machine responsible for the authoritative gameplay state. Ownership identifies the relationship used to determine an actor's owning connection and parts of its network behavior. These concepts can relate, but they are not synonyms.
Official fact: Epic documents owner and owning connection as relevant to RPC routing and replication conditions. A player controller has an owning connection, and a possessed pawn can derive that relationship. Actor owner and owning connection
In our exercise, the client owns its input path but does not get to declare that a pickup is valid or that health has increased. The server evaluates the requested gameplay action using authoritative state.
Suppose the client can see and click a world pickup owned by no player. That visibility is insufficient evidence that a client Server RPC on the pickup will be accepted. Inspect the calling connection, actor ownership, and RPC execution rules.
A design for this exercise sends the interaction request through the player's owned controller or pawn, then has the server inspect the target pickup. The request identifies what the player wants to interact with; it does not supply an unquestioned inventory update.
If the interviewer changes possession, explain that the request path and cached references need review. Drawing a line between two objects on a diagram does not prove that the current connection owns that route.
Trace one health update across the network
Use this original network timeline. A player's pawn has health 60, and an eligible pickup restores 20 with a maximum of 100. The server must verify eligibility and apply the allowed change.
| Stage | Action in the exercise | Evidence to inspect |
|---|---|---|
| Client request | Request interaction with pickup P7 through an owned actor | Current actor, connection, and target reference |
| Server decision | Check pickup exists, range, eligibility, and prior consumption | Authoritative world and player state |
| Server mutation | Consume eligible P7 and change health from 60 to 80 | One accepted action and resulting state |
| Client presentation | Observe replicated health and refresh the display | Received state and notification behavior |
| Later joining client | Read the current replicated state when relevant | Current actor state, rather than an old effect |
The numbers are synthetic expected values. They are not measured engine traces. A rejected or repeated request should not consume the pickup twice or grant health twice under this exercise's contract.
Official fact: Replicating a property requires the actor's replication setup and property registration; Epic describes ReplicatedUsing notifications and GetLifetimeReplicatedProps. A client changing its local property does not establish a server-authoritative update. Replicate actor properties
When asked for implementation detail, name the actor replication setting, property declaration, lifetime registration, and presentation update. Keep that explanation separate from the server's eligibility rule. Correct replication setup can distribute an incorrectly accepted gameplay action.
Why not multicast every state change?
Official fact: Epic distinguishes Server, Client, and NetMulticast RPC execution. The outcome depends on where the call is made and the owning connection. Reliable RPCs have different delivery behavior from unreliable RPCs and should be used sparingly because of their cost. Remote procedure calls
Original design reasoning: For the exercise, use replicated health as the durable current value and treat a pickup sound or flash as a transient presentation event. A player who joins after the pickup needs the current health, not a replay of every historical flash.
The phrase “reliable” does not mean “the gameplay request is valid,” and it does not convert a transient event into a stored history. A server still needs to decide whether the pickup may be consumed.
Do not assume every network update arrives in the order your local code reads it. Epic separately documents replicated-object execution order. If presentation depends on several fields changing together, define how the display tolerates partial observations or use an appropriate grouped state design. Replicated execution order
For a follow-up, let health reach 80 before the pickup animation is displayed. Explain whether that is acceptable presentation behavior under the exercise's contract, and which replicated value or presentation callback you would inspect if the UI resets to an older health value.
A live UObject is not automatically a replicated subobject
Official fact: Epic documents replicating UObjects as subobjects of an actor or actor component. Replicating an object reference alone does not complete subobject replication. The registered-subobject approach and the older virtual replication approach have different support, including Iris requirements. Replicating UObjects
Apply this distinction to the InventoryModel in the exercise. The strong reflected reference addresses reachability. It does not, by itself, establish that clients receive the model's fields.
If the inventory must be shared, either represent the required state through suitable replicated properties or implement supported subobject replication for the project's replication system. Explain the choice before proposing an API call.
In an interview exercise, ask which replication system and engine version the project uses. Documentation pages and selectors can change; this guide concerns UE5 mechanisms and does not claim that every replication example works unchanged across all versions.
If you choose registered subobjects, include registration and removal in the lifetime discussion. A network registration is another relationship to maintain, not permission to ignore object destruction.
What would prove the proposed repair?
For the original exercise, define observations before running an engine test: the correct player can request the interaction, an invalid target is rejected, accepted health becomes 80, a repeated request adds nothing, and the inventory record remains available after pawn replacement.
Use separate server and client observations. A listen-server host can execute server and presentation logic in one process, making a one-window success less informative than the multiplayer contract requires.
Add a later-joining client and a pawn replacement to the verification plan. Observe which instance receives state and which callbacks execute. The exact C++ and Blueprint notification behavior should be checked in the actual project.
No compiled engine test is claimed here. The ledgers specify what a real test must establish and stop a pointer fix from being mistaken for a replication or gameplay-authority fix.
Five questions for adjacent C++ preparation
| Question | Follow-up to rehearse |
|---|---|
| Find and Fix C++ Ownership Bugs: Double Free, Shallow Copy, and Object Slicing | Contrast ordinary C++ ownership with reflected UObject reachability. |
| Explain C++ virtual dispatch and object lifetime | Explain dispatch and the lifetime of the referred instance. |
| Detect memory leaks in C++ | Investigate unintended retention and untracked references. |
| Compare C Generic Techniques and C++ Smart-Pointer Ownership | Distinguish standard C++ smart pointers from Unreal object pointers. |
| C++ Fundamentals: Memory, Compilation, and Containers | Connect language fundamentals to the documentary member sketch. |
Choose the ownership-bug question, then explain what changes when the target is a UObject managed by Unreal. For the gameplay exercise, rehearse the health timeline and change one requirement: another owning connection, a replaced pawn, or a client joining late.
Return to Find and Fix C++ Ownership Bugs for focused practice. A useful answer identifies the mechanism responsible for each symptom and the observation that would confirm the repair.