Though this article is focused on hiring developers, it applies to any technical hire, anyone who needs to be able to grasp a complex topic and become useful in that area relatively quickly.
One of my favorite pieces of advice:
Much more important than what they know is how they learn it, and how quickly. You are looking for somebody with a track record of learning new skills and applying them successfully. Talk about their career path, and look for evidence of increasing responsibility (which is related to, but not the same as, seniority). Remember that anybody you hire will expect raises every year: somebody who isn’t getting better all the time is going to become [a] worse and worse value unless their skills increase in value, too.
Terrific foundational stuff.
Some good stuff, but point 1 and point 2 are completely wrong, because they assume that the person you’re interviewing knows how to write code. If your goal is to avoid hiring a person who doesn’t know how to write code, asking the interviewee to write code is a good test. Not to decide whether to hire the person, but simply to decide whether to continue the interview. Perhaps a person who won’t get over this hurdle shouldn’t have reached an interview to begin with, but I’ve seen candidates who invest a lot of energy into appearing much better than they really are, and then fail that simple test.
Number 3 is also bad advice, at least in some situations. Are you hiring a generic programmer for generic tasks? Fine, she doesn’t need a degree. Are you hiring somebody for a hard task that requires in-depth knowledge of a very difficult topic? Then hire somebody who has a PhD in that field. It’s crazy to tell people never to care about degrees for programmers; it’s like saying that medical companies should not hire chemists if they can hire people who have brewed beer in their garage. Sometimes that might be enough, but if you’re doing real engineering, and solving actual hard problems, it’s probably not enough.
4 and 5 are probably good advice, but the article misses one important point: hire people who can write, particularly for development positions. Writing code is only half the job. Documenting it, and explaining it, and making sure that people know how to use it, is the other half, and that requires written communication. A lot of it. Don’t hire people who don’t know how to communicate using text.
no, they aren’t completely wrong — and the notion that you feel these subjective hiring strategies could even possibly be “completely wrong” gives me a good idea of your own shortcomings as an org/leader.
having been hired and done hiring, more often than not i feel coding tests are a waste of everyone’s time. ask to see their app portfolio (including some source code), sure, but dont expect to get somebody’s best effort while “white boarding” code or sitting at a blank IDE next to you. we all use rich libraries, boilerplates, and cheatsheets. most of the creatives i know no more excel at timed coding tests than would a graphic designer…(“Make me a logo….Go!”). no. thats just silly.
rather, to make a good hire, you need to be able to understand people. if you can’t tell whether you’d like to work this person, after 10 minutes of talking with he or she, then you probably shouldn’t be in a hiring position.
and i live by this — i remember the shock on the faces of a small interviewer team when i declined their code-me-a-solution challenge…i smiled, explained i didn’t think this was a productive use of our time because i didn’t feel we would work well together, and thanked them for their time. the lead was stunned into silence. no regrets — the project i ended up on instead was a far better match. (granted there were other flags, but the whiteboard coding was the final one)
The first paragraph of the piece is itself a great point that deserves its own article, and covers many more job categories than this one, including design and development. It explains why bozos hire more bozos.
You won’t know how to hire a good candidate for the position because you are one of the company’s “internal clients” who shouldn’t have been part of the screening committee in the first place. You have no genuine expertise with which to assess a candidate’s qualifications; all you have are buzzwords and a raging ego that requires deference.
You’ll ask questions like “How would you guarantee that the [big redesign project] makes all us division-head stakeholders happy?” At which point a smart candidate realizes that the job will consist of promising a pony to every VP while largely sidelining the end-users.
An unscrupulous candidate will respond with the reassuring, content-free, politic answers you want to hear. An honest candidate will tell you that you’re asking the wrong question, that no major redesign ever makes everyone happy, and that what’s important is the end-users get better a service or product.
actually, no 1 & 2 aren’t completely wrong. 1 & 2 aren’t going to tell you if the person’s a good programmer, they’re going to tell you if the person can take tests well. That’s regurgitation test, not a test of thinking or approach. That’s not to say you can’t see how someone thinks, but crap like the fizzbuzz test, or the infamous google idiocy isn’t going to do it.
For example, early in my career, when my boss would interview for other tech positions would often have a “broken” computer on one of the benches, and ask the person to go about troubleshooting. If the first thing they did was start throwing out “it’s a …” solutions, that was a bad sign. The people we hired the most didn’t do that, but rather interviewed us about the symptoms, and then went about troubleshooting in a methodical manner. We didn’t care if they fixed it. The stupid thing was nonfunctional due to a lightning strike anyway.
We didn’t want them to dancing bear for us. We wanted to see how they approached a problem. If they were logical and methodical, then the particulars were minor. If all they had was a mental script, then they’d be screwed the first time they had to go off script.
You can find out how someone approaches things and thinks without stupid artificial “TESTS OF KNOWLEDGE”.
Same thing for the degree. The degree is a somewhat consistent measure of knowledge, not a sign of how good a programmer someone is. even the much-vaunted Ph.D isn’t going to mean they’re a good programmer for your requirements. That doesn’t, just in case someone tries to turn this inside out, mean that you ignore degrees. But the degree requirement for programming/IT gigs keeps out more good people than bad.
The writing thing is a good point, but if that’s their greatest, or only weakness, there are ways around that.
Don Melton covered some great points on Debug (can’t find the episode number right now – 11?
He ordered by priority –
Trustworthy*> Passionate > Teachable > Smart > Knowledgable
All useful skills in that order, with Trustworthy being trustworthy to do what they’ve said they’ll do for example.
If the test is “write code”, then “doing the test well” is the same as “being able to write code”. Given that a lot of candidates are unable to write code, this test is relevant.
Your response, on the other hand, gives me a good understanding of your shortcomings as somebody who is able to read. I do not expect to get somebody’s best effort. I expect to find out if they know how to write code. I also don’t use this to decide whether to hire somebody. I use this to decide whether to continue the interview.
Both of these things, you’d know, if you had read what I wrote, rather than reading the first few words and then writing an angry response.
If you’re seriously not checking whether potential hires for programming actually know how to write code, but only check whether you like them, you’re part of the problem.