The most interesting interview question I ever answered involved some C code that did a bubble sort. They asked me to optimize it. There were some obvious places to improve the code by moving constants outside of loops etc...

I said "replace all this code with a call to qsort()"

They really liked the answer. The job didn't work out for other reasons (too long of a commute) but I think this is a good interview question.

> Kay & Michele, a one-hour interview?

Most likely even less.

> That is very
> impressive. How do you determine if the candidate has the
> technical skills you require? How do you evaluate whether
> the candidate will fit into your team's culture and
> development environment? How do you know that behaviorally
> and personally, the candidate will be able to work well
> with your team? If you are able to do that in an hour,
> and hire well, then you are on to something.

What if all this "hiring a coder like you would hire the CEO" style candidate search doesn't yield any different results on average and university education + CV + a short talk allow for good predictions unless candidates are cheating, something which seems to happen rarely enough for anyone to take expensive and serious counter measures.

> I suspect there is more to this story than
> country-specific culture.

I don't believe there is a mystery which has to be unravelled. German IT managers don't avoid hiring cargo cults because they have any superior insights or a sixths sense. They are just not used to and they don't seem to have strong incentives to change their behaviour. Don't try to repair what is not broken.

My experience is anedoctic, I can only speak about what I have seen happening here in Milan, and I am not in charge of
hiring. Nevertheless, let me explain how it works.

We use Python as our main language, so our strategy has been to leverage on the Python community and the Italian newsgroup. In particular we have been sponsors of the Italian PyCon from the beginning, especially for hiring purposes. Since we know the
community, we know the people. If I am going to hire a guy with a thousand posts on i.c.l.py I already have a pretty good idea of his technical competence and also of his personality and I do not need a long interview. Also, if a prospective candidate is involved in an Open Source project, I do not need to ask him coding question: I can just download his code and have a look at it. For instance, I could hire Kay Schluehr here with a 10 minutes interview, without asking him any technical question, because I already know he is competent, just from his posts/projects.

The strategy has worked well for us whereas using the services of Monster or other agencies has been totally useless (we got tons of CVs from Monster, but totally uninteresting).
All the people we hired turned out to fit extremely well with our team, I suppose because the Open Source community attracts similar-minded people.
We have quite a lot of hacker types here ;-)

Michele, I would say your experience is atypical but not rare. I was once hired with just a 45 minute phone interview. I worked remotely and never even met any of the employees face-to-face.

It was a similar situation to what you describe. I was part of a tight technical community. I had a good reputation, and I had vast experience with the software the company wanted me to work on.

In the U.S., and I suspect in the vast majority of the world, IT companies are usually dipping into large talent pools for their candidates and don't generally have the luxury of knowing the pedigree of their candidates in advance. When you do know the pedigree, you already have the information you need to hire. In the absence of that knowledge, a company is unwise to hire on faith.

Kay, I wonder if all of IT Germany agrees with you? Maybe people are more truthful in Germany, but I find that in the U.S., regardless of where candidates are from, truth-stretching and even deception, are quite common.

I believe it's not country based, it's company based. The greater the company, the longer the interview.

Once, I applied for a position of an assistant of a department manager. The interview took like 4 hours filled with a domain knowledge test, psychological test, test of my analytical skills, plus a language test. I was a high school graduate with one job experience already and I scored better than some uni graduates. Problem was that the job was rather "stupid" - after a such long interview, I was supposed to copy / print some materials, put them together and ship'em. I stayed there 6 months.

My shortest interview was done in 10 minutes while discussing the job with the boss, smoking cigarettes :) I stayed there 2.5 years.

Otherwise, my experience is that an interview takes like 3 hours, but it really depends on the company. I liked one - write a short program in your favorite programming language.

I think hiring OSS people is great, as you can see that they really like what they do.

> Kay & Michele, a one-hour interview? That is very
> impressive. How do you determine if the candidate has the
> technical skills you require? How do you evaluate whether
> the candidate will fit into your team's culture and
> development environment? How do you know that behaviorally
> and personally, the candidate will be able to work well
> with your team?

You can't really determine any of that even with a whole day interview. Or a one-week interview, for that matter. In my experience (and I spent a lot of time interviewing people at my previous job), an interview is only useful to filter out people who don't meet the bar when it comes to technical competence; for that I need less than 15 minutes.

Nice piece, Sean.

I wish I could say that I haven't made most (or all) of those mistakes myself in one interview or another :-(

I think you touched on the root of it at some point, which is that hiring (or at least interviewing) is often shoved into an already-chaotic schedule, instead of being planned for. If it were a "project" like any other that was being prioritized and scheduled and managed, the outcome would be significantly different.

Peace,

Cameron Purdy | Oracle Coherence
http://coherence.oracle.com/

I wonder how smoothly a job interview would go if the prospective employer informed the candidate ahead of the interview that they want to discuss various topics at the interview?

"Please come prepared to discuss topic/technology X, Y, Z..."

Of course, the aforementioned topics would not constitute the entire interview and the topics need not be al technical in nature.

Just a thought...

Lou, interesting question. As an interviewer, I want the interviewee to present herself with maximum fidelity. So I want to provide an environment where she can represent herself as accurately as possible.

I don't want the interview distorted by excessive fear, tension, uncertainty, etc. Likewise, I don't want to tip off the candidate to the point where she can ace the interview because of my influence. So there's a delicate balance.

I think it can be good to let the candidate know what to expect. For example, I think it is reasonable to let the candidate know she will be asked to write some code in a particular language, on a white board. I don't think it is helpful to tell the candidate, "You will be asked to solve this problem so come prepared with an answer."

I would have no problem telling a candidate to come prepared to discuss web services. I would not ask her to be prepared to discuss RESTful web services. For the later, the candidate could simply 'cram' for the test and I wouldn't get as good a read on her overall knowledge. On the former, she can prepare somewhat, but she won't easily be able to fool me about her overall knowledge of the subject.

The job description is a useful tool for helping the candidate be prepared for the interview. If web services experience is listed as a requirement of the job, the candidate should be prepared to discuss that topic. Researching the company is also a useful strategy for being prepared for the interview.

> It must have happened at some point, but I've never heard
> of an instance of a interviewee getting up saying, "sorry,
> but I really do not think this will work" -- and promptly
> leaving.

I have phoned the agent about 15 minutes after a 2nd interview to say I was no longer interested. It happened after an experience not unlike the one described in the original article.

Candidates are entitled to be picky too.

As an interviewee, I think I'd wait until after lunch to walk out. :-)

I'm not sure that will always work neither I think is a good indicator in general.
While opensource contributions can show a candidate coding level (on a project of his/her likes) that's pretty much all: in fact it won't show how the candidate will react to a project he/she dislike to work (commitment, ability to understand the complexity of legacy code support etc.).
It won't show algorithm (the non-CS flavour!) development skills because normally these are bound to NDA and/or people not often like to work on that demanding task for the sake of humanity.
My evidence has been quite the contrary: larger, longer running project have to avoid the "hacker" kind of guy, the lonely coder.
Far from me to assume an opensource contribution as a negative point, I'll take that just as another point in evaluating candidate.
But probably that depends largely on the underlying company culture.

> Far from me to assume an opensource contribution as a
> negative point, I'll take that just as another point in
> evaluating candidate.
> But probably that depends largely on the underlying
> company culture.

Agreed. It is just another data point. In some cases, the open source community is small and familiar, and you already know the person and her work. Then it becomes several data points. Maybe even enough information to do a hire. For most companies, this is a rare situation. Having a more robust interview process is the way to go when you don't know much or anything about the candidate.

I am quite surprised anyone would say a four hour on-site interview is too long. If I am going to offer a six figure salary (US), I want to have some confidence I am making a good choice. I don't have super powers that allow me to evaluate someone in an hour.

(Appropriate quote here: "I used to have super powers, but my therapist took them away.")

> I am quite surprised anyone would say a four hour on-site
> interview is too long. If I am going to offer a six figure
> salary (US), I want to have some confidence I am making a
> good choice. I don't have super powers that allow me to
> evaluate someone in an hour.

Depending on the situation four hour could be very tiresome to anyone and you cannot have guaranty about that you choose the best performance time of the candidate.
Personally my brain is more productive on afternoons, but I am, certainly, more fresh before noon for chatting.

Instead of the longer interviews what if someone gives a task and says: here is the problem, about 4-5 hours of work, give me some solution next day. I think this would be more closer to the reality how people work: task given, left alone in peace, can use resources at like.

I've been in software development since 97, with various firms in California. I had just moved to New York to start a family with my (then) wife, and was applying for a software engineer job. Something I considered a touch regressive considering my experience. About thirty minutes into my interview, my would be hirer asks me about the pay grade and scale of my previous jobs. I responded casually that during my previous employment, I was the team lead responsible for hiring and placing new engineers, and that I found it unprofessional to ask such a question. I certainly never would have done so. Little did I realize that back in California, he had applied to my firm and I had (appropriately) turned him down. He promptly told me as much and ended the interview on the spot. I never mouthed off during an interview again, unless of course, I was conducting it.