The dumb interviewer

One day in January started very badly for me. The first email that I read that morning had the title "Dumb Interviewer" and was from a disgruntled developer we had interviewed recently and had decided not to take things to the next level. 

What he was complaining about was that the interviewer was dumb because he had been asked a lot of irrelevant questions and thus his true talent has not been judged at all. A proof of his abilities, he stated, was that he had since been accepted at a good software house which in his words was "a 100 times better than Kaz".

What made the email disturbing was that he was telling the truth. Of course I don't mean that the "100 times.." statement is the truth - that's just a pure lie - Kaz is the best software company in the universe :) And I am not referring to the surface level meaning in the statement "dumb interviewer" either - which sadly is true since I am kinda dumb :( The truth that worries me is the implied meaning that our process of selecting talents is faulty.

This is something we have always accepted. It is impossible to judge someone's abilities in a 20 minute call or a 2 hour interview or maybe even a day long session. Talents in the technology world is multi-dimensional. A developer can be a disaster in algorithms but amazingly good at finding just right code do his job on google. Experience has taught us that rockstar formula that Joel keep referring to could sometimes be a huge liability for a project looking for a temporary fix on a broken codebase for example. And of course sometimes the super lazy google search based coder who somehow gets things done at the right moment makes a complete mess for a whole week on something that the algo genius could have fixed in an hour. It's all about context and everything is relative. I think since we are a custom software dev shop with small teams working on client projects this fact is particularly so - I love Eric Sink's little article about this context above all situation 

So what do we do?

We compromise.

We will always lose some great talent. So we compromise by saying "let's stick to some guiding principles" and just accept that we might be wrong. But before you read any further, if you haven't read Joel's ultra famous piece in this subject you MUST right now: The Guerrilla Guide to Interviewing Although we agree almost with every point Joel makes in his article, there are somethings we feel has missed out and there are some places we feel he is kind of lost.

Anyway, here are some of the principles we have set for ourselves:

1. Start the conversation in technology background and let it flow in any direction it wants to go.

This tells us how passionate she is about technology. Only people who are passionate about what they do can continue a conversation that is interesting. If the conversation has good flow, leading to interesting aspects of her past work or goes into strongly held convictions about technology, it is a sure sign of passion and interest.

2. Go with the gut feeling.

Google knows everything. So it is kind of pointless these days to really keep everything in your head. It is only normal that a lot of our questions can't be expected to be answered. But what are guess answers? Guess tells us how someone is trying to solve the problem of not knowing. And gut feeling is the best judge here.

3. Make sure the candidate gets to solve something very simple on the whiteboard.

We obviously don't care about perfect syntax here! But if someone can write code on a whiteboard it shows confidence in his craft. We are just slaves of our IDEs and intellisense - so any sign of independence from these are good signs.

4. Get the person to write code to solve a simple problem that has many possible solutions.

As Joel puts it: "Would you hire a magician without asking them to show you some magic tricks? Of course not." But our only addition to his advice is the "many possible solutions" angle. By looking at what was the solution someone has chosen for a problem we get to feel how this person is likely to approach problems in his professional life.

5.  Ask question that challenges the technology choices she made in stuff she has done.

This we feel is very important. A coder must be sure why she is using a piece of technology and know its pros and cons. If there is sign of blind support then this could be a very bad sign (or it might just be a case of great passion or youth so we have to prod more). The challenge also creates the environment of stress and gives us a chance to see how she reacts to criticism. 

6. Get her to participate in a debate.

If there is one thing that is ubiquitous in our profession it is debate. We debate every day about why this is better than that and why .Net is the evil and Java is the savior (I'm just kidding...). And how a person participates in a debate is extremely important. What we particularly look for is the ability to understand someone else's point and ability accept defeat if defeat is indeed the obvious choice.

But nothing is set in stone. We are always keen to change our rules, to make them better and are always on the lookout for criticism - and so a big thanks to the developer who made my day horrible! 

​N.B. Just in case you are new here: we are a software company in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.