rococo - then rubble

For my birthday celebration last year I did something a little different: a Birthday Challenge. What is a Birthday Challenge?

… a birthday challenge is essentially a goal, generally in the form of physical achievement, to make your birthday more memorable than the last. Usually the number of your years lends itself to the base of your challenge.

– from http://www.birthdaychallenge.com/whatis.html

Last year’s challenge (my first) consisted of a 26Km run, 26 pullups and 2.6L of beer. For this year’s challenge I’ve decided to run a marathon, which has been a long-term goal of mine. I’ve signed up for the San Francisco Marathon this July 29th. This is great for a few reasons: this distance aligns with my age (26.2 miles vs 27 years), the date almost falls on my birthday, and I’ll by living in the Bay Area this summer.

I haven’t yet decided what all of the events will be for this year but it will probably include another physical challenge and some kind of eating or drinking. Wish me luck!

One of a software engineer’s most critical skills is the ability to read code. In my experience developers spend far more time and effort reading code than writing it. Others agree (Joel On Software, Jeff Atwood). It stands to reason that this is a skill that should be looked for during the interview process. I’ve found that code critiques can be a valuable tool in this regard.

They answer questions such as: Can this person see bugs? Can they comprehend an unfamiliar piece of code? Are they opinionated about what good code should look like?

For this purpose I came up with a stack-like class that fits on a single sheet of paper. This class has a variety of flaws ranging from the painfully obvious to the subtle. The candidate takes a few minutes to look over the sheet and then we spend 10-15 minutes talking about code. The issues include:

1. Poor method naming (”doIt“)
2. Poor time complexity (O(n) when O(1) would do).
3. Duplicated code
4. Handling of error cases (does a pop on an empty stack corrupt the datastructure?)
5. Memory leaks
6. (Java-specific) Misimplemented Object#equals method
7. Input validation (does pushing a null onto the stack cause later failures in the contains method?)
8. Inconsistent and/or non-existent comments

What I like about this process is that it give a very fine-grained scale to understand how someone thinks. If they don’t mention something you can start a conversation on that topic. “So what do you think the time complexity of pushing N items would be? Could it be better?” “What happens if multiple threads use the class at once?”

So far I’ve tried this on a small sample of candidates and it has been a reliable discriminator. One person failed miserably, one person more or less aced it, and a few more landed somewhere in the middle. With more time and experience I hope to refine the process further. I would love to hear from others who have thoughts or experience with this technique.