[Fell]

I spent the past 4 years at a small studio with about 6-8 programmers.

Almost all the programmers that ever joined our team came from a non gaming background.

And every time I onboarded someone new, it went about the same way. They adapted pretty quickly to our C++ codebase, even if they had a different background. But most of them were really not used to work in an environment where performance really matters. They knew how to write code, but they didn't know how to write fast code. Or what actually makes their code fast.

So if you want to prepare, take the slowest machine you can get your hands on, and program something for that hardware using C++ or Rust. It doesn't matter what it is. You'll learn a lot and have something nice to talk about at the job interview.

[unshavedyak]

> So if you want to prepare, take the slowest machine you can get your hands on, and program something for that hardware using C++ or Rust. It doesn't matter what it is. You'll learn a lot and have something nice to talk about at the job interview.

As an aside, "slowest machine" seems an easy way to bench things - is there not a common way to wrap an executable in something that limits performance, network, etc?

It's a trope that developers tend to have beefy machines and so we often miss pitfalls of lesser machines unless we're explicitly benching code. I'm kinda surprised there isn't some CLI for `slow --ram=2gib --cpu_clock=3ghz --core_count=1 mybinary` sort of program.

[mijoharas]

Cgroups[0] can do that for you on Linux. I believe docker containers wrap the cgroups API and can do something similar? Possibly cross platform?

[0] https://en.m.wikipedia.org/wiki/Cgroups

[ibejoeb]

CPU and RAM is pretty straightforward with something like cgroups or basically any container system. I'm not sure how you'd go about limiting GPU, though, which is probably essential for any modern engine that uses shaders.

[sgtnoodle]

You could put effort into instrumenting your main loop. Knowing how long the CPU takes to run the various routines will quickly expose bottlenecks. If you're using 90% of a high end CPU, you can assume it's not going to run well on less capable hardware. If you're using 10%, then you're probably in good shape. If you're using 100%, then it's a good opportunity to learn about various frame limiting algorithms.

[zengid]

> take the slowest machine you can get your hands on, and program something for that hardware using C++ or Rust

that's a lovely idea and a great limitation for inspiring creativity!