Archive for April, 2009

The gorilla guide to interviewing

Posted in Uncategorized with tags on April 6, 2009 by Bartosz Radaczyński

The title

is of course coming from Joel Spolky’s famous series about hiring people. But there is something to the fact that sooo many companies look for code monkeys instead of really thoughtful people, that I just couldn’t resist.

Sooo, for he past couple of weeks I’ve been to several interviews for a job. To be honest, some of them were good, some were… uh, decent, some were lousy, and some were horrible, horrible interviews. Well, up till now, there is only ONE place that I would say the interview process even remotely resembled what Joel Spolsky was writing about in his guerilla guide to interviewing (guess if that is the place I would choose to work?). This is really sad. Leaving all the headhunters aside (well, I mean after all they should also be at least OK with technology since they are recruiting people for highly technical positions…), but the technical people not asking technical questions?!?! Come on, be serious. Would you hire someone to build you a house without knowing that he is capable of reading a blueprint? Didn’t think so. But, sadly this is what it looks like in the software world around here. Only a couple of places got me to write a piece of code and even fewer took the time to actually look into more detail of the code and discuss it. It is not THAT hard to venture three or four decent quality questions for the interviewee.

Random choice of crap

Idiotic questions encountered so far:

  1. what is JNI
  2. puzzle – silly one (I’m not talking that kinda thing here)
  3. SQL questions with ill-defined tables
  4. typical HR questions: what is your biggest strength and weakness/what would you like us to remember from this interview – all that kinda crap

Excellent questions encountered so far:

  1. algorithmic puzzle
  2. a page of code with some bug to find and correct
  3. SQL questions with well-defined tables
  4. how many queries have you written so far?
  5. does Java allow operator oveloading? are there destructors in java?
  6. what to avoid when using RDBMS? are there any good practices, what did you use?
  7. does python pass parameters by value or by reference? how to make a copy of a list in python?

Process as I see it should be…

I don’t think that Joel is entirely correct in that article. Basically what he says is that you sit the man down in a room with the interviewer and ask him all these questions one by one from easiest to the hardest in order to have a nice conversation (easy question, pointer/recursion…). I believe that you get even better results when you give a candidate a list of few questions and some time to get through them (short introduction is appreciated, like: don’t worry about the memory allocation and freeing, write pseudocode or whatever language you are comfortable with etc.). At least that’s what I would prefer as a candidate. The interviewer in the same room looking at me all the time makes me a little bit nervous, but that’s just me. But I guess that being on the other side of the table makes you see these things a little bit differently. Now, as to the questions that ought to be asked:

  • easy ones: fizzbuzz, swap two variables (tell the candidate that it is NOT a trick question)
  • intermediate: binary search, bubble sort
  • upper intermediate: heapsort, quicksort, fibonacci, linked list, something specific to your area of expertise (if algorithms and stuff like this pay even a remote role in your everyday programming life)

Some nice additional questions that you may wonder towards from any of these:

  • is there a bug in there?
  • performance (would you use recursion for 1 million elements? why/why not? can quicksort be written iteratively?)

What to avoid:

  • having the candidate interviewed by more than one person at a time (I’ve been to an interview, where this was a technique that they used <and intermixing “soft” questions with technical ones> that was really a pain. I felt turned inside-out after I left that place). And in the end did not get the job anyway – maybe I was too lame for them, but still, making the candidate feel like dirt is probably not what you want. Now I would tell anyone around that this is not the place to be working for. On the other hand there was a place, where after the interview process I felt like telling the guys that interviewed me that it was the best one I’ve been to, ever (regardless of whether I got the job or not). It was just a pleasant experience, nice conversation…
  • leaving candidate without feedback – either way he/she WANTS to know how he did on the interview. If there was someone better, let them know. If he has to work on something – let them know. If they wanted to much money – let them know for crying out loud! How are they supposed to figure this out? And if you do not give feedback at all – they  might tell everyone they know that your company sucks!
  • by all means avoid hiring developers solely on the basis of what they say! make them prove it to you!

As to the headhunters, I have no idea how it looks at where you are, but I can tell you fir sure that most of these guys have absolutely no idea about what this T-SQL is and what is the difference between Java and C# (and that someone knowing one will as likely be a good candidate for a job in the other). Most of the “HR agencies” hire a bunch of students that do a term-by-term matching of all the LinkedIn profiles to the offers. If they find a match, they send out an email. If they do not find an exact match – they move on. If you get an email, you have a nice talk with someone who graduated from psychology or sociology departament and has little to no knowledge of CS and all that is related. I had to explain to one of these recrutires that the SQL dialects are not that different between one another and that a SELECT query is basically the same across RDBM engines. I’d call that pathetic, but what is really pathetic is that someone is willing to pay these people a lot of money for their “services” (and it is a lot, believe me). And that person is going to decide whether or not you fit the job description. How on earth do they expect to find even decent programmers if they let the nontechnical people decide?!?! This may (or may not) work for sales people or whatever, but not for engineers! You have to test their aptitude (not their current skillset – I believe that a good programmer will learn a new language within a week, OK if it’s LISP then it may take two weeks).

On the other hand there are HR agencies that know their shit. But these are the ones that hire some technical people to screen applicants. I’ve had a nice phone call with a technical person from a HR agency a while ago and he really knew what he was talking about. He even knew how to ask about python! Cool!

After all, you also get the trail period in the job contract, so you can change your mind within three months, two weeks notice, no strings attached. But still, three months with some ill-equipped person is most likely a pain in the neck at the very least.