Coding. Interview as a Service – Part 2.

[tweetmeme source=”snarayan” only_single=false]

This is a continuation of the Interview as a service series. You can visit the part 1 here, where I talk about some of the common shortcomings in recruitment process of IT organizations.

Well.. to jump directly onto the subject, Coding. How many organizations have coding as a standard practice in their regular interviewing process? To your surprise, not too many. It is absolutely mind-boggling to how one can recruit programmers without actually testing their programming skills.

Programmers are supposed to program. Code. In any language, but Code. That is a absolutely non-negotiable. Any concept, any theory, if it is not demonstrated through code.. it is not correct. It is not good enough if one talks well, is well dressed and knows few technical buzzwords/jargons floating around in the industry. We’ve seen such folks struggle to write even the simplest of programs. And for all the referral process fans here.. these folks have lot of friends like themselves. They will refer everyone. No doubt about it. So you end up having a fantastic team of programmers who can’t program. Not program even if their lives depended on it.

This decision has to be made by the organizations. Do you want such posers in your system? If your answer is we’re fine with it, you can stop reading further. This one is not for you.

Ok. If you’re still here, I believe you understand the importance of recruiting right programmers. One of the important exercises to be done immediately is add 1 or more coding exercise in your recruitment process. Start with a simple problem, one  that requires some of the programming constructs and ask them to write code for it. Not pseudo-code. Actual program. Make sure the problem contains atleast 2-4 constructs like conditional logic, looping, modularization, data structure, etc.. as one sees fit. An example could be, from a list of numbers give me all numbers that are divisible by 3. As simple as that.

Look at how quickly one gets to solve the problem. In my experience, good programmers would be solving this the minute you’ve finished your question. Speed is not necessarily a measure of quality but can be treated as an indicator.

This is fine if you need just programmers. How about requiring good programmers? Do you need them? Yes.. ok lets go about doing it then.

Present a problem that involves more programming constructs and add a bit of design into it. You’d like to see how one goes about arriving at a solution. What are the approaches he takes. What are the approaches he doesn’t take, and reasons why. It can be a really exciting experience when you carry this exercise with a real good programmer.

I’d suggest doing this on premise and actually going through the whole process of arriving at solution. Thats the best way to do it.

One of the other approach I’ve seen is sending the problem to the programmer and ask them to submit the code. After submission, on premise, discuss with them about their choices and practices.

If you go with this approach, I’d rather suggest submitting code katas, screencasts.. This would give a nice idea of how a programmer goes about doing his job. How comfortable is one with his editor. What shortcuts does he use to get the job done. What classes he comes up with, etc..

To summarize, to build a good or even decent software organization, you need to focus on the kind of programmers you let inside. Better the programmers, better the kind of services or products you provide.


2 thoughts on “Coding. Interview as a Service – Part 2.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s