It's no secret most software engineering interviews leave a lot to be desired. As an interviewer, do you ask candidates about their past experiences? Do you have them solve a problem on the board? Or even more awkwardly, do you have them work on a computer other than their own? It's understandable that lots of people get nervous and bomb these interviews. I've been there, on both sides of the table. It's not a fun day. So how do you make sure you get the most out of a couple hours of interviewing without making the prospective employee a nervous wreck? At Doximity we start with a coding assignment.
Why a Coding Assignment?
We believe the candidate should be allowed to showcase their skills on a practical and relevant assignment. A few days before the interview, we add candidates to a GitHub repository and provide instructions on how to complete the assignment. This allows them to work with familiar tools on their own computer, without the unnecessary pressure of someone looking over their shoulder. We want to make sure someone is capable of solving the problem at hand with clean code. Memorizing an implementation for an interview doesn't prove anything.
The Evolution of Coding Assignments
Our first stab at creating a coding assignment wasn't great. At first, we asked candidates to write an air conditioner controller simulator in Ruby. The unit would be responsible for ensuring the temperature stayed within 3 degrees of the desired temperature while being as cost efficient as possible. This assignment allowed candidates to showcase their OO design skills and Ruby knowledge. However, it lacked opportunities to showcase the use of JavaScript and required very little knowledge of Rails DSL -- both skills needed to perform the actual job.
We scrapped the original assignment for something more practical. We asked the candidate to create a simple blogging engine with authentication, seed data, specs, caching and a few performance optimizations. This assignment was much better at allowing engineers to showcase their Rails DSL knowledge, but it was too open-ended. We got submissions that vaguely fit the requirements and neglected implementation details. A lot of the details we found valuable for gauging knowledge and experience level were missing. This was totally our fault, so we decided to change it one more time.
Current Assignment
The third and current installment does a much better job of allowing the candidate to focus on well-defined tasks. Still using this blog engine, we ask candidates to add search and a simple scoring algorithm class. Though this assignment usually takes less time to complete than the previous one, it gives us more insight. We're generally able to gauge OO Design, JavaScript knowledge, Rails DSL and Ruby experience. The main difference with the current code is that the candidate starts with a much more feature-complete base application. Therefore we remove distractions such as: "Which gems should I use?" or "Should I install Bootstrap?" Instead, the majority of the time is spent on the things that help us determine if we want to invite the engineer for in-person interviews. And because it takes less time to complete, the current assignment is more respectful of the applicant’s time.
To keep things fresh, we tend to change the assignment requirements every few months.
There's some controversy regarding unpaid assignments. I've talked to other companies and interviewing departments who swear by a temporary contracting period prior to full-time hire. We've done this in the past, and I am not totally against this. The problem arises when the candidate is already employed and either has no free time or can't legally take on paid work for another company. Our opinion is that as long as the assignment can be completed in a reasonable amount of time, say 2-4 hours, it's an investment the applicant should be willing to make in their career.
The In-Person Interviews
During the in-person interviews, we use code from the assignment as talking points. We can then dive into the thought process behind some of the decisions made by the engineer. There are no absolute right answers; it's an exploratory discussion between the interviewer and interviewee. We may choose to ask questions regarding possible optimizations, current limitations, and alternative solutions. Having real code as a starting point allows us to limit interviews to two one-hour sessions. At the end of that time, we make our decision.
We continuously try to fine-tune this hiring process by using feedback from candidates. If you have any interview tips, we'd love to hear them. Likewise, if you're interested in working for Doximity, we're hiring.
Hope you enjoyed a peek into our recruiting process. I expect to write a few more posts about our engineering culture and processes in the near future. Follow us @dox_engineering if you'd like to be notified about updates to this blog.
Thanks to Jason Seifer, Jey Balachandran for reading drafts of this.
