Article summary
Atomic interviews quite a few folks for entry-level software development positions each year. Part of the interview process involves a programming challenge. We try our best to present challenges that are similar to the work we do day-to-day, rather than asking candidates to solve obscure algorithmic puzzles. Generally, though, our candidates start from a blank slate–and that’s not typical of our day-to-day work.
Usually, we’re working in a large codebase with established conventions. We need to understand the architecture, discover where to make changes, and know when to refactor before adding new functionality. Our programming challenge this year happened to include a small codebase as a “starter kit” for our candidates. It was closer to our real work and a much better evaluative tool as a result.
What We Learned
Programming is difficult. There’s a whole lot to learn. So it makes sense to start with simpler problems and move on to more difficult ones. What this means for most students is that they’re largely focused on producing their own code, and rarely asked to read and understand large codebases during their college years. This is unfortunate because it’s most likely the first thing they’ll be asked to do when joining a software team. It’s really valuable for us as interviewers to know what experience students have–some will have significant practice from internships and personal projects, and others will have very little.
With a “reading” component in our challenge, we found that some candidates were able to separate themselves from the group in terms of being able to follow and understand the program logic. Others struggled, and they were clearly in unfamiliar and uncomfortable territory.
Ways to Add “Reading” to Your Program Challenge
So, how do you make this part of your process? Here are a few ideas to start with:
- Ask candidates to spend some timing reading a codebase and answer a list of questions about it.
- Challenge them to find and fix a bug in an existing codebase.
- Ask candidates to add a new feature to a working application.
- Try a mix of all of the above.
If you don’t currently require candidates to read code as part of your interviewing process, give it a try! We’ve found that it really helps when interviewing entry-level candidates and provides good clues on how to evaluate their programming experiences outside the classroom.