Technical interview methods pale in comparison to playing Factorio with someone

While I played, I came to similar conclusions to the article. Building factories in this game is very very similar conceptually to building software. I ran into exactly the same problems that I ran while I build software like:

- If I don't plan ahead enough the scope and layout of the factory, I end up with a spaghetti mess that is very difficult to rectify (technical debt)

- If I plan too much ahead, I overwhelm myself without even starting. The amount over-engineering and over-preparation becomes counterproductive and demoralizing.

- Starting new factories is fun. Maintaining and extending a factory that is starting to show serious design issues is a chore. I always tend to want to scrap the factory and start fresh.

- While designing a factory, modularization is key. You can go with a "monolithic" factory where you provide all possible materials as input, and try to build everything as output. It is very efficient transportation wise, and can centralize all management, but it can and it will become an unmaintainable mess. You can also design factories as "microservices", where each factory is a very compact, clean and scoped. It will only produce nails, or rubber, or copper wire. When you need to increase production of that item, you just duplicate the module (horizontal scaling). It seems fantastic at first, but the issue is now transportation. Dozens of micro-factories have to communicate with themselves to combine and produce more complicated items. The physical distance makes planning transportation a logistic and construction nightmare. So you have to find the right compromise between monolithic and micro-services.

I think I agree with the article that you can extract a lot of information about how good a person can be at software development by the way he plays Factorio/Satisfactory. Not so practical though :)

It really pisses me off that we as an industry don't broadly know our roots and the actual theory that we are putting into practice when we work. The "coding is engineering or art" debate? Easy; it's systems engineering.

The closest we get as an industry to teaching what's under the hood is to deal with computer science, which is great, but data structures and complexity heuristics are only a small piece of the puzzle.

It's no great surprise that there's such a big problem with cargo culting when most of us don't explicitly know what it is that we're doing.

A whiteboard FizzBuzz might be actually testing for memorization, deliberate interview prep, extrovert tendencies, etc. And not for any kind of actual technical skill. Failing the FizzBuzz could also just mean high social anxiety.