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
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.
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.