March 15, 2012

how to get your code submission accepted

I have been reviewing a lot of code submissions for potential candidates to hire. And a lot of candidates make similar mistakes. Here is a short list of things I would recommend to someone submitting a code sample to an employer:

Test-drive your code

All of it. No exception. Write the test first and then code to the test. Make sure your tests are proper unit tests (i.e. testing a single function). We get a lot of submissions with a few higher-level tests that are there to prove that the sample input we give out actually produces the sample output. These tests are okay, but they are not a replacement for unit tests. And if you're really serious about your submission, read TDD by Example before writing your first line of code.

Do not add comments

It is perfectly fine to submit your code without any comments in it. In fact, that's encouraged. This is contrary to what most schools are teaching but it is still the right thing to do. On the teams I've been on, junior programmers add comments to the codebase and the senior ones delete them. The only documentation you should provide is a README to quickly state your assumptions and to explain how to compile/run your code. If the comments are really necessary because the piece of code is complex, rewrite that piece of code.

No showing off

Do not over-engineer in order to show off. Your submission should not be a showcase for all the patterns you know. If you're coding in Java, keep interfaces to a minimum -- they are usually noise. In general, do not do anything based on potential future requirements. The goal is to keep your submission short. The only form of yak-shaving that I could potentially agree with is error handling. If you're so inclined to handle all possible failure scenarios, go ahead.

Simplicity is key

Keep your methods short and readable. By short, I mean less than 10 lines. Try not to nest your control structures inside one another. A triple-nested if within a try/catch block is a huge turn-off. Related to that, following the Single Level of Abstraction concept is a good idea. For what it's worth, you might also consider following a relaxed form of the rules for doing Object Calisthenics. Unless you're solving the code problem using a paradigm that is not object-oriented, in which case you are truly awesome and you will stand out from other submissions.

Whatever you do, keep your code submission simple.

March 14, 2012

a bone to pick with the googlebot mobile crawler

I am spinning off my own instance of Socialite in the form of Octopus News. However, once in a while -- maybe once a day -- I would get an email nicely notifying me that an exception had just been thrown.

The exception looked like this:
A ActionView::MissingTemplate occurred in submissions#index:

 Missing template submissions/index with {:locale=>[:en, :en], :handlers=>[:rhtml, :haml, :rxml, :builder, :erb, :rjs], :formats=>["*/*;q=0.9"]} in view paths "/u/apps/octopusnews/2012_03_02/app/views", "/u/apps/octopusnews/2012_03_02/vendor/bundle/ruby/1.8/gems/kaminari-0.13.0/app/views", "/u/apps/octopusnews/2012_03_02/vendor/bundle/ruby/1.8/gems/devise-1.2.1/app/views"
 vendor/bundle/ruby/1.8/gems/actionpack-3.0.5/lib/action_view/paths.rb:15:in `find'

And the user in question is actually the googlebot mobile crawler. To fix this, apply the following gist. The gist is a monkey patch of the Mime module that will allow your Rails app to parse the request header coming in from the googlebot.

It is good to know that the exception emails are relevant again.