The background to our decision to hire was simply that we have found we have more work to do than we have time available and that we expected this to continue. So while last year we had two people help us for short term projects, we decided that it makes the most sense to expand the size of our permanent team. Both people who worked with us last year had moved on to other exciting Haskell jobs.
Applications
We posted the job notice on our company blog (which is syndicated to Planet Haskell) and also to the haskell and haskell-cafe mailing lists. We probably should have also posted it on the CUFP jobs page.
We were pleased to get a total of 42 applications, of which 19 merited serious consideration, and we eventually settled on a shortlist of 7 to interview. We also received a couple expressions of interest from people looking for part-time work.
Advertising openly was certainly the right decision, though it does entail a fair amount of work. We received applications from well-known members of the community plus many excellent applications from people we did not know or who we were only peripherally aware of. In the end, we made two offers to people we would not have asked directly: one person we did not previously know and another person we do know but who we would not have thought to ask.
The main features of our job posting were that it was not geographically limited, the work is, we think, interesting but the rate of pay we were able to guarantee was not especially high. All of these affected the kind of applications we received. We are in the lucky position that we do not need to sit in the same physical office as our co-workers, which gives us access to a big international pool of talent. The people who applied were quite dispersed geographically, covering 21 countries. There were 18 people from the EU, 8 from the US and 16 from elsewhere including several from Australia, Russia and Ukraine.
We know that we cannot compete with large companies in terms of pay, but on the other hand we are able to offer a great deal of flexibility and work that involves using Haskell and interacting with the Haskell community. Many people wrote about their love of Haskell and functional programming and how they would like to make more use of it professionally.
Decision process
When it came to the decision making process, a key issue was that we had decided that we would need two people rather than one. Hiring two people gave us the opportunity to increase the range of skills in our team by picking people with different skills and background experience. We decided that we should aim to select one person with a mainly academic background and one person with more business and consulting experience.
Ian and I both read all the cover letters and résumés. We didn't want to influence each others initial assessments so we read everything independently and compared notes at the end. There was a wide variety in style of résumés, from 1 page bullet lists of education and experience, through to 9 pages including descriptive paragraphs. I don't think one style is a particular advantage over another; those with short résumés tended to come with longer more descriptive cover letters. A few résumés made it quite difficult to guess how much Haskell experience the applicant really has.
We decided to make an initial "longlist" by restricting our attention to people with three or more years of Haskell experience. That combined with a little more discussion and comparing notes between Ian and myself gave us a longlist of 19 people. This was quite a spectacularly talented group of people, everyone with some mixture of Haskell programming and other commercial experience. It included 5 people with 10 or more years professional programming experience, 7 people with masters degrees, 3 people with PhDs and 7 people who have used Haskell in a commercial context.
The next step of picking an interview shortlist was of course very difficult. Our aim was to interview only a handful of people. We reread and discussed letters and résumés.
It became obvious that we had a clear first choice on the academic side. In a sense we had a shortlist of one. We were thus in the slightly odd position of not shortlisting several people with excellent academic qualifications, but relatively little commercial experience.
On the commercial side, the deciding factor was (our perception of) the combination of Haskell programming skill and business experience, the latter especially in a client-facing role. Of course you cannot really assess programming skill on paper, but before the interview stage one has to go by what people say about themselves and their achievements.
We eventually picked an interview shortlist of six people on the commercial side, plus the one person on the academic side. We sent out notifications to everyone who had applied. Five of the six people had experience of either running their own company or otherwise acting in a client consulting role.
Interviews
For the interviews we decided to use IRC rather than phone or Skype. Ian devised a technical problem to use in the interviews. We had candidates log in to our server so that they could view, edit and run code during the interview. We used a shared console session so we could all see. We scheduled two hours for each interview and ended up using more or less the full time. The technical part ended up taking around 40-60 minutes and we spent the rest of each interview chatting about past experience and future plans.
The purpose of the technical problem was to assess more directly candidates ability to write Haskell programs that can be used to solve real world problems, where memory usage and performance are important. The problem was all about evaluation order and memory behaviour. We started by asking candidates to look at a short program and say what shape they would expect the heap profile to be. That would then lead on to a discussion of what things are evaluated at what stage and how much memory they are taking in the meantime. For the final step we asked candidates to rewrite the program to run in constant space. We felt overall that the technical problem was quite useful and we allowed it to become a significant factor in our final decision making process.
The choice of problem is based on our belief that a good understanding of evaluation order is very important for writing practical Haskell programs. People learning Haskell often have the idea that evaluation order is not important because it does not affect the calculated result. It is no coincidence that beginners end up floundering around with space leaks that they do not understand.
We had about a week of interviews following which we made two offers. With our shortlist of one on the academic side, the outcome was a foregone conclusion. On the commercial side we based our decision both on our prior reading of résumés etc and also on how things went in the interview. Again, the key factor was the combination of Haskell programming skill and consulting experience.
Reflection
I think all in all, given that we have never run a hiring process before, that we did OK. We could however have done better with keeping candidates informed about the process and expected timeline. The period for applications was perhaps unnecessarily long. I would welcome any feedback from people who found the process painful.
Ian and I would again like to thank everyone who applied. We appreciate the thought and effort people put in and that so many people are interested in working with us.
World map originally by John Harvey and others, CC-BY-SA.
]]>
