Last month, I reviewed a lot of applications for our summer internship program. The interview process for interns is essentially a more brief version of our developer interview process, and during both we ask for a code sample (shared via jsfiddle or gist) that is representative of the applicant’s problem-solving ability.
I found that many candidates who had otherwise impressive applications either failed the code sample or hampered an otherwise excellent application. For the former, our application process worked; we only want developers (or interns in this case) who make software, and if you haven’t made software, you won’t have a good code sample. For the latter, however, I wonder if a little nudge in the right direction might help aspiring developers present their best self—to Atomic or otherwise. So here are some tips on submitting a good code sample!
1. Don’t pick something that you did in class*.
This isn’t an absolute; if you made an awesome class project that required creativity and many hours of work, it’s probably worthy. However, I saw many applications with various data structure implementations chosen as their code sample. Although these are great things to implement as a student, we want to see your interests expressed through software. Everyone has to roll their own linked list at one point or another. Not everyone decides to make an iOS app that generates rhymed couplets from trending tweets.
*It’s a great idea to document your class projects as part of your overall portfolio, though!
2. Do pick something that solves an interesting problem.
Emphasis on interesting. We’d love to see a problem you encountered in the wild and had to use your wits to overcome. There are tons of tutorials for implementing hash tables (a common project in foundational CS classes). But say that you wrote your own random dungeon-generation engine for your home-made role playing game. That would be an excellent selection because it shows your creativity and willingness to take on a difficult problem. Even if it isn’t perfect, it’s a great example of what we’re looking for in an application.
3. Don’t pick something that is 1,000 lines long.
We get a lot of really impressive applicants, which makes application review difficult. If I get a 1,000 line file, well, first of all, why is it so long? It might need some serious refactoring. It’s even more likely that I can’t spend the appropriate amount of time reading your file to find the good stuff… and I really want to see how bright and creative you are! A good code sample is typically somewhere between 20 and 100 lines long.
4. Do pick something that demonstrates good coding practices.
A completely awesome code sample that I haven’t seen yet would be this: a unit or integration test that exposed a hard to find bug in your software. Test-driven development (TDD) is like the strong nuclear force that holds Atoms together. Without it, we might not be Atoms. If you’ve got it, you just might become an Atom.
5. Don’t worry about giving us the entire program.
I found that submitting a complete program was a very common concern. And while it’s a great thought, it’s usually not necessary. First, we’re not going to read 10,000 lines of code, nor do we want to troubleshoot the many possible reasons why your program might not run on our machines. We should be able to infer from your variable names and the context that you give us what is going on in your code sample, and how it might fit into a larger program.
6. Do write something about your code.
Good communication skills don’t just apply to email and in-person conversations. Tell us the story of this code sample. Explain why you’re proud of it and what you learned by writing it. What are some challenges you faced? You can also do this in comments, but remember to sweat the details on your grammar and spelling.
The do’s and don’t’s above are meant to be a rough guide, and by no means is every good code sample going to adhere to all of them. I hope that they will, however, help you put your best foot forward when applying here or elsewhere.