We used this a couple times at Sandstorm back in the day. At the end of the interview the candidate would play Factorio cooperatively with the team for a while.
I think it is remarkably effective at identifying the kinds of skills and personality traits that a software engineer actually needs to have in day-to-day work. You can find out if someone is self-directed, how fast they work, whether they produce clean designs or spaghetti code, whether they are good at cooperating or tend to go off on their own, etc. Some people will just sit and watch and do nothing unless instructed... that's bad. Some people will build stuff, but with obvious efficiency flaws and "bugs"... also bad. Some people identify what needs doing and get it done effectively but without trying to be perfect... that's good. Factorio essentially compresses real-world work patterns into a shorter time period, giving you the chance to see how someone works in the space of a couple hours. I don't know anything else that does that.
But, obviously, it's problematic. A person who has played the game before will have a big advantage. A person who doesn't play video games at all will have a big disadvantage. For these reasons, I don't think I could seriously recommend this approach be adopted more widely.
But then, I don't know of any approach to interviewing that I think is fair. Everything has problems:
* Regular interviews bias towards people that are charismatic, not effective.
* Coding interviews bias towards people who can code under pressure with someone looking over their shoulder, which is almost nothing like real-world coding.
* Puzzle-y algorithms questions identify people good at clever solutions but that's hardly what most people need to do day-to-day when coding.
* Take-home assignments bias towards people who have lots of free time, and still don't really tell you how that person works with others.
* Looking at GitHub history biases against people whose lives are too busy to code in their free time (e.g. maybe they have kids) and who weren't lucky enough to have a previous job that touched a lot of open source.
* Looking at past work experience misses brilliant junior programmers coming out of college.
* Don't even think about using ML for this, that doesn't solve biases, it just hides them in a black box.
I've honestly simplified my approach to interviewing over the last few years and I'm pretty happy with the results.
I just have a conversation and ask them to tell me about a favorite code project they've worked on. Could be school project, previous job, whatever.
And just let them talk about it. I'll prod for more detail if I need to give a little nudge. Ask about problems they solved when doing it, etc.
The _only_ thing that I'm looking for in this process is whether or not the person is truly interested what they're doing. This comes through when talking about something they're excited to have worked on, seemingly small problems that they had to really work to solve, etc. Geeking out, if you will.
The single most important trait I've seen in programmers that I've worked with over the years is "level of interest". There's too much that you have to learn on a daily basis to be successful in this field. If you're not interested in learning new things and finding solutions to the problems that you encounter, you're not going to make it very far.
Beyond that and basic competence in the core skills that the job requires, I don't look for much more.
Thus far, everybody I've ever hired who has passed this little conversational test has been an excellent team member.
Please don't. Better, I'll remove the please and go JUST DONT FUCKING DO IT.
Hiring is broken because most people hiring aren't good at it and the people working in tech are pretty much idiots (I'm focusing more on SV-startup, 5hour discussion about aeropress, put people down because they chose vim or emacs - people kinds). From 'cultural' fit interviews (who the fuck cares if you are a sikh or an atheist, whiskey drinking or think alcohol is evil? You are hired to do a job, not much more). This 'i have my social life at work, so I want people I can hang out with' shit has got to end. I work remotely for 10+ years and I can see in interviews/meetings the people that seem to base their identity and life around work, and the ones that actually are well rounded people that don't care about which coffee grind size you use on your morning crap of joe.
I have been a professional boxer and dabbled with MMA/Grappling. I can say most things in the article can apply. So.. at the end of the interview just get them in gloves and duke a few rounds? I would be sued out of existence, but for some reason, between take home assignments, 10h whiteboard drilling and whatever the fuck is hip now (leetcode or what not), interviewing is broken because people are idiots. I have been interviewing people for the last 5 years. If in an one hour talk that is semi technical, you can't understand if the person knows what the fuck they are doing or not, then the problem is you, not the whiteboard or the take-home or the paid assignment. Just admit most people interviewing others for technical positions have not fucking clue or training, BUT, hey, they are smart people from Standford or MIT, so 'how hard can it be' and we get the clusterfuck that it is now
Good lord, this is an awful idea. I've played a ton of Factorio, and I'm a decent engineer, and while the skillsets are similar conceptually, the actual execution and mechanics of them are very very different. Factorio involves a lot of care with spatial layout, tricks to optimize loading the conveyer belts, ensuring that the right ratios of pre-cursors are sent, etc etc.
You could get a candidate who perfectly understands design patterns for programming, because they've studied programming and know how to program using programming languages and programming tools, but they don't translate that very well into the spatial environment of Factorio. Debugging and optimizing in Factorio again are conceptually similar to doing so in a programming language, but the actual techniques and patterns available to do so are very very different, and you have to learn them. Most of us do not figure these things out from scratch by ourselves.
As others have pointed out, it also is begging for a monoculture. Plenty of people who are good at programming don't give a shit about video games, and will either do poorly in this interview, or will skip it altogether. The result would be hiring one type of person, and not having any other skillsets on your team. Even as someone who would do well in this interview, I would run screaming, as I do not want to work in a monoculture.
> A senior developer should be able to explore the UI and figure out a goal, then establish a plan for accomplishing that goal.
I'm confounded on why the author thinks being a senior developer (say, in embedded systems) would make someone better at exploring a game UI compared to an intern-candidate who puts 20+ hours into gaming per week...
I would probably walk out of the interview if someone suggested I play factorio as part of the hiring process - I have been intentionally avoiding it - you might as well offer me a free hit of crack cocaine while you're at it.
I assume everyone is curious and can easily filter garbage to find useful ideas. But I’ve been surprised the number of times juniors got stuck and weren’t able to Google and find libraries that are top on stack exchange.
Or designs with alternative analyses that honestly leave out the top toolkits for a project because they found the gartner report and didn’t go any further.
I don’t consider these junior/senior types of things, but there are things I have to realize vary across people and not everything is intuitive or easy to everyone.
Factorio isn't a game about shooting things. It is a systems-design game. Your goal is to orchestrate the processing of several different resources (iron, copper, coal, oil, stone) into several different intermediate products (gears, circuit boards, sulfuric acid, radar systems, etc), in service of a final deliverable (a rocket launch, or if you're ambitious, a continuous series of rocket launches).
To that end you must manage a variety of subsystems and how they interact with each other and with the components that you build. You will be rewarded for consistency, for modularity, for automation of frequent tasks, for reproducible designs, for looking ahead and preparing for scalability. You will be punished for failing to plan ahead. You will also be punished for trying to scale too fast, too soon.
The interview is a bad idea, yes. Even if all candidates were experienced with the game, as a showcase of how to build things, you'd still need many more hours than a typical interviewee is willing to provide, to showcase the approach. But it's not a game you get better at by focusing on "gaming".
I am a senior engineer and have been programming for close to two decades. I picked up Factorio a few months ago and felt overwhelmed. I couldn't finish the tutorial. I think my problem is spatial relations--it is something I've always struggled with (how to arrange furniture in a room, solve a jigsaw, etc).
I don't think this is a detriment to my programming ability at all--spatial relations really never enters into architecting a large system. Of course you need to think about design constraints but none of them exist on a physical plane.
Factorio, on the other hand, requires actual spatial relation ability. You need to visualize how belts intersect and how to best position things so they dont interfere with each other. This is where I struggled.
Also a senior engineer. I tried factorio demo out for maybe 30 minutes, but hated the fact that I actually have to walk the engineer around and do menial tasks like resource collection myself. Why can't I just do stuff with mouse cursor like in most other top-down strategy games? Maybe the game changes in later stages, but the demo seemed to be full of nonsense busywork that is prevalent in survival games.
I agree with this - having watched the trailer and played the demo, Factorio looks to me like a game of managing logistics of transporting resources around, featuring a conveyor belt system that only works in 2D.
In another game, I'd consider that an annoying micromanagement feature.
The conclusion of the article somewhat contradicts the title:
"What's the takeaway from this? I don't know. We certainly can't switch to using Factorio as an interviewing method - you might as well just give a candidate a take-home assignment. At the very least, we can do better than whiteboard interviews."
So it's not a description of how to use Factorio for interviewing, beyond a simple assignment of Factorio tasks to seniority levels. It does however make an interesting comparison between Factorio and software mechanisms.
This is a great way to end up with a monoculture, with all of the fragility that’s associated with it. That might be a fun way to hire engineers 1-5 in a startup but it will hold you back in the end. Many good engineers have no interest in games, and won’t present well in that arena. You’ll get lots of false negatives.
“Fizzbuzz is all we have...” is a myopic take. Interviewing is hard but not as hard as the article makes out. There is a legitimate debate between take-home and on-site interview practices, but at the end of the day you want to see a work sample that is as realistic as possible from your candidate. Companies that are good at hiring understand this. Factorio has a tenuous (at best) correlation to the work you’re asked to do.
It’s like doing puzzle questions because you “can see how they think about problems”, but interviewers are really just selecting for people that think like they do.
> but interviewers are really just selecting for people that think like they do.
No. We don't care how you get it done, but that you try in a way that would be worth paying you for.
My job isn't a calm safe place, it's the chaotic result of two departments and the proverbial rubber hitting the road in one spot. It's not intentionally bad, mean, hard, or long, and we weed out people who don't cooperate well, but every crazy thing you can imagine has happened.
But even in previous, easier, positions people were still put on the spot by being assigned to work with customer support on some issue way up the stack from their normal job, which required to be on a call with 20+ outsiders, from CEOs to SREs, and representing us and our department properly. The people on HN who talk about giving people calm interviews to see their true selves don't get it, the performance under a small amount of stress is far more interesting. Do you get mean and snappy, get entitled, shut down, or what?
If being asked, kindly, to solve a basic leetcode is too much then there's no way you'd be suitable for anything else we do.
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.
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.
You only have to understand how to move your character using WASD, the concept of Inventory and pointing at different places on the ground with a cursor. Failing to understand this simple set of rules would disqualify a person from most jobs ever invented.
It might, if they were actually suggesting this. Title was intended to race to the top of Hacker News.
>What's the takeaway from this? I don't know. We certainly can't switch to using Factorio as an interviewing method - you might as well just give a candidate a take-home assignment.
I don't think it would have a huge bias towards gamers in general. the real issue would be people who already happen to be good at factorio. if you play with experienced people, it's easy to pick up on a lot of efficient patterns without really understanding why they work.
It’s unclear if this article is satire or not. Given that you will be spending 20 hours of at least two people’s time (one candidate, at least one employee), the space of alternative interviews is quite large. You could, for example, spend 20 hours observing them perform an actual software task. This piece doesn’t consider alternatives at all, merely asserting that this particular 20 hour game is the best that can be done. I see no reason to believe that comparing the play of a practiced factorio player to that of a brand new player would carry much signal at all. That means that a company carrying out this type of interview would need to ask candidates to study by playing the game.
This winter break I spent an embarrassing amount of time on Satisfactory on Steam, which is essentially a nicer (and probably easier) modern refresh of Factorio.
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 :)
Also dipped my toes into Satisfactory this winter - after spending over 2,000 hours in Factorio.
Games like these challenge your ability to manage complex systems. Remembering which parts of your system processes which data (aka, "materials"). Finding and addressing bottlenecks in production lines. Maintaining and upgrading components, while creating new production lines using the techniques you learn. Managing time spent refactoring old systems vs replacing them with new ones. Etc, etc, etc. Planning properly - as you mention - is extremely critical to building a good factory.
However, despite over a decade of software development experience, and some time in Factorio, my first several play throughs in Satisfactory where an efficiency disaster, and even my recent ones were an ugly mess of spaghetti for the first few days of gameplay.
It took several playthroughs for me to grok the mechanics well enough to build a somewhat efficient factory. If my first couple tries were reviewed in a job interview I highly doubt I'd get the job.
There are strong similarities between these games and the mechanics software development, but like any new system, it takes time to create a true intuitive understanding of the mechanics and demonstrate them in front of others. If you're going to interview someone for a job, you're better off testing their ability to play the game that they'll be playing on a daily basis if they get hired: "Software Development".
Software Development, the game!
Want to play a game where you will never run out of new content? Where you are constantly challenged by new issues that'll haunt your dreams and make you lose sleep? Software Development is the game for you! With an ever changing landscape, where components and frameworks are updated daily! That's right, DAILY! This MASSIVE-multiplayer-online game never turns off. There are actively hundreds of thousands of players right now!
And you know what the best part is? Software Development is not "Pay-to-Play" like all those other games that try to steal those valuable dollars out of your pocket.
No, in Software Development YOU get PAID to play. That's right! All you have to do is find a company, nail a job interview, and enjoy playing the game you love while they hand you buckets of REAL LIFE MONEY that you can spend on other games that you have to pay to play. And also, food and rent and stuff...
If that's the analogy, then I don't think it captures the core difficulty of software, which is unknown unknowns. That is, you write something that depends on an external system working a certain way, you follow its spec and depend on it working that way, and then it just ... doesn't, and you have to find exactly where it deviates, possibly making up some complicated kludge.
To capture that, there would have to be e.g. some hidden logic about which direction the output comes out that you have to deal with and work around until you understand it.
Satisfactory is really great, highly recommended from me as well. I think the verticality really adds a lot of fun over Factorio where you are restricted to keeping everything on the same level. Can make some really confusing spaghetti though...
I haven't played Satisfactory since the water update, so I have no idea if my approach still works, but IMO the easiest way to design an efficient factory is to not bother trying to balance anything, and scale out in only one direction as needed. Feed everything along a central stack of belts, and multiplex inputs/outputs via splitters/combiners so any individual machine line will always have throughput.
It doesn't make for a very exciting build, but it's very rote and dependable.
The latest update in Experimental (in Early Access on April 13) adds Drones for point-to-point delivery without needing connecting belts or rails or whatever. They're pretty low-bandwidth so you can't use them to transport raw materials at any scale, but if your "microservices" are sufficiently focused at a higher tier, you can tie them all together pretty easily with Drones now.
At least, in theory. Drones are T8 tech, and I'm not _quite_ there yet to start putting that theory into practice. But that's the stated intent, at least.
Factorio runs on Windows, Mac and Linux; Satisfactory only runs (currently) on Windows. Factorio is the better option, though Satisfactory is a great game non-the-less.
This is the reason why I don’t like playing factorio. I’d rather make real software and get paid or build something usable vs a game version of it. I spend a lot of time already doing it as my job, and it stresses me out in a similar way.
The major difference between Factorio and software is you can't refactor in Factorio. Your options are to spaghetti or start fresh. You can't really pick and choose good pieces of your layout because of physical restrictions and the game is a giant math equation, and you want inputs to match outputs at every step of the way - if you don't have the space to do this you don't have the space.
It's like if in the software world you could greenfield, waterfall, or spaghetti. There is no agile in Factorio, which is broadly accepted as most commonly the best way to develop a piece of software.
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.
I don't think there is any silver bullet way to do technical interviews. The idea that you can extrapolate a few hours of exposure to a person into a reliable predictor of future performance is somewhat silly to me. Any technique you use is going to be biased for people that are good at "X", where "X" is a tiny subset of what you need in an employee.
Obviously, you still need to do interviews, but keep some perspective when deciding. Don't overweight any one thing.
Dyson Sphere Program is so good. I haven't played Factorio yet, but I think it has all the same sorts of things that this article described.
When I started playing DSP at first, I was just putting stuff anywhere. Then I realized that there are advantages in trying to make things modular in a way roughly analogous with code. At the same time though, it is very different than code, as the design is spacial, not as abstract as coding. Refactoring code is very different as a result.
I've never played Factorio and have no particular opinion on its value as an interview method, but I assume some of whatever value it has comes from forced team interaction rather than anything inherent in the game.
I have turned down an interview because of Diablo. I got recruited a couple times by a startup that would have been a very good fit for me. The first time it was quite small and I chatted with the CEO about possible roles and product directions and such, but I'd just quit a long term job and eventually decided that I wanted to take a break for a while.
The second time was years later after it had grown a lot and gotten tons of funding over multiple rounds. As it happens, the CTO was also a friend-of-a-friend. When the Diablo 3 beta came out, I played a bit with him and our mutual social circle, and he demonstrated enough personality traits during that brief experience that I decided I wasn't interested in socializing with him more, and just turned down the recruiter after checking to see that he was still the CTO. I would have at least discussed it further if he wasn't specifically in a leadership position.
Looking forward to this becoming the new standard with an ecosystem of bootcamps, an infinite stream of blogs, youtube videos, and personal tutors teaching you how to play optimal factorio while candidates sweat bullets and cry.
Also don't forget all the blog posts about how hiring is broken, particularly because high school dropouts are able to put hundreds of hours into the game while senior swe are busy with their jobs and families.
Yes, confidence to try something new and problem solving are important factors but once one solves for those then testing for the ability to communicate well with others might be as or even more important than having the required computer skills.
I used Zachtronic's TIS-100 [0] as a test variable and found the best person to work with. I believe it was a two way street because they saw an opportunity to work with someone who attacks problems a little differently. I am in real estate. Who would have thought knowing something about assembly would be helpful?
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...
I dislike defining seniority by your technical knowledge or skills. I have a different, I think more useful definition that I use. It overlaps a little bit but excludes knowledge, intelligence and focuses on mindset and ownership.
More senior person is one that has more mature approach to their work. One that can get better results with less resources. Typically more senior people can also accept wider variety of tasks.
What is better results and what is less resources will depend on the project.
It has nothing to do with the knowledge or experience, in my opinion.
You can have good senior person get better results in a technology they have no previous experience with compared to a very experienced / intelligent / knowledgeable person that has track record of making bad decisions. Senior person will use their good judgement to warn the manager they are running outside of their knowledge and to know when they need to use some resources (like help) from somebody more knowledgeable.
A knowledgeable but less senior person may think they know anything but not be able to recognize they are trying to achieve something that is outside their area of expertise or not be able to recognize or accept they are bad at something.
For me senior developer is somebody I can entrust they will put honest, worthwhile attempt at making good decisions when it is called for and recognize when they need to come back for further direction.
Senior developers show ownership in that they seek to uncover problems and discuss those problems with the team, proactively and productively. Senior developers can smell problems even if they don't necessarily know the solution. They can act on the signs of the bad smell and maybe seek discussion (with architect? client? manager? team?) to figure out what is going on and what needs to be done further.
Senior developers understand there are many ways/levels to solve the problem and sometimes solution isn't more code but maybe procedural change or a shift in paradigm.
Senior developers can meaningfully help/direct more junior team members individually without taking over their projects.
Senior developers can keep working relationships even with difficult people or people they don't like.
[+] [-] kentonv|5 years ago|reply
I think it is remarkably effective at identifying the kinds of skills and personality traits that a software engineer actually needs to have in day-to-day work. You can find out if someone is self-directed, how fast they work, whether they produce clean designs or spaghetti code, whether they are good at cooperating or tend to go off on their own, etc. Some people will just sit and watch and do nothing unless instructed... that's bad. Some people will build stuff, but with obvious efficiency flaws and "bugs"... also bad. Some people identify what needs doing and get it done effectively but without trying to be perfect... that's good. Factorio essentially compresses real-world work patterns into a shorter time period, giving you the chance to see how someone works in the space of a couple hours. I don't know anything else that does that.
But, obviously, it's problematic. A person who has played the game before will have a big advantage. A person who doesn't play video games at all will have a big disadvantage. For these reasons, I don't think I could seriously recommend this approach be adopted more widely.
But then, I don't know of any approach to interviewing that I think is fair. Everything has problems:
* Regular interviews bias towards people that are charismatic, not effective.
* Coding interviews bias towards people who can code under pressure with someone looking over their shoulder, which is almost nothing like real-world coding.
* Puzzle-y algorithms questions identify people good at clever solutions but that's hardly what most people need to do day-to-day when coding.
* Take-home assignments bias towards people who have lots of free time, and still don't really tell you how that person works with others.
* Looking at GitHub history biases against people whose lives are too busy to code in their free time (e.g. maybe they have kids) and who weren't lucky enough to have a previous job that touched a lot of open source.
* Looking at past work experience misses brilliant junior programmers coming out of college.
* Don't even think about using ML for this, that doesn't solve biases, it just hides them in a black box.
It seems like there's no right answer here.
[+] [-] brightball|5 years ago|reply
I just have a conversation and ask them to tell me about a favorite code project they've worked on. Could be school project, previous job, whatever.
And just let them talk about it. I'll prod for more detail if I need to give a little nudge. Ask about problems they solved when doing it, etc.
The _only_ thing that I'm looking for in this process is whether or not the person is truly interested what they're doing. This comes through when talking about something they're excited to have worked on, seemingly small problems that they had to really work to solve, etc. Geeking out, if you will.
The single most important trait I've seen in programmers that I've worked with over the years is "level of interest". There's too much that you have to learn on a daily basis to be successful in this field. If you're not interested in learning new things and finding solutions to the problems that you encounter, you're not going to make it very far.
Beyond that and basic competence in the core skills that the job requires, I don't look for much more.
Thus far, everybody I've ever hired who has passed this little conversational test has been an excellent team member.
[+] [-] odshoifsdhfs|5 years ago|reply
Hiring is broken because most people hiring aren't good at it and the people working in tech are pretty much idiots (I'm focusing more on SV-startup, 5hour discussion about aeropress, put people down because they chose vim or emacs - people kinds). From 'cultural' fit interviews (who the fuck cares if you are a sikh or an atheist, whiskey drinking or think alcohol is evil? You are hired to do a job, not much more). This 'i have my social life at work, so I want people I can hang out with' shit has got to end. I work remotely for 10+ years and I can see in interviews/meetings the people that seem to base their identity and life around work, and the ones that actually are well rounded people that don't care about which coffee grind size you use on your morning crap of joe.
I have been a professional boxer and dabbled with MMA/Grappling. I can say most things in the article can apply. So.. at the end of the interview just get them in gloves and duke a few rounds? I would be sued out of existence, but for some reason, between take home assignments, 10h whiteboard drilling and whatever the fuck is hip now (leetcode or what not), interviewing is broken because people are idiots. I have been interviewing people for the last 5 years. If in an one hour talk that is semi technical, you can't understand if the person knows what the fuck they are doing or not, then the problem is you, not the whiteboard or the take-home or the paid assignment. Just admit most people interviewing others for technical positions have not fucking clue or training, BUT, hey, they are smart people from Standford or MIT, so 'how hard can it be' and we get the clusterfuck that it is now
[+] [-] notJim|5 years ago|reply
You could get a candidate who perfectly understands design patterns for programming, because they've studied programming and know how to program using programming languages and programming tools, but they don't translate that very well into the spatial environment of Factorio. Debugging and optimizing in Factorio again are conceptually similar to doing so in a programming language, but the actual techniques and patterns available to do so are very very different, and you have to learn them. Most of us do not figure these things out from scratch by ourselves.
As others have pointed out, it also is begging for a monoculture. Plenty of people who are good at programming don't give a shit about video games, and will either do poorly in this interview, or will skip it altogether. The result would be hiring one type of person, and not having any other skillsets on your team. Even as someone who would do well in this interview, I would run screaming, as I do not want to work in a monoculture.
[+] [-] sangnoir|5 years ago|reply
I'm confounded on why the author thinks being a senior developer (say, in embedded systems) would make someone better at exploring a game UI compared to an intern-candidate who puts 20+ hours into gaming per week...
I would probably walk out of the interview if someone suggested I play factorio as part of the hiring process - I have been intentionally avoiding it - you might as well offer me a free hit of crack cocaine while you're at it.
[+] [-] prepend|5 years ago|reply
Or designs with alternative analyses that honestly leave out the top toolkits for a project because they found the gartner report and didn’t go any further.
I don’t consider these junior/senior types of things, but there are things I have to realize vary across people and not everything is intuitive or easy to everyone.
[+] [-] fennecfoxen|5 years ago|reply
To that end you must manage a variety of subsystems and how they interact with each other and with the components that you build. You will be rewarded for consistency, for modularity, for automation of frequent tasks, for reproducible designs, for looking ahead and preparing for scalability. You will be punished for failing to plan ahead. You will also be punished for trying to scale too fast, too soon.
The interview is a bad idea, yes. Even if all candidates were experienced with the game, as a showcase of how to build things, you'd still need many more hours than a typical interviewee is willing to provide, to showcase the approach. But it's not a game you get better at by focusing on "gaming".
[+] [-] jontas|5 years ago|reply
I don't think this is a detriment to my programming ability at all--spatial relations really never enters into architecting a large system. Of course you need to think about design constraints but none of them exist on a physical plane.
Factorio, on the other hand, requires actual spatial relation ability. You need to visualize how belts intersect and how to best position things so they dont interfere with each other. This is where I struggled.
[+] [-] wideareanetwork|5 years ago|reply
As a job seeker you need to identify these companies fast so you can avoid wasting your time on them.
[+] [-] burntoutfire|5 years ago|reply
[+] [-] learnstats2|5 years ago|reply
In another game, I'd consider that an annoying micromanagement feature.
[+] [-] KineticLensman|5 years ago|reply
"What's the takeaway from this? I don't know. We certainly can't switch to using Factorio as an interviewing method - you might as well just give a candidate a take-home assignment. At the very least, we can do better than whiteboard interviews."
So it's not a description of how to use Factorio for interviewing, beyond a simple assignment of Factorio tasks to seniority levels. It does however make an interesting comparison between Factorio and software mechanisms.
[+] [-] theptip|5 years ago|reply
“Fizzbuzz is all we have...” is a myopic take. Interviewing is hard but not as hard as the article makes out. There is a legitimate debate between take-home and on-site interview practices, but at the end of the day you want to see a work sample that is as realistic as possible from your candidate. Companies that are good at hiring understand this. Factorio has a tenuous (at best) correlation to the work you’re asked to do.
It’s like doing puzzle questions because you “can see how they think about problems”, but interviewers are really just selecting for people that think like they do.
(And for context I like Factorio.)
[+] [-] Rule35|5 years ago|reply
No. We don't care how you get it done, but that you try in a way that would be worth paying you for.
My job isn't a calm safe place, it's the chaotic result of two departments and the proverbial rubber hitting the road in one spot. It's not intentionally bad, mean, hard, or long, and we weed out people who don't cooperate well, but every crazy thing you can imagine has happened.
But even in previous, easier, positions people were still put on the spot by being assigned to work with customer support on some issue way up the stack from their normal job, which required to be on a call with 20+ outsiders, from CEOs to SREs, and representing us and our department properly. The people on HN who talk about giving people calm interviews to see their true selves don't get it, the performance under a small amount of stress is far more interesting. Do you get mean and snappy, get entitled, shut down, or what?
If being asked, kindly, to solve a basic leetcode is too much then there's no way you'd be suitable for anything else we do.
[+] [-] francisduvivier|5 years ago|reply
[+] [-] decafninja|5 years ago|reply
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.
[+] [-] Toutouxc|5 years ago|reply
[+] [-] Workaccount2|5 years ago|reply
[+] [-] cwhiz|5 years ago|reply
>What's the takeaway from this? I don't know. We certainly can't switch to using Factorio as an interviewing method - you might as well just give a candidate a take-home assignment.
[+] [-] fudged71|5 years ago|reply
I don’t think anyone is arguing that McKinsey has a bias towards gamers.
[+] [-] leetcrew|5 years ago|reply
then again, I guess that's also true of software.
[+] [-] wskinner|5 years ago|reply
[+] [-] lvice|5 years ago|reply
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 :)
[+] [-] oauea|5 years ago|reply
[+] [-] kempbellt|5 years ago|reply
Games like these challenge your ability to manage complex systems. Remembering which parts of your system processes which data (aka, "materials"). Finding and addressing bottlenecks in production lines. Maintaining and upgrading components, while creating new production lines using the techniques you learn. Managing time spent refactoring old systems vs replacing them with new ones. Etc, etc, etc. Planning properly - as you mention - is extremely critical to building a good factory.
However, despite over a decade of software development experience, and some time in Factorio, my first several play throughs in Satisfactory where an efficiency disaster, and even my recent ones were an ugly mess of spaghetti for the first few days of gameplay.
It took several playthroughs for me to grok the mechanics well enough to build a somewhat efficient factory. If my first couple tries were reviewed in a job interview I highly doubt I'd get the job.
There are strong similarities between these games and the mechanics software development, but like any new system, it takes time to create a true intuitive understanding of the mechanics and demonstrate them in front of others. If you're going to interview someone for a job, you're better off testing their ability to play the game that they'll be playing on a daily basis if they get hired: "Software Development".
Software Development, the game!
Want to play a game where you will never run out of new content? Where you are constantly challenged by new issues that'll haunt your dreams and make you lose sleep? Software Development is the game for you! With an ever changing landscape, where components and frameworks are updated daily! That's right, DAILY! This MASSIVE-multiplayer-online game never turns off. There are actively hundreds of thousands of players right now!
And you know what the best part is? Software Development is not "Pay-to-Play" like all those other games that try to steal those valuable dollars out of your pocket.
No, in Software Development YOU get PAID to play. That's right! All you have to do is find a company, nail a job interview, and enjoy playing the game you love while they hand you buckets of REAL LIFE MONEY that you can spend on other games that you have to pay to play. And also, food and rent and stuff...
Download now at, the internet.
[+] [-] SilasX|5 years ago|reply
If that's the analogy, then I don't think it captures the core difficulty of software, which is unknown unknowns. That is, you write something that depends on an external system working a certain way, you follow its spec and depend on it working that way, and then it just ... doesn't, and you have to find exactly where it deviates, possibly making up some complicated kludge.
To capture that, there would have to be e.g. some hidden logic about which direction the output comes out that you have to deal with and work around until you understand it.
[+] [-] kleff|5 years ago|reply
[+] [-] colpabar|5 years ago|reply
[+] [-] sixothree|5 years ago|reply
[+] [-] bentcorner|5 years ago|reply
It doesn't make for a very exciting build, but it's very rote and dependable.
Also - build the entire thing high up in the sky.
[+] [-] Iv|5 years ago|reply
[+] [-] DanHulton|5 years ago|reply
At least, in theory. Drones are T8 tech, and I'm not _quite_ there yet to start putting that theory into practice. But that's the stated intent, at least.
[+] [-] zionic|5 years ago|reply
Satisfactory is freakin incredible and it is easily the best new game I have played in the last 10 years.
[+] [-] evo_9|5 years ago|reply
[+] [-] novok|5 years ago|reply
[+] [-] bcrosby95|5 years ago|reply
It's like if in the software world you could greenfield, waterfall, or spaghetti. There is no agile in Factorio, which is broadly accepted as most commonly the best way to develop a piece of software.
[+] [-] kevincox|5 years ago|reply
[+] [-] tyingq|5 years ago|reply
Obviously, you still need to do interviews, but keep some perspective when deciding. Don't overweight any one thing.
[+] [-] markus_zhang|5 years ago|reply
https://store.steampowered.com/app/1366540/Dyson_Sphere_Prog...
The leading programmer uses some sophisticated ways of optimization, including:
- DOP instead of OOP
- Leveraging GPU for parellely calculating certain stuffs
- Using a GTX 660 Ti for development
Here is a technical post but in Chinese. Lemme know if you are interested and maybe I can do some translation.
https://www.zhihu.com/question/442555442/answer/1711890146
[+] [-] jkingsbery|5 years ago|reply
When I started playing DSP at first, I was just putting stuff anywhere. Then I realized that there are advantages in trying to make things modular in a way roughly analogous with code. At the same time though, it is very different than code, as the design is spacial, not as abstract as coding. Refactoring code is very different as a result.
[+] [-] bb010g|5 years ago|reply
[+] [-] splonk|5 years ago|reply
I have turned down an interview because of Diablo. I got recruited a couple times by a startup that would have been a very good fit for me. The first time it was quite small and I chatted with the CEO about possible roles and product directions and such, but I'd just quit a long term job and eventually decided that I wanted to take a break for a while.
The second time was years later after it had grown a lot and gotten tons of funding over multiple rounds. As it happens, the CTO was also a friend-of-a-friend. When the Diablo 3 beta came out, I played a bit with him and our mutual social circle, and he demonstrated enough personality traits during that brief experience that I decided I wasn't interested in socializing with him more, and just turned down the recruiter after checking to see that he was still the CTO. I would have at least discussed it further if he wasn't specifically in a leadership position.
[+] [-] omginternets|5 years ago|reply
So really, this article is saying "live, self-directed coding is the best technical interview", which isn't very original.
[+] [-] tehjoker|5 years ago|reply
[+] [-] MrKristopher|5 years ago|reply
[+] [-] _e|5 years ago|reply
I used Zachtronic's TIS-100 [0] as a test variable and found the best person to work with. I believe it was a two way street because they saw an opportunity to work with someone who attacks problems a little differently. I am in real estate. Who would have thought knowing something about assembly would be helpful?
[0] https://www.zachtronics.com/tis-100/
[+] [-] S_A_P|5 years ago|reply
[+] [-] shawnz|5 years ago|reply
[+] [-] TruthWillHurt|5 years ago|reply
[+] [-] lmilcin|5 years ago|reply
More senior person is one that has more mature approach to their work. One that can get better results with less resources. Typically more senior people can also accept wider variety of tasks.
What is better results and what is less resources will depend on the project.
It has nothing to do with the knowledge or experience, in my opinion.
You can have good senior person get better results in a technology they have no previous experience with compared to a very experienced / intelligent / knowledgeable person that has track record of making bad decisions. Senior person will use their good judgement to warn the manager they are running outside of their knowledge and to know when they need to use some resources (like help) from somebody more knowledgeable.
A knowledgeable but less senior person may think they know anything but not be able to recognize they are trying to achieve something that is outside their area of expertise or not be able to recognize or accept they are bad at something.
For me senior developer is somebody I can entrust they will put honest, worthwhile attempt at making good decisions when it is called for and recognize when they need to come back for further direction.
Senior developers show ownership in that they seek to uncover problems and discuss those problems with the team, proactively and productively. Senior developers can smell problems even if they don't necessarily know the solution. They can act on the signs of the bad smell and maybe seek discussion (with architect? client? manager? team?) to figure out what is going on and what needs to be done further.
Senior developers understand there are many ways/levels to solve the problem and sometimes solution isn't more code but maybe procedural change or a shift in paradigm.
Senior developers can meaningfully help/direct more junior team members individually without taking over their projects.
Senior developers can keep working relationships even with difficult people or people they don't like.
And so on.