Does specific technology knowledge matter when recruiting?
Even though working directly for Werner Vogels may not be for everyone, Dan reflects on the current state in software business:
So often I see companies create job specs for engineers where the key requirement is to hire someone who can hit the deck coding like mad using whatever tools have been selected. To that end they load the specs up with endless tech hubris and at interview ask the details of this or that bit of syntax or API call. But what about the next project within the company where the tech is different? All those engineers that just got hired are now useless, they don't have the skills and we lose time whilst they learn. Or we could fire them and hire another lot?
But how did we end up here?
Years ago, the CS courses at the universities focused on the deeper, underlying principles of computer science, but that tradition seems to die away more and more. Many will argue that this is quite a threat to our industry. Joel Spolsky once wrote an article about the perils of Java Schools, where he described his experiences through the MIT-inspired Scheme course at Penn University:
… I watched as many if not most of the students just didn’t make it. The material was too hard. I wrote a long sob email to the professor saying It Just Wasn’t Fair. Somebody at Penn must have listened to me (or one of the other complainers), because that course is now taught in Java.
I wish they hadn’t listened.
Now when Joel does recruiting, he sees the other side of the coin when he realizes that a lot of developers don't know anything about functional programming, recursion or lambda calculus; concepts that are still quite useful for solving real world problems.
Without understanding functional programming, you can’t invent MapReduce, the algorithm that makes Google so massively scalable.
But they even have trouble understanding pointers.
Now, I freely admit that programming with pointers is not needed in 90% of the code written today […] But it’s still important for some of the most exciting programming jobs […]. You can’t understand a line of code in Linux, or, indeed, any operating system, without really understanding pointers.
I can’t understand why the professors on the curriculum committees at CS schools have allowed their programs to be dumbed down to the point where not only can’t they produce working programmers, they can’t even produce CS grad students who might get PhDs and compete for their jobs.
The industry complains that schools doesn’t teach students what the industry needs (read: the current buzz word technologies). The schools react by changing the courses to please the industry, but looses some of the harder parts in the process. The industry then recruits these students, who have not been taught as many different ways of thinking as before, and as Dan writes, the following scenario becomes standard practice:
Of course what happens more often than not is that companies ensure they don't use new tech. Instead they force new projects into using all the same stuff they used before. This is a design disaster as now technology is dictating not design or suitability to requirements. A company that follows the hit the deck coding mantra just has deathmarch and no career progression stamped all over it.
Language/framework experience is least important
Unless you're a staff augmentation company, hiring based on skills is extremely myopic. I thought that was a well-understood idea in most professions.
Only rarely is specific technology experience important
Rob Di Marco
When looking for a candidate, I care about intelligence, curiosity, dedication, personality, and last, and definitely least, relevant experience. Experience with a library can be taught. A smart, curious developer who has never used JBoss before will quickly be more productive in the environment than a mediocre developer who has experience with the tool.
The reason that you get the technology lists is that it is the easiest way to put out help wanted ads and to filter out unqualified candidates. When searching for a job on-line, most candidates enter technology keywords that describe where they want to work. This often includes specific technologies. It would be hard to come up with effective search terms in the supplied ad other than "Amazon.com".
Also, when a resume is sent to a company, it usually is filtered first, either using software or by a member of the HR department. Whenever a help wanted ad is put out, most of the resumes that come in are no where near qualified for the position. Using a list of keywords helps the software or HR person screen out obviously wrong resumes.
There are some exceptions to this rule, usually in pretty senior positions where I need someone who already knows the problems with the technologies we are using.
Re: Only rarely is specific technology experience important
I wrote a whole software hiring manifesto on my blog a few weeks ago.
Also, when a resume is sent to a company, it usually is filtered first, either using software or by a member of the HR department.
Unfortunately , lot of companies do "keyword searches". Not many companies allow you to reach a stage where they can really test your problem solving capabilities.
I love Rob's software hiring manifesto, I think it's extremely good even if there is maybe too much emphasis on writing code "on the fly". I know really good developers who can be very nervous and shy to type code during an interview, so I would prefer to discuss with them an already written piece of code. And what about working under pressure? Do you know any IT environment not putting even too much pressure on people? The problem is that nowadays we are putting too much hopes on modern tools instead of good people and every project suffers because of unrealistic deadlines, even more than a few years ago.
This has been a problem for ten years...
2) people to learn things only trivially (for the interview)
3) penalizes fundamentals (as described above)
4) penalizes people with varied backgrounds (which can provide insights into architecture, debugging, and problems)
NEWSFLASH: look around you, it obviously doesn't matter at all
The server-side, client-side and the browser-side are totally fragmented in terms of technology/language/frameworks.
It's all luck who you get stuck with and when you get stuck with them. If you're looking through a filter or laundry list it is only an effective means to fool yourself and is in fact a waste of time.
Social/team compatibility ranks high
We discussed a similar topic in January at SAW Arosa. The key output was exactly the same. Specific skills can be learnt by a motivated, clear thinker at any point in time. The ability to think abstractly was considered more important than knowing a particular language, tool, technologie, etc.
Given that you have found someone that is a good abstract thinker, social compatibility was second highest qualifier. Sometimes, social compatibility was considered more even important than other factors. In other words, "Would I be able to have a beer/coffee if we just met by accident?".
I have to agree with Joel on this one. In my company and country (South Africa) we are seeing similar trends. I now focus on recruiting Engineering graduates because they seem to do formal courses on design techniques, lateral thinking, problem solving etc. I then take the risky position of teaching, informally, the fundamental abstractions, theories and techniques of computer science that Joel talks about. It seems to work for us, for now.
Re: Social/team compatibility ranks high
A colleague got this question a few weeks ago (in London UK). Is 'I don't know' a satisfactory answer?
Does specific technology knowledge matter when recruiting?
Smart people are rare, but just because you find one doesn't mean they are a shoe-in - being smart without being practical may only get you elaborate designs that can't be realised.
Similarly someone who's gung ho on delivery will probably take so many short cuts, you'll be forever trying to catch up with your design debt.
What the right balance is, is different for each circumstance (and the characters you've already hired), but I find it a useful mantra.
The right level of exposure to the technology-du-jour in your organisation is clearly a benefit, but not always critical (unless, as the article says, you need code going out the door by Friday).
From the hire-ee point of view...
The more a job description resembles this template, the less likely I am to apply... I figure there probably is no relationship between what's posted and what's really wanted, so I really have no idea what the job is. I also presume that, if the person filling the position really cared who they got, they'd put something into the posting to attract a creative, versatile person like me. Vogels' posting, referenced above, gives me an idea of who I'd be working for and with.
Use of only technology or methodology buzzwords in a job description suggests to me that I'll end up dealing with some HR person who doesn't know a RUP from a FitNesse, and who won't appreciate my resume properly, either. I don't waste any time on these. I wonder if these are the people crying "we can't find qualified candidates!!" ?
Isn't phd just another buzzword?
Abstraction is the real key. If you can't abstract, you can't do any real work. I don't think any curriculum can teach this. You either have the knack or you learn it the hard way.
A great many schools have a vested interest in dumbing their curricula down, especillay at the MS level. They can charge through the nose for CS or IS degrees for the same reason that they can charge a mountain for MBAs... most folks in the program are after the degree so they can make more, so there's an investment. The schools use the professional degree programs to pay for their more academic degree programs. Where I did my MS, degrees in CS or business at the master's level cost double per credit that history or art degrees cost. I'm not griping about it... it was an investment. I'm just pointing it out.
In general I agree with the approach for a very senior position though... I'd rather work for the right place than figure out whether I'm using .net, jee, or lamp. I think its like learning spoken languages. After you've done it 3 times, you begin to figure out how to learn new techs quickly.
Recruiters are incredibly poor at their job - skills matter to pass filter
Until IT companies pull their recruitment in house again and stop allowing these vultures to make a quick buck while still providing a terrible service we will continue to see buzzword driven CV's - they are required to get past the "select statement" candidate selection.
There is a lot of value in recruiting for specific skills - if you actually need somebody who has those specific skills - if you need a good technical person then if they know [languageA] or [languageB] makes little real difference.
Re: Recruiters are incredibly poor at their job - skills matter to pass fil
As a manager, you just need an engineer with the Software development foundation(Java/.net/SQL etc) and a conceptual understanding of design patterns. Couple that foundation with an IQ/Personality test you will have your candidate. Otherwise, these resumes+interviews are like court cases in that they help recruiters find the best liars and pretenders.
Uwe Zdun, Rafael Capilla, Huy Tran, Olaf Zimmermann Mar 09, 2014
Olav Maassen, Liz Keogh & Chris Matts Mar 08, 2014