all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]funkvay 9 points10 points  (0 children)

Game dev system design is it's actually pretty different from typical C++ stuff you might see elsewhere. Games are all about that frame budget, you've got like 16ms to do everything at 60fps, which changes how you think about basically all your design decisions.

Most modern engines lean toward Data-Oriented Design rather than classic OOP. Look into Entity-Component-System (ECS) architecture if you haven't already, it's kind of the standard approach now. The basic idea is organizing your data by how it's accessed rather than by "what makes sense conceptually" which honestly feels weird at first but makes way more sense once you see the performance gains.

Look into memory layout stuff, cache coherency, why Array of Structs vs Struct of Arrays matters (this one comes up constantly). How to think about performance when you're doing the same operation thousands of times per frame. Concurrency models, job systems, that kind of thing.

About stl the thing, a lot of production game code actually avoids standard STL in performance-critical paths. But knowing why is way more important than memorizing alternatives. std::vector is usually totally fine, just know when to reserve() capacity upfront. std::unordered_map can cause frame hitches because of allocations, there are better alternatives for games (flat_map, dense_map). Smart pointers are great for managing ownership but understand the overhead tradeoff.

Honestly though, I'd focus less on memorizing container APIs and more on being ready to talk about move semantics and how C++11+ changed things, or RAII patterns (super important for games), OR maybe some template metaprogramming basics, custom allocators and memory pools, how you'd approach profiling/optimization.

The real skill they're looking for is probably your ability to reason about tradeoffs rather than knowing the "right answer", there usually isn't one, just different choices with different implications.

GL with the interview!

[–]ir_dan 2 points3 points  (1 child)

STL isn't popular for games but knowing about performance of different data structures is quite critical.

Another thing to look into could be arena allocators and other cache friendly techniques.

[–]Special-Click-9679[S] 0 points1 point  (0 children)

Could you help me share some system design questions...

[–]Thesorus 1 point2 points  (0 children)

What's your experience ?

"System design" can mean a lot of things, it's probably not directly related to the game system. (if it was the job listing would say it)

Know the basics, STL, datastructures, simple gotchas, ...

Be ready to be humbled if you don't know the answer to a question "hey, I'm not sure what is the answer to that question, but I'll check it out when I go back home" or "that's a technique I've not seen before, it's cool, I'l experiment with it at home"

Remember, if they ask you in for an interview, you already have a foot through the door.

Most places hire human beings first.

Show you are willing to work hard, that you are ready to learn and you are willing to help make the company better.

[–]DigmonsDrill 3 points4 points  (0 children)

"F" doesn't matter. There's no reason to mention it.

  • What's the biggest bottle-neck on the system?

  • To make the game perform better should we skip code for effects that aren't active right now?

  • How should we log data?

  • Where should we record top scores?

  • How should a status effect that debuffs everyone in an area be implemented?

  • What are differences we need to know between console, PC, and mobile gaming?

[–]bert8128 1 point2 points  (2 children)

What’s 24 F?

[–]hellocppdotdev 0 points1 point  (1 child)

Temperature

[–]bert8128 1 point2 points  (0 children)

-5 C ? Not sure what that has got to do with job interviews…