Live data from Hacker News

Technical interview methods pale in comparison to playing Factorio with someone

erikmcclure.com

31–40 of 358 posts

Re: Technical interview methods pale in comparison to playing Factorio with someone

#32
The fact that all of the game's functionality mirrors real-world situations when building system shows that you could just ask someone to build a scaled down system rather than asking them to play this game.

Any game sufficiently complicated as this will be akin to asking someone to write some example code in a language they've never used before, so you wouldn't be able to tell much anyway.

Re: Technical interview methods pale in comparison to playing Factorio with someone

#33

How can this not have a huge bias in favor of gamers? Might work for them because that's the kind of culture fit they need, but I doesn't look all that generalizable for other companies.

Worth pointing out that McKinsey developed their own game for demonstrating problem solving in interviews. I don’t think anyone is arguing that McKinsey has a bias towards gamers.

I will argue McKinsey has a bias against humanity and good things, but that's off-topic :-)

Re: Technical interview methods pale in comparison to playing Factorio with someone

#34

I seriously think that "personal projects" are very underrated when it comes to hiring. If I see that someone has a lot of personal projects and has lots of time in Factorio they probably know how to code. I'm not sure you can rank them as Junior/Senior too effectively as these two things don't require much leadership, but you can basically skip the trivial phone interview questions at this point.

often in multiplayer factorio playthroughs you get one player who becomes the defacto "lead dev". it takes some nontrivial organization to get subgoals completed in a way that people aren't blocking each other. a common mistake is two players building separate factories too close together, which leads to some very messy solutions and limits how much the throughput can be upgraded.

Re: Technical interview methods pale in comparison to playing Factorio with someone

#36

How can this not have a huge bias in favor of gamers? Might work for them because that's the kind of culture fit they need, but I doesn't look all that generalizable for other companies.

Reminds me of questions related to sports.

I have zero interest in sports and am clueless to the rules of baseball or football or basketball. I hated when I got questions that assumed I had any such knowledge.

Granted this was way back when when interviewers like to toss brainteaser questions to cargocult Google/Microsoft/etc...before they started doing leetcode to cargocult Google etc.

Re: Technical interview methods pale in comparison to playing Factorio with someone

#37
post #16
post #7

I don't know that I agree. I don't really play games so I would be a bit lost here, but if you needed me to design and start coding a large distributed system I would happily oblige while he watched...

Isn't a factory a large distributed system? What's the difference between this and a visual programming language like LabVIEW?

Well, LabView doesn't have locals who get pissed off by your pollution, for one.

Re: Technical interview methods pale in comparison to playing Factorio with someone

#38
post #30
post #21

Earlier quoted context omitted.

You can choose to make X (what's tested for in the interview) a representative cross section of the harder things that you need. Or don't even try and make X not even intersect with anything you need. It still puzzles me how many people opt "don't even try".

I see what you mean, but in my experience there's this tendency where you think you're testing for "X", but you aren't really. 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.

True. I find I have to iterate on my processes quite a few times before I squash these issues.

They're conceptually similar to software bugs - inevitable, often surprising and impossible to fix all at once.

Post reply on HN