5 ms·
I agree. We recently got rid of our more traditional "tech screen" and replaced it with a 90 minute realistic programming interview. We have 3 tests we give de
by jaaron 6y ago
I agree. We recently got rid of our more traditional "tech screen" and replaced it with a 90 minute realistic programming interview.
We have 3 tests we give depending on the role (game dev, backend, or SRE). The tests replicate typical work the engineer would be doing, such as adding functionality to a 2D game, developing out a web service for a given API, or debugging and optimizing a linux server. We provide a development environment remotely, or the engineer can use their own. They code/work on their own, without needing to share their screen, though we're on the line if they have questions or just want to chat. The interview itself takes about an hour and we schedule in buffer time before/after to setup and to debrief.
We've designed the problems to be (a) relative, (b) scalable and (c) fun. By scalable, I mean that the problem should have a simple, naive solution that most engineers who work in that space should be able to solve quickly and easily, while also having enough space for more advanced engineers to extend the problem and show off a bit.
So far we've gotten good feedback from this approach, even for candidates who haven't passed. I know 90 minutes is a long time, we but feel that with this test, we get a good, realistic work sample, and we can forgo a lot of the other less effective interviews.
(plug: we're still hiring [1])
[1] https://www.singularity6.com/careers https://www.singularity6.com/careers
- throwaway815190 6y agoIs the 90 minutes a time limit? And are you required to do it all in one sitting?
- lazyant 6y ago"scalable" (not sure about that name) questions or scenarios are the best to gauge competency. I do them although it's pretty hard to come up with good ones. A fallback for shorter question is to ask for a something with many possible answers, as typically somebody more experienced will have many answers besides the most popular ones. (server A can't ping server B, what can be the reasons?)
- jaaron 6y agoYes, scalable problems are the best, but can be difficult to devise. A lot of folks tend to go the "optimization" route, by having a problem with multiple ways of extracting more performance, typically by better algorithms or data structures. These are ok, but not great. Most candidates will reasonably start with a simple naive solution that works and then try to optimize, but time may not allow for that and the optimization may require significant rewriting of the solution. So unless you either start out with the optimized solution or you have a lot of time, you're unlikely to ever see those solutions. I tend to prefer scaling via scope. For example, for our game engineering test, we start with a half-finished 2D "game" (think something like pacman). We then have a list of functionality that can be added with increasing difficulty. This allows us to measure "seniority" by both (a) how far down the list they get and (b) the quality of the individual solutions. Another example is starting with a single threaded solution and then extending into a multi-threaded or multi-process solution.
- deleted 6y ago[deleted]
- scollet 6y agoAre all the roles strictly senior?
- jaaron 6y agoNot strictly. At this stage of the studio, we are orienting to a more "senior" team, but that basically means senior+. We're not particular about titles as it's still a small, flat team. As the team grows, we'll gain the mentoring capacity for more junior talent, but for now, we're focused on an experienced team.
- scollet 6y agoThanks for your response. I just started game dev this year, so I'm slowly gauging the complexity the same way I might gauge complexity in my eng domain: fullstack web development. If you have the time, what are your clear indicators on who is a competent mid-level game systems engineer? I'd love to apply your advice to my portfolio before I feel ready to assume that role.