Why pre-screen game physics programmers before the technical panel
Physics work fails in two directions. It can be numerically correct and feel terrible to play, or feel great until the frame budget collapses on the console version. Add non-deterministic behaviour that only appears in multiplayer and you have the bugs that eat a month. Programmers worth hiring have chased one of those. A short screen asks about the worst physics bug they solved.
What actually matters when screening Game Physics Programmer candidates
- 01
Technical proficiency
Check depth in rigid body dynamics, constraint solvers, and collision detection: GJK/EPA, sequential impulse versus TGS solvers, continuous collision, and C++ SIMD math work in PhysX, Havok, Jolt or a custom engine.
- 02
Systems and trade-offs
Probe how they held a fixed timestep budget: substepping choices, broadphase structure, determinism for replays or netcode, and what fidelity they sacrificed to hit 2ms on console.
- 03
Evidence and rigour
Test how they proved stability: unit tests on constraint cases, deterministic replay harnesses, PIX or Razor captures, tunnelling repro scenes, and profiling data before and after optimisation.
- 04
Collaboration and communication
Assess how they worked with animators, designers, and tech artists on ragdolls, vehicle handling, and destruction tuning, including exposing parameters without letting content break the simulation.
Pre-screening questions to ask Game Physics Programmer candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Shipped titles
3 questions01Can you describe your experience with physics engines in game development?
Listen forEngines used on shipped titles, with the parts they extended or replaced described specifically.
Engine use limited to default settings, or no shipped work involving physics.
02Which game engines have you worked with?
Listen forEngine internals understood well enough to work below the scripting layer when needed.
Experience confined to editor settings, or no engine source ever examined.
03Can you explain a difficult physics problem you solved on a project?
Listen forA specific problem with the diagnosis path described, including what turned out to be wrong.
Problems described as engine limitations, or solutions that amounted to changing values.
Fundamentals understood
4 questions04What are the key differences between rigid body and soft body simulation?
Listen forAccurate explanation with the performance cost and stability issues of each described.
Definitions recited without cost implications, or soft body treated as a checkbox.
05Can you explain why time-stepping matters in a physics simulation?
Listen forFixed versus variable steps explained, with the effect on stability and reproducibility understood.
Time step treated as a tuning value, or frame rate dependence not recognised as a bug.
06How do you handle collision detection and response?
Listen forBroad and narrow phase distinguished, with tunnelling and resolution artefacts addressed properly.
Fast objects passing through geometry accepted, or collisions solved by increasing iterations.
07Have you implemented custom physics algorithms?
Listen forAlgorithms written from the maths with a reason the engine implementation was insufficient.
Custom work described without detail, or reimplementation for its own sake.
Holds the frame budget
3 questions08How do you optimise physics calculations to keep gameplay smooth?
Listen forProfiling before optimising, with specific costs measured on the weakest target platform.
Optimisation by intuition, or performance judged only on a development machine.
09How do you keep physics consistent across different platforms?
Listen forFloating point differences and determinism understood, with the consequences for multiplayer play addressed.
Cross-platform consistency assumed, or desync problems attributed to networking alone.
10How do you balance realism against performance?
Listen forFidelity spent where the player actually notices, with approximations chosen deliberately everywhere else.
Accuracy pursued everywhere, or simplifications made without checking how they feel.
Works with designers
2 questions11What tools do you use to debug physics problems?
Listen forVisual debugging and state capture used, often with tooling they built for the team.
Debugging by print statements alone, or no way to reproduce an intermittent problem.
12Can you describe integrating physics with other game systems?
Listen forAnimation, networking and gameplay code worked with directly, with designer needs taken seriously.
Physics treated as a closed system, or designer feedback dismissed as unrealistic.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Explains solver iteration counts, warm starting, and penetration recovery from direct experience; names the engine and the math library they wrote against.
Systems and trade-offs
25%5Describes concrete trade-offs, for example dropping to simplified convex proxies or capping ragdoll counts, with the frame time and platform that forced it.
Evidence and rigour
25%5Cites measured before and after numbers from a profiler, plus a regression scene or automated test that caught jitter or explosion bugs.
Collaboration and communication
15%5Recounts shipping a tuning tool or clamped parameter set for designers, and negotiating a feel-versus-realism disagreement to a workable result.
Physics can be correct and still feel terrible to play. A one-way video screen asks about the worst bug.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish shipped work, test simulation fundamentals, and hear how they handle performance and debugging.
Should I ask for a code sample too?
Yes, after the screen. A small simulation or a debugging write-up tells you more than an interview, and the screen decides who is worth the reviewing time.
Evaluating answers
What is the strongest signal when screening this role?
A physics bug they chased down. Real answers describe the symptom, the false leads and the actual cause, usually something about time steps or precision. Vague answers mean tuning rather than debugging.
How do I judge their fundamentals?
Ask about time-stepping. Anyone who has written simulation code will explain fixed versus variable steps and why the choice matters. Configuring an engine does not produce that answer.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
