Random Thoughts On Builders At Work - Part 16.

Filters To Keep Whiners Out.

One of my primary job roles at Multiplitaxion Inc; was to interview every single candidate that would get hired into the organization. This meant that if you were thinking of joining Multiplitaxion Inc and got through the technical rounds; I would eventually end up interviewing you.

Irrespective of whether you were a developer; senior developer; architect; manager; creative-user-interface-programmer; IT professional or a database administrator; chances were that you would go through at-least one round of my interview before you were hired at Multiplitaxion Inc.

Your first couple of rounds would be highly technical with the best people we had in the specific area for which you were interviewing. I was supposed to be more of a last minute check to see that you had the overall right attitude and culture to be joining the organization. Put simply; I was being used pretty much like a filter which was supposed to keep the junk from getting into the organization.

Now; if you were a candidate; you would probably be thinking that after having gone through two or three rounds of technical interviews your chances of getting rejected in my interview; at-least for technical reasons; were a bare minimum.

Newsflash!

During my stay at Multiplitaxion Inc; I think I may have rejected more than ninety-percent of the candidates that came to me after having cleared one or more technical rounds. My reason for rejecting them:

Lack of technical competence.

With no intentions of insulting; or undermining the intelligence of candidates who interviewed with us; here are examples of questions programmers interviwing with me have marvelously failed at answering:

1. Solve the famous Fizz-Buzz questions.
2. Write a program that prints out numbers from hundred-to-one; leave out multiples of five while printing out the numbers.
3. Give me one example of a project where you had to write your own interface and why did you need an interface.
4. How do you assign 2nd of January 2009 to a Date-Time variable Y.
5. And (believe it or not) How do you assign five to an integer variable Y.

I have had DBA's who have failed at answering questions on the lines of:

1. I have an employee table with a joining-date column which is of Date-Time type. Get me the names of the employees who joined in the year 2009.
2. I have an employee table with a joining-date column which is of Date-Time type. Get me the names of the employees who joined in 2nd January 2009.
3. I have an employee table with a joining-date column which is of Date-Time type. Get me the names of the employees sorted alphabetically.

During my stay at Multiplitaxion Inc; I interviewed IT professionals who had no clue as to what a subnet mask is; and managers who looked at you with completely blank eyes when you uttered the word 'sprint'. I've seen candidates fail at every single litmus-test-question that is out there.

Most of these are individuals; were employed in really-big body shops. To be fair to them; quite a few of them also had years of experience and top-notch-educational qualifications behind them.

At some point the folks in the recruiting department and I myself had concerns around these shocking rates at which I was rejecting candidates.

Were our builders failing that desperately at taking their first couple of technical rounds?

Was I being overly critical of the candidates?

Where were we going wrong; was it at the first couple of technical rounds; or was it at my round; we sat there and wondered for days.

Three Things Your Filters Should Know.

The mystery literally cleared itself out when we decided that we were going to let me sit through the first couple of technical rounds and then if needed let those engineers conducting the first couple of rounds sit through my round as I interviewed the same candidate.

Jack; who was one of our best builders around; started his interview of a candidate; who for the purposes of this post; we shall refer to as Fred; with questions and discussions around difference between abstract classes and interfaces. The answer was flawlessly correct. Then as he meandered from one question to another; the answers came in all right.

Somewhere during the course of the interview a sinister thought crossed my mind. Like all my interviews; I handed Fred my laptop and asked him to show me a real life abstract class implementation or example. What I saw in return was two angry young eyes staring at me in utter disbelief. The guy literally took minutes to figure believe that he had been given a laptop and had been asked to write some code.

From that point on; things went down-hill.

The interview ended with Fred taking over thirty minutes to write a reverse loop that would print hundred to one; skipping all multiples of five in between.

We dear reader; had hit a home run; with a simple realization.

The fundamental issue with Jack's opening question - difference between an abstract class and an interface - and his overall interviewing style - was that it worked under the assumption that anyone who was capable of answering harder questions on object orientation knew what for-loops were; had worked with for-loops and had done some basic programming in his life.

Sadly enough; as far as the state our software development goes that is a slightly unrealistic assumption to make.

We; the collective we that represents the software development world out there; have spent years raising army of whiners who know exactly what to read; how to clear interviews and how to say things that impress folks high up in the pecking order. Put them on the spot with an IDE and a laptop.

Watch them fumble with icons on the toolbar; clueless about short-cuts on the IDE. Watch them fail as they attempt to write the simplest of programs out there; and take hours doing that.

There were three things that interviewing experience at Multiplitaxion Inc; taught me:

1. Just because someone has a great resume and an impressive background; does not mean that the person is not a complete whiner. 
2. Make no assumptions about what the person knows. For all you know; he might know nothing. 
3. If you want to hire a singer; get him on a stage and ask him to sing. If you want to hire a programmer get him a laptop and ask him to write some code.

Months later as I scribbled the fizz-buzz question in front of a senior programmer; and asked him to quickly solve it so that we can move on to the harder questions; he quite literally retaliated with the objection: 'If I can solve this will it tell you that I am capable of doing my job?' --- The answer to this question as it turns out was rather simple and spontaneous: 'No; but your not being able to solve it will tell me you are incapable of doing your job'.

The next time you conduct interview for your organization; unless your organization is looking for whiners; try to keep one dedicated person in your organization who acts as a filter. When picking a filter; go get someone who makes no assumption and is not afraid or does not get intimidated when looking into the eye of a senior technical architect with nine years of experience and asking him to crack a for-loop.

I wish you good luck.

@BuildersAtWorkBookNotice