That time of year has come again where my current client has committed to more development work than the existing team can complete by the promised launch date… [Sigh…] We’ve all been there. It’s the unfortunate, situation that occurs when months of work is spent on improper and misguided business priority. Startups and young companies get a pass here because their environment and focus changes rapidly as they’re still trying to figure out what works for their business.

 

But for a lot of companies, inevitably the day comes… SLAP! ..and a new or potential client sets a new priority for your team that has little to do with the focus of prior months. Now the clock is ticking and “we got a long way to go and a short time to get there” because the sales team has already promised a launch date. [beware sarcasm ahead…] So the logical thing to do is throw a lot of money and developers at the problem. With a little luck, pizza and late hours we’ll all be high-fiving this fall when the project is finished.

 

My client is in full-on hiring mode now and we’re getting candidate submissions from Careers 2.0, TopRubyJobs.com and every tech recruiting firm in town. In addition to the standard resume, we’re requiring serious candidates complete a coding exercise for review by the interview team.

 

Over the past couple of weeks, I’ve reviewed well over 20 code submissions. Sometimes the process has been surprisingly pleasant as we’ve seen some exceptional code submissions. Other times it has been pretty painful… Pain is actually a good thing when reviewing code submissions for potential candidates, because it’s not the pain of reviewing bad pull requests for production applications. In end, pull request pain is what we’re trying to avoid. We started requiring the submission of code exercises about 6 months ago and have tweaked the process a bit along the way. We’ve found that with the right approach, code exercises are an invaluable tool to help gauge the eventual code quality of potential candidates. By no means is it fool-proof as I’m sure we’ve passed on some talented developers; but for the most part, the process has worked well. It has been a great tool to see whether or not we want to move forward with the final stages of the interview process and whether or not the potential candidate would work well within the existing codebase.

 

As one of the interviewers, I thought I might pass along a few words of advice to any potential candidates out there. Keep in mind that much of what I say probably applies to code exercises for any development position – not just the openings we’re looking to fill. Additionally, at the end of this post, I mention a few personal take-aways I’ve absorbed from the interview process.

Exercise Guidelines (for context)

Without giving readers the entire example (and without giving any potential candidates a lead on any of the specifics), here’s a quick overview of our coding exercise guidelines. We try to leave the implementation details wide open for interpretation, but steer the candidate in somewhat of a general direction.

 

  • Read a dataset from a provided set of CSV files and perform some calculations.
  • Print your results to STDOUT.
  • The developer is in complete control of what gems they choose to use. …if they choose to use any.
  • There is no database requirement. Use one or don't use one - we don't care. The solution can be completed with or without the use of a database.
  • Approach the problem as if you were intending on deploying this to a production environment.

That’s it!

Take Advantage of the Opportunity

Not everyone has the time or aspires to be an open source contributor or active blogger; and thus, many developers have a pretty lightweight public Github profile. I get it, you use Github for work stuff only – that’s fine. Everyone has different priorities and if you haven’t had the opportunity or the time to put your work on public display, here’s your chance! Treat the exercise as though you actually want others to see it. In this case it’s a significant factor on whether or not we think you’re a good fit for the job.

Write for Production

Coding exercises for interview purposes are more than likely contrived and simplistic, but hopefully it’s fun too. When you’re submitting code, the reviewers are looking to see whether or not it is production quality regardless of what the code is supposed to do. Take some time and put some effort into the solution because code really smells if you don’t. Prove that your solution has evolved a bit over the course of your work – iterate on it. As with any first-pass on code, it could probably use some refactoring. Approach the code in the same way you’d develop a feature for an application you’re working on. 

Source Control

I’m actually a bit surprised that I’m even mentioning this… However, we’ve gotten a lot of submissions through .zip or .tar.gz files. Really?! No one will ever merge something from an archive file into a production codebase. If they do, you’ve just found an organization that should go on your employment blacklist. Submit the code in Github or Bitbucket… Not only does it make the code easier for others to review, but it gives the reviewers some insight into your development approach through the commit history. Additionally, we’ll also be able to tell if you were B.S.-ing about your TDD disciplines.

Tests…

Yes, we’re looking to see if you test your code. If you ever get past a coding exercise to the next round of interviews without writing tests – employer blacklist. On more than one occasion, we’ve seen submissions without tests… Surprisingly, I’m happy to see these because I can automatically dismiss it without any further review. You’ve just made my job easy – and I appreciate that.

Good Tests…

This is without question the most important thing that I’m looking for when reviewing code submissions. I don’t only want to see tests, but thorough and valuable tests. Show clear intent and value in your tests and make sure the tests cover the important areas of your work. Use tests to help you flush out your final solution. It’s extremely important to approach the problem with TDD in mind.

Ruby 1.8.7

Yes, we actually received one solution indicating in the project README that it targeted Ruby 1.8.7. “I haven’t updated my laptop to the newest version yet…” For crying out loud, man! Ruby 1.8.7 hasn’t received bug fixes since June of 2012 and all security fixes stopped almost a year ago (if you don’t believe me, read this). This type of thing is nothing more than developer laziness and suggests you know little or nothing at all about RVM or rbenv. Targeting the latest version of Ruby is nothing more than a quick shell command to set up! Dial 187 on Ruby 1.8.7 and take this as an opportunity to try something new if you haven’t already!

Database Usage

As I mentioned earlier, the coding exercise in our case can be completed without the use of a database; but the decision to do so is left entirely up to the developer. If someone decides to use a database, it’s usually SQLite3 (which is fine because it works everywhere). However, we are going to check to make sure that you’re not specifically targeting SQLite3 because there’s no web project I know of that would use that in production. Use the ActiveRecord ORM and for Pete’s sake, don’t write inline SQL. Yes, we had a submission that had a hard-wired SQLite3 dependency with inline SQL. In my experience, developers (of any language) who think inline SQL is an appropriate practice instead of only-rarely-as-an-exception are cancer to teams. If you don’t believe me, hire one and let me know how that turns out for you. Inline SQL is poor programming practice even if you have tests covering the functionality.

A Rails App? What about STDOUT?

When instructions clearly state to “print all output to STDOUT”, don’t submit a Rails app. Additionally, don’t use “rails new some_application” to generate a project template for the code submission because there’s going to be a lot of unnecessary bloat in your solution… We originally left it up to the developer for the choice of whether or not to write a Rails app, but we’ve since changed the instructions to specifically ask for console output. Previously when Rails apps were submitted, we critiqued the whole project – controllers, models, routes, tests, HTML markup, etc. Now when Rails apps are submitted, it’s painfully clear that the instructions weren’t followed and projects get immediately dismissed. It’s incredibly important to follow the given instructions…

In Closing…

Not only has the code submission and review process been good for our interview process, but it has been good for me as a reviewer… One of the best things you can do for yourself to “level up” as a developer is read, inspect and execute a LOT of code. Over the last several weeks, I’ve done just that.  I’ve seen some approaches to problems that I would never have considered. I’ve learned some Ruby “trick shots” that I’m probably going to use in the future. …and I definitely gained some insight into what others will probably be looking at when the time comes for me to submit my coding exercise.