What have you developed in your spare time?

Throughout the years, I’ve interviewed quite a few developers and I’ve recently been reflecting on what single question can give me the most information about the ability and passion someone has for programming.

I’ve concluded that this one gives me the best ammo to work with:

What have you developed in your spare time?

I love this question because it touches a few areas at once.  Spare time is a valuable resource which you usually dedicate to what you enjoy most.  Dedicating that to development is a huge indicator of where your passions lie. On the other hand, getting a “Huh?” or “In my SPARE time?” in return is probably a good indicator that this person isn’t what i’m looking for.

What they’ve been working on is also an interesting indicator.  Did they contribute to an open source project? Port a popular tool to a new language? Build some nifty tool to try out some new tech? Reading into the type of development they did and why can really give some insight into what motivates or challenges them.

It also touches on is their ability to stay up to date and be self-taught.  So much new tech and ideas are being made available and it’s hard to keep up.  It’s almost impossible to do so at your “day job”.

That’s why I like that question and use it as often as i can when interviewing candidates.

What is your favorite one?

Update:

I very much appreciate all the reactions and opinions regarding this specific topic.  In no way does it try to pigeon hole people one way or the other and is my humble opinion on my personal experiences.  The main point I want to stress is that I like to know where someone’s passions lie. If someone says “After working at my job all day, why should I work more at home?”  I totally agree!  It shouldn’t be considered “work”.

It also can (or should) be an occasional thing.  I try to spend 2-3 hours a week on average working on some idea, or testing out some new technology, or just reading a good book.  That’s hardly overwhelming.

I’d also argue that over time it becomes more important.  When you build a deep body of knowledge and experience in one field, it becomes your prism to view new problems.  Expanding your horizon can create some interesting (and sometimes surprising) ideas for new projects, ideas to solve stubborn problem from the past, or just some personal enjoyment.

The point is to have an itch regarding programming and feel the need to scratch it.

Scale using your users

I’ll use an example scenario to show what i mean.

As part of your site functionality, you allow users to create, update, search for, and view “thingies”.  This thingie has an address.

When people look at your thingie (er, that doesn’t really sound right), you want to display a nice dynamic map of the address with a cute little red marker.  You don’t have the coordinates for that address and therefore want to do some geocoding.

Having those coordinates would allow you to support all types of fancy location-based searches to tell if someone is near your thingie.  Even better, your cute little red marker would be in the right place.

So how do you go about doing this?  Well, some possible solutions could be:

1) Send a geocode request when saving/updating your thingie

A good first start, but probably not the best.  This has a few disadvantages, but for the sake of simplicity, let’s say the main reason  is you don’t want users waiting for unnecessary synchronous steps to complete.  Factor in network uncertainly, timeouts, etc. and you have a nice set of disasters waiting as your site grows.

You also realize that these geocoding services have limits on daily usage!  Too many thingie’s a day will be great for you, but you’d be tied to the limitations on your geocoding daily allowance and throttling requirements.  What to do?

So you come up with:

2) Create a queue to batch your geocoding requests

Better idea! When you create new thingies – and assuming you don’t have the addresses cached somewhere – you queue them in your uber geocoding async job.  It chugs away in the background sending nicely throttled requests and stops after reaching the daily limit.  Unfortunately, unless you want to pay lots of cash to up your daily limit, your queue will start getting longer and longer as it can’t keep up with new thingies.  Also, the geocoding might not even be done for thingies that your users are viewing right now.

Fortunately, this is a great scenario of how you can take advantage of your users to help you grow.  And you do it by leveraging client-side JavaScript.  Each user using your site is a potential resource which you can use to offload some of your work.  Help your users help you!

So why not have the users geocode for you?

3) Have the first user who views your map geocode it for you

I personally like this solution best because it’s being lazy.  When you have to display your map and that thingie has no coordinates yet, have the user send out a geocoding request from their client machine and use the results to show the map.  More importantly, send another async request afterwards to your server to save that value for future users!  Now you both get what you want at the right time.

Now assuming the geocoding API you’re using allows anonymous requests (like Google),  you don’t have to worry about daily limits, throttling issues, and other headaches.

The point of it all

Now this was all a hypothetical scenario to stress a point.  Lots of services today have an HTTP API accessible via JavaScript and this will probably grow and grow.  Align that with the increased horsepower of modern machines and improved browser JavaScript engines and you have an army of resources waiting to be tapped if you can figure out how to do so.  The great part is this resource scales linearly with demand.

The tricky part though is changing your frame of mind when writing features to consider this new option.  Why use server bandwidth and resources to do it when the client can do it just as well?

Have you had any scenarios like this?