There is no advantage to coding on a white erase board
- It doesn’t simulate how you actually write code
Do you write code on a dry erase board? Probably not, I don’t either. Why the hell would anyone expect someone else to do this in a stressful situation? - It excludes candidates who have interview anxiety
I had a candidate that I hired that was extremely nervous and struggled with test anxiety his entire life. We did a bit of interviewing and some code work, but it was minimal. He ended up being an incredible hire and couldn’t have made the game we shipped without him. - It isolates the candidate from feedback they are used to
Compiler warnings and errors, Intelli-sense (AKA: auto-complete) are all essential for coding quickly and efficiently. Working without those tools is indeed possible, but would you want to do that? We want to gauge an employees ability to code quickly efficiently, why take away tools that allow that to happen?
Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.
— Max Howell (@mxcl) June 10, 2015
Why have we been doing this so long?
- Computers were expensive and not portable
PC’s were expensive, difficult to setup and not portable at all. - There’s nothing to setup
Because computers were expensive, sometimes unreliable and require customization, it wasn’t super easy to get someone setup on the IDE of their choice. Not to mention, they were expensive! A dry erase board, a marker and an eraser (or a blue colored fingers afterwards) were all that were needed.
Let’s not do this anymore
Here’s what I do for interviewing candidates. Here’s a template for how I interview engineers:
Communication Skills
I look for candidates who can clearly explain the projects that they worked on, how they work, what part they worked on and why it was good/bad. I also look for them to clearly explain their ideas, aspirations and generally be someone I want to work with. No assholes please.
I bring up a problem that we recently solved organization and ask them how they would approach it. I compare the results of their approach vs ours on a high level and debate the pros/cons.
Architecture Skills
Let’s build a game together on a dry erase board. Let’s talk about how we store/fetch player data, know it’s going to scale. Now let’s add some limitations to it. I use this as an opportunity to do some software architecture together and get a good gauge to see how well this person can think about systems and how they fit together
Raw Coding Ability
How good are you at laying down some code? Let’s do that together:
- I provide them with a computer with a text editor, or bring their own laptop, and ask them to code a solution to a problem in psuedo code or their favorite programming language.
- Give a programming challenge they complete at home. We often give people a challenge that we email them at a set time and give them two hours to solve and submit their solution. We always use the programming language they will use in our day to day work. (Unity with C# for us)
- After they submit their solution and we feel they should move to the next interview step, I give feedback on their solution.
- How do they take feedback on their solution? Do they get excited or defensive? Do they want to learn from mistakes or from other senior engineers?
- Because we work in games, we have a unique opportunity to make a game together in the same way we would work in our office.
- Let’s make Pong 3D, give them a few hours to get the basics up and running
- Give feedback on their code design, ask them to improve any basic controls so controls feel responsive.
- Ask them to add a new feature, what would be fun? A power up that lets the ball travels faster, slower, etc.
- Once we feel like the game is fun and responsive to controls, we ask them how they would change this now that we’ve iterated on it to make it solid for ever day play.
Pro Tip: The best developers always have a cool side project they are working on.