I was sitting at my desk today, sunlight streaming in the window of our SoHo office, my mouse hovering with dread over the words “click here.” The past several times I’d gotten this email, it’d been quite a disappointment. I didn’t know it, but I was about to get a very pleasant surprise.
Striders take our code test very seriously. We’ve spent a lot of time refining it, and it’s become an excellent way to assess a candidate. It’s far more effective at screening for good candidates than the industry-standard whiteboard-style challenges and trivia tests many other companies use. That’s why it’s so painful for me to see people falling into the same pitfalls.
It’s also why it was so refreshing to see someone nail it, as they did today.
So what makes a great Stride code challenge? Well, five things.
1. Keep it simple
First of all, it ought to be the simplest thing that could possibly work. People bring in huge templates or external libraries and then use little to none of it. Not today; this person nailed it. They had to break their code up into classes in order to make it maintainable, but they didn’t fragment it into tiny data classes, which create clutter.
2. Explain your decisions
Second, it should show some familiarity with the trade-offs in design choices. This person included a discussion section in their README that clearly outlined why they made the choices they did, and what consequences those choices have for future maintenance.
3. Make the grader’s job easy
Third, a great code test solution really shows that the candidate thought about what life would be like for the next developer to touch their code (aka the grader). Many submissions come in without so much as a README. This one had step-by-step instructions for getting up and running, and it used a build tool to make everything easy. Running that command was like getting a neon green Christmas tree of passing tests. Thank you, Santa! It’s beautiful!
4. Write maintainable code
Fourth, the code should show an eye for maintainability. Things should be named well and tested thoroughly. If a candidate throws together something sloppy that can’t be easily modified on a code test, what will they do on a real client engagement? Today’s candidate clearly had reviewed their code for clarity and built an extensible system.
5. Follow your language’s conventions
Lastly, we get a lot of candidates submitting code tests in languages they aren’t familiar with, and you can see clearly when it’s actually Java code written in Ruby, or PHP written in JavaScript. Code samples should follow the conventions of the language they’re written in.
For example, Ruby methods that return a boolean value should end in a question mark. If you snake_case your JavaScript, that shows you haven’t spent much time learning from other people’s JavaScript. This code sample nailed the Ruby style, using symbols instead of strings where appropriate and preferring iteration to recursion.
Conclusion
These guidelines won’t just help you with your application to Stride, they’ll help you with code tests from any company. Keep it simple, discuss trade-offs, make it easy for the grader, write maintainably, and follow conventions!
William Jeffries
