Developer Interviews – Code first approach

One of challenges that I’ve seen people facing while executing projects is that they often end up having people in their team (many a times screened by some experts) who are not good at writing quality code. There could be many arguments that writing code is not the only thing when working in an IT organization, but I have closely observed and built my theory.

Most of the projects that we execute or applications that we build do not require us to write code from scratch. Which means, either someone has already written some code (also means the design already exists) and we are extending the design specifications, or we just maintaining it only as much as it is required to keep our end-users happy. Software evolves, it is not created!

I am sure some of the readers would be working on green-field projects and they would disagree to the above said. I, myself, have worked on several green-field projects but these projects are very rare to find. Most often, projects that are on the verge of retiring tend to produce green-field projects or projects that cater to a distinct set of requirements to be used for a specific purpose turn out to be green-field projects. But this number is small. Or putting it in other words, the profit made from these projects is less.

Believe me, the skills required to design a green-field project are same as required to maintain a version of a “live” project. That’s where the catch is. Maintenance projects aren’t easier to develop. Writing code within the boundaries of design created by someone is more complex than defining your own boundaries and writing code within them. Oh, of course if we do not want the code to be maintainable, readable, scalable then we ought not worry about code quality in a maintenance project.

Software evolves, it is not created! And this evolution requires developers to be able to write code while they perform other monitoring, reporting and rewarding tasks. And even if you or your team members are engaged in any non-development tasks, being able to write code is the easiest way to hone your analytical skills.

So with this philosophy, I prefer candidates who may not necessarily perform the task of development on a regular basis but can write code if the need be. Now, you don’t need to be code masters. You need to be logic-crackers and the “CAN-DO”-attitude man.

When interviewing a candidate we usually check his communication skills and attitude, technical & analytical skills if he is required to write code, presentation, leadership and risk taking abilities for senior roles and …. (may be a HR can add more qualities screened). But all roles need the candidate to be sound in logic. So for testing logic, I prefer to give some very simple program to write in any language of their choice. English is also one of the languages! Believe me I see 40% rejections at this stage of interview. Candidates with niche skills sometimes are not able to think through the solution. May be it is the stress, or may be it is that they never expected a question that simple. By asking someone to write code, you aren’t checking their development-quotient. You are instead checking if they will be able to apply logic (I am not referring to Mathematics, here) in problems of smaller or larger scale.

Like say, a favourite question of mine is,

With simple mathematical equations, write a program that will swap two numbers

There are several solutions to this problem. What this problem statement refers to is applying the logic we learnt long ago.

Another simple program that I generally ask them to write is,

While iterating through 1 to 100, for every odd number print “Thumbs” and for even numbers print “Up”. For a prime number, print “ThumbsUp”

One more,

If for every 3 steps that I take ahead, I take 1 step back. When would I cross a point that is 100 steps ahead of me?

That’s again mathematics – no programming language knowledge required. And if you are speaking to a candidate who knows a programming language, you better ask them to write a simple program of say factorial, or Fibonacci series. We are not looking at perfect answers here. We are looking at how they analyse a problem, their approach, their willingness to do something that they haven’t done since long.

When questioning on software design there are ample of questions available on the Internet and almost all candidates would have gone through them. But a real time problem can be a googly to most brilliant minds. Even I’ve faced a googly in a discussion I’ve had sometime ago. Again, one of my favourite design puzzles is,

We are required to build a tic-tac-toe game for 2 players, X and O, who take turns marking the spaces in a 3×3 grid. The X player usually goes first. The player who succeeds in placing three respective marks in a horizontal, vertical, or diagonal row wins the game.

If you were to design this game (not develop), identify the classes that you would create?

Most of the candidates, here, misinterpret the question. They start describing the interfaces and inheritance they would use; or would start with a Windows application and define UI elements like grid, buttons, etc. Everything is given as an answer, but the names of classes.

Problem statements could be many. Puzzles could be endless. When you are hiring someone, get the man who could sit besides you and challenge your logic and quotient. Not one that keeps appreciating you even if you are wrong! We after all want to come up with variant thoughts and innovation at work!
 

Reference: Developer Interviews – Code first approach from our NCG partner Punit Ganshani at the Punit Ganshani blog blog.