This does require a rather skilled interviewer, so the benefits may well not be worth it. But it can be very interesting information to have.
The “thinking ways” that allow one to solve the problem can be considered to be socio-normative and neuro-typical; normally these fit white patriarchal modalities.
The mental modalities that make it harder to solve such problems are those related to sequence memory weaknesses, comprehension weaknesses, stress factors, attention weaknesses, social differences, exposure, culture, education. So dyslexics, ADHD, Autistics, socio deprived (poorer backgrounds), may struggle with tums like this that assume a consistent world view - when in fact they likely have other strengths in problem solving. It’s not a one size fit all.
Additionally like IQ, ability to solve these types of problem is down to either natural ability or practise in the domain - that is you can increase your IQ by training against the core elements IQ tests look at.
I tend to get candidates to take me through something they know well, or love, or have solved, and then I ask them about how they did it. This shows me genuinely how good they’ll be at the job in hand.. and is why my teams are actually diverse.
In game development we care a lot about build systems- and annoyingly, we have vanishingly few companies coming to throw money at our problems.
The few that do, charge a kings ransom (Incredibuild). Our build times are pretty long, and minimising them is ideal.
If, then, your build system does not understand your build-graph then you’re waiting even longer for builds or you’re keeping around incremental state and dirty workspaces (which introduces transient bugs, as now the compiler has to do the hard job of incrementally building anyway).
So our build systems need to be acutely aware of the intricacies of how the game is built (leading to things like UnrealEngine Horde and UBA).
If we used a “general purpose” approach we’d be waiting in some cases over a day for a build, even with crazy good hardware.
WRT github actions... I agree with OOP, they leave much to be desired, esp when working on high-velocity work. My ci/cd runs locally first and then GHA is (slower) verification, low-noise, step.