In this video we explore what it means to have an invisible disability and how that impacts the way you design and build products.
When we review developer candidates in our hiring process, Code is King™. At the end of the day, no matter how creative, intelligent, and personable someone is, a developer needs to be able to put their ideas into code.
In Alley’s job postings for software developers, we ask candidates to include at least three code samples, along with a description of each detailing what they wrote and why, why they’re proud of it, and how it reflects their experience and abilities. We do this in lieu of “whiteboard” activities, sample projects, and the like (though in full disclosure, we will on rare occasion do paid sample projects if an applicant can’t produce code samples for one reason or another).
As more and more companies go remote, it will become increasingly more common to provide code samples with résumés. How should you select your code samples? What should you do to prepare them? Here are five things I look for when reviewing code samples:
1. Is the code clean, clear, and coherent?
There’s a joke amongst developers that you should write code as if the person who needs to maintain it is a violent psychopath who knows where you live. I want to hire developers who write code that others understand and enjoy maintaining. To that end, I expect samples to be readable and well-formatted. I expect methods and variables to be named clearly. I expect to be able to understand at a mere glance what a block of code will do. I don’t want to see clever, showboating code; I want to see code that anyone could read and understand.
2. Is the code well-documented?
Great inline documentation is the sign of a mature and thoughtful developer. When I read code samples, I hope to see a good balance of inline documentation. No documentation is lousy, as is too much. Inline docs should add to the code, not repeat it.
3. Is the code novel?
I’ve seen plenty of code samples that are little more than a call to WordPress’
register_post_type(), or something along those lines. That’s akin to applying to be a chef and cooking off-the-shelf mac and cheese to demonstrate your abilities. If you want to cook in our kitchen, you need to demonstrate that you can prepare a novel dish on your own. When I read code samples, I want to see some flavor. I want to see code that solves an interesting problem, and does so as simply and elegantly as possible.
4. Does the code show understanding of the problem it solves?
I see many code samples that are obvious Frankensteins of Stack Overflow snippets, copypasta that a developer stitched together without proper understanding of how or why it works. That’s not to say that using solutions found on Stack Overflow is a bad thing – certainly not! But it can be fairly obvious when a developer pastes something in that they don’t understand, especially when part of that code has literally no impact on the function in which it runs.
5. Is the code good?
Lastly, I want to see if the code is, as objectively as possible, good. Is it performant? Is it secure? Is it over- or under-engineered? Would I deliver this code to a client?
Code samples are an extension of your résumé. Be mindful of that and prepare them with as much care as your résumé, cover letter, and the rest of your application packet. Choose samples that you’re proud of, then proofread them and clean them up before you submit them.
I’ve covered some of the basics here, but there’s lots of room to go above and beyond. Be creative! Include automated tests with your code samples. Share links to the working product that code represents. Share code contributions you’ve made to open-source projects. Code samples don’t have to be boring; always be professional when applying for a job, but still have fun with them! If you’re interested in learning more about our hiring process, or seeing what positions we have available, check out our careers page!