The main sources of information used when hiring someone are their CV, the interview, and references.
Table of Contents
CV
The CV is written by the applicant or sometimes for the applicant. Naturally it says only good things, if a CV notes no skill in a particular area then it may be used to exclude an employee from consideration. But the trend is towards including a reference to anything that you touch, so someone who lists DBA experience may merely have done a couple of CREATE TABLE operations.
Interview
The interview is a good test of people skills but is often of little value in assessing technical skills. The interviewer asks questions such as “do you know technology X” and the applicant says “I know that really well“. If the company is hiring another person with similar skills to current employees then they can have their current employees sit in on the interview and ask difficult technical questions, but for unknown reasons managers often don’t take that option and get no advice from their technical people. Also if the company is hiring someone with specialised skills (EG they are about to implement a new application and want to hire their first employee to work on it) then it may be impossible for them to assess the technical merit of answers. Probably the best use of the interview is to match answers with the CV, if the applicant doesn’t appear to know the contents of their own CV then they should be rejected.
The biggest problem with interviews is when the questions are all of the form “do you know X“. Someone who really knows it will say “yes” as will someone who doesn’t know enough to realise the limits of their knowledge – and such ignorant people vastly outnumber the skillful people. The real problem is that the people who are moderately skillful will lose out. If someone asks me about my MySQL skills I will tell them that I’m not really good at it. Sure I’ve run replicated servers with tens of thousands of users running 24*7, but that doesn’t mean I’m really good at it – probably most people who will claim to be great at MySQL without qualification would have less experience than me.
References
Reference checks rely on an unknown person saying good things about the applicant. For starters there is the issue of the number of references which may not be representative of their employment history – EG the applicant could use as a reference the one manager who didn’t sack them.
The next issue is that there is little incentive for the referee to be honest, most people are aware of instances where someone once worked for a friend and can rely on good references for the rest of their career. If a reference is inaccurate then there is no realistic opportunity for redress.
Finally every reference check that I am aware of (checks where I have been the referee or the applicant) has involved the applicant giving the phone number of the referee to the hiring manager! The phone could be owned by a friend or relative of the applicant, so logically a good reference that is based on trusting the applicant to supply the phone number only proves that the applicant is either good or really bad. To make a reference check prove something the recruiter would at a minimum have to phone the number listed in the white-pages for the corporation that used to employ the applicant, asks to speak to the manager of the relevant department, and then gets a reference. Calling a mobile phone number that is supplied by the applicant (which seems to be the standard practice) is essentially trusting the applicant – and trust is the root cause of most security problems!
Really most of this ends up as trusting the applicant to provide honest evidence that they are trustworthy and believing that the applicant’s technical knowledge is good enough to be correct when they say that their technical knowledge is good. It can fail spectacularly when someone isn’t trustworthy enough to provide honest evidence of their integrity or when someone doesn’t have the skills needed to know that their skills are lacking.
As an aside, even if the reference is given accurately and in good faith it may still be misinterpreted. The fact that telephone references are exclusively relied on exacerbates this problem. Ideally references would be in writing with some way of proving their authenticity (maybe using phone verification of the accuracy of the written document).
Solutions
So how can we solve this? Some people believe that career based social networking software will solve the problems, but as usual I think that software doesn’t magically solve human problems. The first challenge when trying to use social networking to solve the problem is to find someone on your friends list who has relevant knowledge, this may be viable in a small industry (EG when someone from bank A applies for work as bank B in the same city). The next issue is that of false “friends“. I’m sure that I’m not the only person who has been pressured to add people as friends on social networking sites, the non-computer social interactions really don’t prepare people for saying “no you are not my friend” (apart from high-school I guess). With professional social networking sites there are further issues, if you are working on a client site and a manager demands that they be listed as one of your friends then what are you going to do?
So it seems to me that the social networking sites are at best a helper for the gossip network. If you think that a friend of a friend from a social networking site might be able to help you then you first ask your friend if the person in question is really a friend, and if so are they one of the shifty pseudo-friends you only hang out with because their company pays good money. But the problem with the gossip network is that it’s mostly secret and is therefore subject to settling vendettas, I’ve heard of senior managers going out of their way to spread false stories about former employees to settle scores.
The best solution I can think of is for someone who has a reputation to publicly stake it on the accuracy of their references. If I’m going to give a reference then I would be happy to do so via a GPG signed email or a blog post. This doesn’t mean that my references will always be correct, but it would show that I try to give good references.
This is the correct definition for the term false friends:
http://en.wikipedia.org/wiki/False_friends
steve: What term do you think I should use for people who appear on your social networking page as “friends” but that you actually don’t like?
I’d use the term “acquaintance”.
I think you’ve identified the main problems with the hiring/interview process. I’m not sure what the answers are, but I’ve always found it odd that no one does hiring with a temporary employment contract, say six months. At the end of six months, if both the employee and employer want to continue the relationship, then they can sign a more permanent employment contract.
btmorex: I was under the impression that almost every employment contract had a 3 month trial period. That is my observation from working in England, the Netherlands, and Australia. Where do you mostly work?
Regarding references, it seems somewhat more secure for the prospective employee to provide an email address at the company in question. Anyone can answer the phone as “So-and-so, FooCorp”, but having an email address @foocorp.com typically requires actual employment at FooCorp.
Anon: Sure, so you register FooCorporation.com.au or FooAustralia.com or something.
The Nigerians have worked out how to solve those problems. ;)
Another possibility is to have a friend working at FooCorp who can impersonate a manager.
I think the key is to let the right collegue participate in the interview. If you’re hiring an admin, get one of your admins into the meeting. Tell him to think about required skills and to prepare a few questions or problems to assess if the candidate knows really as much as he claims.
Apart from knowledge/experience, one of the biggest issues in technology is how people approach problems. I’m amazed again and again at how random people tacke problems. There is often no consideration whatsoever of how to most efficiently explore the “solution space”. (english corrections welcome.. :-))
CV: worth (almost) the paper it’s written on.
References: worth very little. In the UK at least, a reference is not a privileged document and thus a referee can be sued for defamation of character if anything bad is said. I agree with your suggestion to telephone via the white pages.
Interview: you need to use someone who understands the job role to carry out at least part of the interview, and to dig to the “I don’t know” point. Even apparently simple concepts (for example, in the IT world, “How does DHCP work?” or “How is a subnet mask used?”) can reach an “I don’t know” point for all but the most knowledgeable candidates.
But the bit you missed was the technical test. Set aside 2-4 hours for the candidate to work on things that they will have to work on if they get the job. For our technical candidates, we set them a number of tasks in a test environment, and ask them to keep notes on how they get on. That is the best indicator of whether they will be able to do the job or not, and the interview is the best indicator of whether they will fit in to the existing community.
Sure I’ve run replicated servers with tens of thousands of users running 24*7, but that doesn’t mean I’m really good at it – probably most people who will claim to be great at MySQL without qualification would have less experience than me.
Here’s an idea off the top of my head: instead of a yes/no response, ask the candidate what would merit a rating of 10 on a 1-10 scale of “knows mysql”. Since we’re assuming no inhouse mysql expertise is available on the interview, bring in a checklist of features mysql advertises and find out how many your candidate mentions for the 10 qualification.
I think this will help you weed out novices who from experts-to-be.
Something about this post really bothered me.
I feel you’ve constructed a straw man argument. Granted, resumes are really
only good for extremely coarse-grained screening. But your depiction of the
interview process is absolutely the lowest-common-denomiator. If you’re
conducting a technical interview, there’s tons of interesting questions you can
ask. You can try to solicit their opinions on archetectural strategies, for
instance. You can ask questions that directly relate to problems you’ve
recently solved to get their perspective. The list goes on and on. Clearly,
just asking “are you an expert?” is a /horrible/ way to interview someone.
Let me give you an example of how I was interviewed for my latest job. It’s a
Java shop that advocates TDD, so I paired with my now-manager on the bowling
game kata (which I hadn’t done before), and we ping-ponged between writing
tests and writing implementations. It was a pedagogical excersize, but it
really seemed to accomplish some very nice things. Later, I found out that my
manager had been influenced by an “Extreme Interviewing” whitepaper; I don’t
have a link for it, but Google probably has it indexed.
Finally, you comment about social networking as though it begins and ends with
LinkedIn or similar sites. Social network is just a tool to complement a much
more important activity — actually being social.
Most people have heard some kind of non-statistical “80% of jobs are found by
networking” claim. When I first heard it, I thought it was a sad commentary on
cronyism in capitalism. But now I feel completely differently. I didn’t meet
my manager through some cold process like a Dice or Monster. Instead, the job
was posted to interest groups (Java, Agile, etc.). I attended these kinds of
groups and met these people before the job was even open. This was the
“interview before the interview.” And honestly, I think that’s fine. Good
people tend to self-aggregate in physical and on-line communities (interest
groups, conferences, mailing lists, IRC channels). If a company isn’t dialed
into these self-aggregating communities, they’re just twisting in the wind, and
probably have deeper systemic problems.
Sukant: This post is based on my own experience. A significant part of my work over the last 15 years has been on short-term contracts, so I’ve had a lot of experience at attending job interviews. I’ve worked in Australia, the UK, and the Netherlands so I’ve seen how things are done in various countries.
Most hiring managers do their job poorly, the lowest common denominator is pretty close to the median.
Few managers directly ask “are you an expert” but that’s what their questions amount to. I note that your comment doesn’t address the issue of hiring a new person to work on a new technology, if you want to install your company’s first Oracle server and hire your first Oracle DBA to do it then how do you assess their skill?
You seem to agree with my point that social networking sites are at best a helper to the gossip network.
As for 80% of jobs found by networking, I know a lot of skilled people and can easily find people with relevant skills. However the vast majority of companies that I have worked for have never sent me the position descriptions for new hires. On most occasions the first that I knew about a potential future colleague was seeing them come in for an interview – and I was not invited to ask them any questions.
The classic was the manager who proudly told me “I hired the guy who wrote Perl”, I said “really, you hired Larry Wall?”. No, he’d hired a monkey who had so little computer knowledge that he didn’t even know what binary was (seriously). One thing that is certain is that if you get technical people in the interview you won’t hire someone who has written some Perl code once upon a time while thinking that you hired the guy who wrote Perl.
Okay, I think we’re pretty well aligned, and I don’t mean to come off as abrasive.
Definitely, software is managed poorly in many different places. One thing I would say to any interviewee, is. . . you’re interviewing the interviewer as much as the interviewer is interviewing you. It’s definitely an option to steer away from employers that seem clueless.
But that gets to the interesting point you made about a company hiring someone for brand new technical competencies. My response is that it’s a harder task, but not impossible. Let’s take your Oracle scenario. Just hiring someone to install a new server for the sake of doing it is unlikely (YAGNI). So there’s got to be some context that motivates the need for a new technology. Those are the issues that should be discussed. Drop the engineer in the context of the problem, and see how he or she swims. If you aren’t following the proposed solutions, probe for explanations. Not only will you identify mentorship traits (which are invaluable), but you also might get them to stumble on their own incompetencies.
As for your Perl story. . . I’m just sorry you had to go through that. I had one job like the one you just described, and that was enough. I don’t have 15 years of experience, but I’m in contact with people that do. And from what I can tell, networking was their gateway to finding a job that suited their needs.
There’s a ton of factors, though. For instance, maybe I just lucked out by being in a great town with better networking opportunities. And who knows, what I have now might be gone tomorrow, and maybe I’ll be my previous cynical self.
Sorry, there’s one more thing. I really see “the gossip network” as being /very/ separate from quality networking. If I sit down and have coffee with someone, and they talk about something really interesting or pull out a laptop to show me something cool. That’s not gossip. That’s just meeting people and networking. The nice part is that we’re in a business where business and pleasures mix pretty liberally. That guy that does Linux development for work probably has a slew of Linux stuff he does for fun too.
However, I quality networking might be seeded by the gossip network. A likely scenario is that I go to an interest group, and I figure out who someone is, but I haven’t introduced myself. Then later on, I realize we share a lot of contacts on LinkedIn. So that’s a good starter for conversation.
This is not to say that I meet up with people like that terribly regularly, but it’s not something I feel is difficult or inappropriate.
Sukant: Good point about interviewing the interviewer, but it depends on what you are looking for. If you are looking for a comfortable environment to work for a long time then such things are a good idea. If however you are looking for a short-term contract then you just look for the best money, and that often means you end up working for and with idiots.
The computer industry tends to have short employee retention periods, so the benefits in sacrificing salary for working environment are greatly reduced.
Meeting people socially to discuss technical issues isn’t gossip. When you discuss the work history of people you might hire it becomes gossip.
If someone gives you a review of a potential employee and they aren’t prepared to publicly put their name to it then it’s gossip.
A few responses.
1. There’s the idea of learning. Working with idiots untangling spaghetti code is a fast way to demotivate a person. I intellectually languish in those kinds of environments.
2. If you find a place that’s intellectually stimulating, where people understand how to deliver high-quality code, there’s a higher probability there won’t be a retention problem or as bad of a pay problem (if any).
3. One good job, coupled with networking, can bootstrap discovery of the next good job. Even if your customers are idiots, you can at least continue to work with people you trust.
4. I completely agree about all your points about gossiping. But gossip doesn’t have to be chaotic noise. I think it can be sifted through to get at more substantiated findings. It’s pretty much the same work as networking, only more directed. I think the problem with gossip is that people don’t do due-diligence to find out the facts. But that doesn’t mean we need to make the same mistake.
Interesting discussion, but this is clearly the most primitive mailing list I’ve ever used.
I have to subscribe to threads individually, reply via web form and there’s no threading..
steffen: The :-# code was invented for a reason…