Monday, October 14, 2013

The Software Chef - II

Imagine you are a music composer. Would you reel in a singer for your soon-to-be-a-hit song without having heard how they sing?

Now imagine you are a restaurateur. Would you have someone be your chef without having them cook something for you first?

Yet, we work in an industry where we seldom bother to ask a software engineer to write us a small program before we hire them. Why is that? Is software development deemed to be not creative enough? Not skill-heavy perhaps? Then why do we deserve these pay scales?

Your resume here says you can cook....

Some believe programmers can be "trained". All that matters is how intelligent and willing you are. This probably applies to our mass employers (need not name them here). Programmers are a commodity here.

Others believe it is inappropriate to ask someone who says they have been programming for 5 years to write us a program. Almost taboo. After all, programmers will have other opportunities where they are not required to write a program before they are hired.

It all boils down to what you are really looking for. Are you looking to add to your headcount because you told your client there must be 10, not 9, programmers on this project? Or, are you looking for someone who can fit right in and quickly start adding value to your team? Are you looking for someone who clearly enjoys programming, and would bring that same passion to the work they do for you?

The culture of programming

There is a culture to programming, just like with anything else where there are many ways to do something and many heads working together. That culture defines whether I put a space after the '=' operator, whether I use a typical loop or instead apply recursion, and whether I define my classes strictly by properties or by function.

Wouldn't it be useful if we had some idea of the programming culture a certain programmer is bringing into our organization? Does it suit your own programming culture very well? Would they bring a much needed breath of fresh air to your programming team? Or would your senior programmers end up having to constantly review their code so it all "fits in"? What would you have to live with, and what would you be able to welcome with open arms?

You do not necessarily need to use a programming test to weed out your candidates. But, there is so much to be learned from such a test about a candidate's programming acumen and style, that it would be absurd to ignore it. Does my chef candidate prefer to make their dishes too spicy? I'd prefer to know that so I could tell them before I hire them - "We like you. Your Baingan Bharta rocks. If you could just turn the chilli pepper down a notch for our customers.."

Cook me something...

Depending on your inclination to invest time in this, and the kind of team you are trying to build, one of the following testing styles should ideally suit you. The tests could be "offline" - the candidates do this when they can, while trying to balance their other responsibilities and their current day job. Deadlines could be extended on request.

Be My Sous Chef For Today: The ideal test is one that involves having your candidate do something you do on any typical day. That would involve sharing the whole code base with them, or have them work out of your own workstation. In fact, many startups do prefer this "spend half a day with us and do what we do" routine.

A Three-Course meal please: You could come up with an interesting problem that can be easily described in words, and that does not have a ready solution on the internet, and have your candidate solve it completely. Add bonus questions to see which candidates will push beyond the minimum requirements. Ideally, the solution should also have certain clear "culture" requirements like "use Object Oriented Programming" so that the candidate knows they will be assessed for this as well.

Cupcakes: The third best option would be to have them implement a helper routine or class you have developed previously as part of your own work. You should provide compiled classes that they will need (hopefully just a handful) as libraries to use, and perhaps even prepare a skeleton of the class they are expected to implement, complete with method names, arguments and even docstrings. This should be something they can do in a few hours.

Finally, you may choose to give them one shot at it, or provide feedback from their first submission and let them decide whether they would be willing to have another go at it. You will soon discover who is willing to go the extra mile simply because they want their programs to be "perfect" and "bug-free". (There is a reason I used quotes here)

I have made it a point to use programming tests as part of my recruitment process. If you try this out someday, let me know whether it worked well for you. What would you change? How would you make things easier?