Hiring right

I saw this the other day:
http://www.inc.com/ss/7-unconventional-ways-hire-best-tech-talent#0
While I like the idea, it was truly impractical for my needs.  Having said that I do feel that I could have been more thorough in my interviewing process.

Lets start at the beginning.  Over the past few years I have been to a few interviews.  I have had some tough questions.  I have done OK in some and not so great in others.  Three companies, two of which I have had multiple interviews, where I have basically been told at the end of it, "we like you but you don't have any experience in Java (or what ever it was at the time that I didn't know)".

I have to say this is particular annoying and a huge waste of both my and their time.  If they were looking for a Java programmer why were they interviewing me.  I didn't have it on my CV.  Ok I have a few interesting things on my CV but at the time Java wasn't one of them.  I said during the interview that I didn't know Java right now but I could learn.  In fairness most people when they are looking for a Java programmer they are looking for someone with 3 to 5 years experience that can hit the ground running.  But again they shouldn't have looked at me.  So the conversation continues.  "Really you can just pick it up, huh.  What evidence can you present us with that would convince me?"  Well for my current (at the time) job I learnt Perl Javascript and SQL and became proficient enough at them to run my own two man projects within a month. "Oh thats interesting, what about a real language?"  Harsh! Though again I get it, no proof that I have an understanding of OOD, but having said that I believe it is possible to learn the basics in a week reading on the internet.  The fact that this guy was so conceited that he thought learning Java was harder than the 3 languages I had to get to grips with prior to this, was a little narrow minded.  Aside from reading about Perl in the week running up to the start of that job everything  else was done offline.  We were on a closed system with no internet in the office.  That meant man pages (perldoc to be specific).  Javascript and SQL had to be learned from reading pre existing code and talking to others in my office.  All done with Emacs, no fancy IDE like Eclipse which does so much for you.  So a little context helps when responding to answers.

So I finally landed a job, this job, I didn't know Java but I had a month to read about it before I started.  I played around a little and the rest I learned as I went along.  Its been two years.  And you know what, I rate myself pretty highly.  How do I know this.  I hired someone.  Someone I expected to blow me out the water in terms of coding.  You know what, she has 9 years of coding experience, c, c++ and Java.  As I understand it 3 years of each.  She doesn't know much about Threads or Swing or Sockets.  She is proficient at what she does know.  But somehow after all her time doing this, I still have a greater breadth of knowledge.

(Additionally I was on track for becoming Rookie of the Year in Java on Experts Exchange but my responsibilities took up too much of my time to actually continue doing all this work for free.  I will post more about EE and Stackoverflow later.)

I am the CTO, I need to know everything (not saying that I do, just that I should have a wide range of skills and knowledge).  I am confident that my employee will be fine, it will start off slow and she will improve, but there is a lesson.  Assuming that someone who has the experience you think is necessary is not necessarily the best indicator of whether they will do well in your company.  I believe that had these companies taken a chance on me then they would have been pleasantly surprised by what I could have achieved.  They weren't willing to take that chance, and why should they they have I am sure they could have found plenty of other coders out there.

This is the lesson of hiring, you never know what you are going to get.  You want some one great, with experience, broad knowledge, in depth understanding and the ability to pick up things they don't already know.  You try to test for this.  But its still hard to know for sure.

Lets step back again, I have had some interviews where I have been asked to solve some problems, or give examples of code.  Generally these have gone badly for me.  Personally this is where I crack.  Its not the pressure I just don't think well like this.  And worst of all I don't end up thinking quickly, which is the worst part, as they not only want to see the correct solution but they want it done quickly.  So I decided that I would not ask these types of questions, firstly I don't know how to interpret the results, and secondly if they know how to do this already then it doesn't show me where they are lacking, and if they don't know how to do it then it doesn't show me other areas where they are positive.

Back to my recent hire.  I have spent too long going over basic Hex and Binary.  This stuff should be second nature to a true CS grad, granted many coders might not be CS grads, but I have a CS grad and I wanted one specifically.  The reason: because they should be able to solve problems like this.  I am beginning to see the logic in some of these harder interviews and the fact that (big headedly) I may have "slipped through the net", anyone that answers the type of problems I was getting from Google, Bloomberg and Brevin Howard deserves to be there or at least get another interview.  It shows a basic level of knowledge/understanding/problemsolving skills.

So for the next interview I will ask the following:
given the a byte array which has the following bits:
sfff ffnn nnnn nnnn nnnn nnnn nnnn nnnn
show me how to extract the one bit sign s, the 5bit denomenator reference f, and the 26 bit numerator n.
the answer would be pseudo code that shows a bit mask for n
a shift and a bit mask for f
and a shift for s.

In fairness to my employee she did solve the big problem that we were having that the byte array we were receiving looked different from the one we were trying to send.  The problem was that we were receiving the byte fields as little endian but reading them as big endian.

So now one gets in the door with out understanding these concepts.  I am going to keep track of these problems for the future.  If any more crop up I will be noting them here and using them for interviewing.  I propose a system by which any one incorrect answer will not be the end of the world.  A scoring system will be used to decide if the candidate has a satisfactorily broad knowledge and with good problem solving skills.

More on this as time goes on.