Interviews: Take home projects
While interviewing for a new role I encountered the dreaded take home project. Just to clarify, I found the experience very enjoyable, however, I must acknowledge that some engineers have called it “working for free”. The requirement for this take home project was building a multiplayer network game. Players connecting to the server are automatically matched with another anonymous player and proceed to duel it out in a game of Connect 4.
Back when I used to conduct interviews at Atlassian, I had misgivings about the ability of a 90 minute pair coding session to expose the traits of a mature developer. My current belief is that good developers are ones that demonstrate an ability to manage complexity. Meanwhile, most coding interviews still test a developers ability to codify an algorithm within a certain time limit. My ideal interview at Atlassian would be to provide the candidate with the Confluence code base and ask them to fix an actual bug or attempt to add a small feature. Alas, due to the custom nature of the Atlassian stack, this was never going to practical in a 90 minute session.
Make a visual to control the first impression
This recent take home assignment reminded me of that ideal interview scenario because it gave ample time and scope to tackle a complex project. You are given a set of requirements. It is your job to clarify requirements where possible and use good judgement when decisions are left up to you. Furthermore, you are building a user facing application that should not crash in production. Finally, you are writing a lot of code and you should structure it appropriately and come up with the right abstractions. Additionally, you can demonstrate your ability to test and deploy the code as well. All of these were daily expectations at past jobs. Awesome.
Here is how I approached the assignment. First I chose technology and frameworks closely related to the job description to illustrate I can contribute immediately. Next I set off on the implementation and after a few hours circled back to clarify any missing requirements (it’s hard to know what’s vague until you start to build). I spent a good deal of time making sure the code structure was intuitive and easily grasped by the interviewers. I assumed this was going to be the dominant evaluation criteria. I didn’t spend too much time writing test coverage, but I wrote some test to demonstrate I knew how to do it. In parts of the code I wasn’t completely happy with, I made sure to comment and explain what it did and how I planned to improve it with more time.
Grab and friend and try it out. Nobody around? Just open two browser tabs and play against yourself: https://conscious-thistle.glitch.me/
This take home project had no deadline. You could spend a day or a month on it, so it was hard to know when to stop. I decided to skimp on building the user interface since I’m not a designer and the role did not mention UI/UX skills. I made sure to document how to test and run the project in the repo README.md, but I was still nervous I overlooked some dependency and the project would crash unexpectedly and render my chances obsolete. As additional insurance, I went ahead and deployed a production version and tested it out with some friend and also made a YouTube video of the game working as intended. I definitely recommend giving some visual aids right off the bat. If they’re opening your email on their mobile phone or they’re busy and can’t compile your code, they can watch the video or play online and already have a positive impression by the time they get around to reviewing your code.
Check out the implementation: https://github.com/ted-piotrowski/connect4
I received word yesterday that I had advanced onto the next stage of the interview, which involves working at the company for a trial week. So I guess in my next post we’ll discuss, Interviews: Trial weeks. Goodnight.