I’ve been sitting on this for about a year and now that it has come up yet again, I just have to comment.
This got started when I got caught up in reading the recent thread on the NYPHP mailing list about interviewing developers and its reference to Joel Spolsky’s, “The Guerrilla Guide to Interviewing” (v. 3.0 10/2006). I discovered that he actually wrote a book on the topic as well (don’t click the link, please).
I don’t know how to say this any other way: All these people got it wrong.
If you read through the threads I’ve linked to, you see that this quickly becomes “me too” party where everyone interjects their criteria/question as to not feel inadequate. So, whats the best answer? There is none, but here are my thoughts on the issue:
Every situation is different. Since every place of employment is different, a standardized test won’t help unless you are doing things in a standardized way. My experience: as much as well all crow about wanting standards, engineers generally don’t – unless it was their standard, of course.
You don’t always want the Alpha. I see the discussion go from a request for a junior developer to questions for veterans. This is not a car, where you are hoping to get a Ferrari for a Chevy price. These people need to fit in and grow with your organization. If you manage to get an “expert” for that junior position, they are just going to leave, so don’t bother. Rather than looking at how much you can spend on this new hire, you should be looking at what you NEED for the company to grow. Hiring a junior person is really for backfill (or if you can’t afford a senior person) so the requirement needs to be different, as well as the questions.
I won’t get long winded, but rather than fun algorithm tests that only prove if the user has seen the latest parlor tricks, you need to assess their experience, skill level, and THEIR goals. All of this fun should be done at the phone screen level, so when they are here in person, you should seriously be considering them. So, do this:
Read their resume, go in and start talking to them. Ask them about their resume and items
As you go through each item, as them in detail about it. If you are experienced as you think you are, you should be able to delve pretty deeply. This also conveys to the candidate that simple BS isn’t going to work with you
Give them a problem to work on and see how they tackle it. This is open-ended, and you should see technical knowledge mixed in with a get-it-done attitude.
The last one is pretty important. You really don’t care if they can solve the carnival game you gave them at the interview, you really care if they can handle whatever may come at them in the future. I think this is the part that people don’t get. Language, platform, etc, don’t really matter at that point. If you are looking for a true expert, you need to look for the traits that one displays:
Technical experience: not syntax, but concepts
STRONG communication skills. This is a deal breaker. They can’t speak and write, they are out. No matter the position.
Roll with it/Get it done mentality. You should be looking for that person to consistently try to solve the problem, coming at it from different angles and won’t stop until it is fixed or they re-assess the problem itself (IMO it takes a real expert to see this).
So, make a pot of coffee and sit and have a chat with the person. You’ll never know what you don’t know without it.
Great points, Tom, especially the “it takes a real expert to see this”. Psychological studies show that when people are asked what option they prefer between two diametrically opposed choices, they choose the option they are most familiar with. *However*, this is only because people lack the training to distinguish which option best solves their problem. The same studies show that experts who know what to look for will not choose on the basis of familiarity but will select the option that solves their problem.
One other comment: Intelligence is not uniformly distributed, both among people and within people. Just because you *know* Skippy is superior to Jiffy peanut butter doesn’t mean you know when to allocate on the stack and when to allocate on the heap.