Fog Creek Software
Discussion Board




The guerrilla guide to interviewing

Very good guide to interviews, Joel! http://www.joelonsoftware.com/articles/fog0000000073.html

I have some additional hints to share, based on my learnings in hiring C++-programmers.

#1: Joel has some tasks that he asks the applicant to do; I've successfully used questions posted to Usened News groups and would recomment that to others.The questions people post to news are real-life problems and you would really want to see how your canditate solves real-file problems.

The questions in news are often poor: wrong terminology, bad language, vital information missing (am I using Visual Basic or C++, Windows or UNIX, etc. things that you'd relly need to answer properly). But poor questions are good: at work you always have to make decisions and provide answers based on incomplete information, you never ever have the luxury of being able to sort out everything that is related to the problem in question.

How your canditate answers to poor questions helps you find out the two qualities
* if she or he gets things done: (s)he makes educated guesses and assumptions, _spells them out_ and reasoning behind them, ("...hmm, the compiler and OS is not mentioned here, I'll assume that MS Visual C++ and Windows are used, because..."), and then proceeds with the answer.
* smart: just watching and listening how a person starts to handle a problem tells you a lot on how smart (s)he is. It's also worth to have a question that is impossible to answer. The one I had, contained a long hard-to-follow description of a fault and then a code example that was correct! Written on such awful style that it would never pass any code review, but correct. The actual bug was somewhere else, not in the example. Based on the information in the question, it simply wasn't possible to tell where and what the bug was.

But smart people could cope with that, they looked the question and eventually told me that they couldn't tell where the problem is. Not-so-smart ones started feeding me with suggestions on how the code excample should be changed (sure the code was horrible and there was a lot room for improvement, but it DID work). No-hire.

Then, to save time, I had one question that I always used first, which I called Goodbye-question:
int a;
char array[a];
Compiler error message: expected constant expression. What's wrong?

Two lines of code and a very basic compiler error message. If you can't tell how to fix this, you are not a C++-programmer. Goodbye. (sure I was more polite). It's amazing how people who don't have the faintest idea on coding actually make a living as programmers.

With professionals the question helps to ease : hey, these questions are not bad at all! Well, you just wait..., but trivial first question gives self confidence to the canditate, preventing under-performing under pressure.

#2: Managers hire people. Managers don't know technology. Sure, I too was a SW engineer befofe I became a manager and started hiring people. And I knew how to code. But being a manager means that your techical skills slowly dimish. Therefore, I had this rule: the canditate must be BETTER than ME.

I'd really recommend that to everybody. Some bosses are afraid to have people that are better than they themselves are in their team, cause that would reveal how bad they are (or something). That is sheer stupidity. Manager gets credit if things get done, and the better people you have the better things get done.

#3: While you can argue whether pair-work works in programming, in interviewing it does. I always interviewed with a collegue. Try to find a person that has different character than you, then your judgements really compelement each others. No-Hire + Hire = No-Hire, only Hire + Hire = Hire. You both must agree on Hire, or it's No-Hire.

#4. My final piece of advice: trust your instincs. In an one-hour interview you can't get to know a person, but your subconscious mind works for you. Trust it. If the facts say Hire, but you just have this odd feeling about the person, seemingly without a reason, it should be No-Hire.

We once had a canditate that really was very good. However, my collegue muttered 'somehow he is too eager'. Definitely that is a stupid justification for No-Hire, and I would have gone for Hire. But No-Hire + Hire = No-Hire.

However, he was later hired to another team. Big mistake! The person turned out to be totally unreliable.

Tero Lahtinen
Sunday, November 17, 2002

There is another very good reason for having at least two interviewers on the panel, and that is that the candidate is also interviewing you. If there is only one person doing the interviewing his attitude towards the company will be too influenced by his personal evaluation of one person.

Stephen Jones
Sunday, November 17, 2002

I have also had very good results pair-interviewing w/ another fan of the guerrilla guide.

Another good reason is that different people remember different things about the interview, which can last hours. So when going over how the candidate performed I may be thinking he blew a question and the other interveiwer might point out something the candidate said that I missed. It definitely helps to have that redundancy especially w/ the marathon interviews we give (3-4 hrs just w/ me and my collegue on top of the time spent w/ other managers and engineers who don't follow the guerilla guide).

dmooney
Sunday, November 17, 2002

Joel's hiring guidelines work for his company. 

At many companies programmers must do more than simply sit in a cube and pound out code all day long.  When this is the case, you can't just ask a few problem solving or coding questions.  There are no "silver bullet" solutions to finding the right employee.

Personally, I feel companies put too much stock in the interview process and neglect to use the probationary period properly to evaluate a job candidate.  If the new hire doesn't work after a week or so fire his or her ass.  The cost of hiring and then firing someone during the probation period is normally not that much.  A bunch of paperwork has to filled out but besides that....

one programmer's opinion
Sunday, November 17, 2002

> The cost of hiring and then firing someone during
> the probation period is normally not that much. 

In Belgium, even in probation period, if you fire an employee within less than a month, you owe him his first month.

So fire him after a day, a week or a month and you'll pay for a month.
[After the 1st month, you'll have to pay something like one extra week]

Serge Wautier
Monday, November 18, 2002

At my last company, they did "contract-to-hire", which meant they paid me hourly for a while until we mutually decided I should stay on as an employee.  I liked it because it was natural, and since I was actually underqualified for the job I could just reduce my hours billed while I learned.

Tj
Monday, November 18, 2002

You may find that when it comes to the cost of hiring someone, the wages you pay them in the probabtion period are a pretty small part of it. You have the time spent in conducting interviews, posting job ads, sorting through resumes, giving them orientation talks, adding them to the pension system, getting them a machine.
Plus the fact that if you hire someone and don't like them it will be at least another couple of months before you can get another person to do the job.
And that's all leaving aside the fact that you can't really tell if someone is going to be any good in the first week or two anyway.

The reason that some placement companies can change more than 10% of a person's salary for finding the right person is that it consts most companies
that much to go through the hiring process.

David Clayworth
Monday, November 18, 2002

It is probably not coincidental that "one programmer" gives neither his name nor that of his company. It would probably have to relocate to somewhere off the internet in order to continue getting programmers if it did.

If word gets out that leaving a job to join one programmer's company is playing Russian Roulette with you career the HR department would soon find itself dealing with a combination of college interns and hard-nosed employment lawyers insistiing on bullet-proofing their programmer client's contract before he will dream of sigining on.

I hire people for a completely different field, which is EFL teaching, and I can assure people the one question that is asked time and time again on the forums is "what is the turnover at this place?"

And to fire all but the clealy incompetent has a disastrous effect on the morale of the rest of the workers.

Stephen Jones
Monday, November 18, 2002

Hey Stephen,

What is the EFL work you do? Which country did u say Qator or Oman?

Prakash S
Monday, November 18, 2002

or was it saudi arabia?

Prakash S
Monday, November 18, 2002

"In Belgium, even in probation period, if you fire an employee within less than a month, you owe him his first month."

Generally speaking, European countries do seem to be a lot more "pro employee" than they are here in the United States.

"At my last company, they did "contract-to-hire", which meant ...."

Yup. That approach is becoming very popular nowadays.

"You may find that when it comes to the cost of hiring someone, the wages you pay them in the probabtion period are a pretty small part of it. You have the time spent in conducting interviews, posting job ads, sorting through resumes, giving them orientation talks, adding them to the pension system, getting them a machine."

Agreed.  But some of the costs you mentioned (interviews, jobs ads, sorting through resumes, etc.) occur whether the company hires somone immediately or six months months later.

As for some of the other costs you mentioned: orientation talks, adding them to the pension system, getting them a machine ...  what is the big deal?

Orientation talks?  Yeah right.  Imo, most companies don't have an employee orientation plan whatsoever. 

Many companies don't automatically enter you into their pension system as soon as you are hired.  Many have a "one month after you hired" policy before any type of benefits become effective.

Assuming that company is really looking to hire someone.  Getting a new employee a machine and possibly having someone configure it -- is a cost that the company will have to incur no matter what.

"Plus the fact that if you hire someone and don't like them it will be at least another couple of months before you can get another person to do the job."

In this job market?  Are you sure?  Look I never said you should hire the first person that interviews for the job.

"And that's all leaving aside the fact that you can't really tell if someone is going to be any good in the first week or two anyway."

Well, this is some truth in this statement.  At some of the companies where I have worked at (on a contract basis) it sometimes took a week or two before the company gave me a machine to use.

one programmer's opinion
Tuesday, November 19, 2002

Prakash, I'm in Saudi

Stephen Jones
Tuesday, November 19, 2002

*  Recent Topics

*  Fog Creek Home