Tag Archives: interviews


Depending how you look at it, my interview with RainBird was either non-existent featuring, at best, an informal chat; or it was a gruelling 5 year affair where I had to prove myself by working my way up the ranks of a totally different company. Either way it wasn’t your standard technical interview.

I’ve written on the subject of interviews before, but that was for an established company hiring a developer. At a startup you’re hiring a manager/secretary/handyman who can also code and do a million other things that need to be done, which is a very tall order. I’m not entirely sure how you’d go about doing that without knowing that person and seeing, first hand, what that person was capable of over a prolonged period of time.

This approach to hiring means you can dispense with the incredibly narrow (and often counterproductive) fallacy that you must hire someone with X years experience in technology Y1, because that’s what you use. RainBird needs developers who can code in Node.js, AngularJS, plus a smattering of C++ and Prolog. If we’re charitable I have 1 months worth of industry C++ experience… from over 15 years ago.

Despite that seeming handicap I like to think I have a good understanding of a number of programming languages, including Javascript, a good grasp of architecting systems, the ability to manage a team, a broad set of organisational skills and the ability to build furniture that means, regardless of the technology being used, the longer term benefit I bring to the company by far and away beats the incredibly short term drawback of me having to get up to speed with some new stuff.

1 And don’t get me started on the whole “must be a self starter; must work well by themselves or as part of a team; must have excellent communication skills”; what does that even mean? You’d be unlikely to hire a lazy illiterate who didn’t play well with others for something as simple as a job at McDonalds, let alone put them into a development role – please, for the love of God, stop putting this crap into job specs.

Side Projects

A number of years ago I was interviewing someone for a position as a senior software developer at a market leading financial institution. This was a job with a large pay packet, excellent benefits package and potential for reasonable bonuses, so we were being understandably picky. One of my [fairly standard, even now] questions was to ask what development activities he did outside of work. His response was that he spent all day working with computers and that he didn’t want anything to do with them during his free time. The interview was effectively over from that point on.

Software development, like most other technology disciplines, moves at a rapid pace. If you’re standing still you’re moving backwards and it’s frightening how fast you can become obsolete. While you can learn on the job it does require the job containing useful elements you can learn from, and the chances are what you work on day to day isn’t going to be bleeding edge.

The easiest way to reconcile this is with side projects; something worked on during your spare time that allows you to investigate new technology, new languages and new ways of doing things. Interestingly though, I generally find those developers who have side projects are not doing them due to a professional need to keep up, it’s from a personal need to learn. They’d be playing with this stuff even if they didn’t have to.

For me it’s this hunger to learn that makes a good developer. Experience helps, but you can gain experience, I’m not sure you can learn the hunger. It’s not just me who thinks this either, an increasing number of top name technology firms allow their developers to spend a certain portion of their work time on side projects. Even if the project itself end up providing no benefit to the company, the experience, lessons learned and morale boost this practice provides can only help the developer become better and more productive.

There is another side to this though. Developers can be fickle creatures and they can get bored easily. When this happens productivity crashes, and more than likely they’ll start looking for a new job. The day job is never going to be as interesting as the side projects buy its very nature – the product has to make money, and has to satisfy more criteria than simply “be fun“. By accepting that your top guys are going to have side projects, buy allowing them to find what interests them and spend a little bit of time during work time, you’ll find they keep themselves interested.

The question shouldn’t be “why is this developer spending a long lunch working on something not work related?“, the question should be “why aren’t all our developers doing this?“.


Interviewing effectively is a hard skill to master. Not only do you need to work out if the person being interviewed can do the job, but also if they’ll be the best out of all the candidates and if they’ll fit in to the team dynamic. All this in a very finite space of time. You’re not going to manage that if you just ask a few questions you’ve downloaded from the web.

I’m unashamedly evil when it comes to interviews. Once the niceties are over you’re going to find yourself face to face with my laptop and a copy of Eclipse. What happens over the next 45 minutes or so is entirely down to you.

This method of trial by fire is something I’ve endured a number of times, and every time I’ve hated it. You’re in the spotlight, you’re under pressure and you’ve got someone questioning everything you do. I recognised very quickly that this is a very powerful interview tool because it leaves you wide open and quickly cuts through any front.

What I ask you to write (which, incidentally, will be decided based on the preamble, the telephone interview if there was one, and your CV) is pretty much irrelevant, as is whether you finish it. The discussion and discovery that happens in the time is what counts. I’ll probe as many subjects as I can, dropping them as soon as I’ve determined if you’re strong or weak in that area. All of this on a platform you may not be familiar with because I use OSX.

You can use the internet because it’s not about what you can remember, it’s about how you apply knowledge; you can ask questions – in fact failure to ask any questions will probably have you flunking the interview; you can say you don’t know, we’ll move on – it is actually OK not to know every tiny thing I question you on.

It’s brutal, I know. I’ve been there. You’re constantly off guard, the goal posts keep moving, the questions keep coming and during all that someone is expecting you to code at the same time. Do well in that and the job itself will be a cakewalk. But hey, if you’ve made it to the interview then I obviously think your CV matches what I’m looking for, so you shouldn’t have a problem 😉