"A seasoned C developer with 10 years experience can not instantly morph into an advanced front end web application developer"
True, but they'll be a damn sight quicker at picking it up than anyone else. And they'll write far better code when they're there.
If you're looking for a permanent employee, all development experience is relevant -- there is a huge amount of overlap and retraining just for a different language is no biggie. They'll also have solved (i'd bet) far harder problems than "HOW DO I GET THIS UI WIDGET TO UPDATE WHEN THIS HAPPENS".
If you're looking for someone to hit the ground running from day 1, or work as a contractor, it's different. But you generalise too far here.
"However, they have failed to mention anything else to back it up. I would expect to see some of the following throughout their CV; Design Patterns (MVC, Factories, Singletons, ActiveRecord), Classes, Objects, UML…"
In my CV (highly rated by everyone i've given it to) you won't find a single one of these. Instead, you'll find real descriptions of what i've accomplished, who I worked with (mentoring etc), my methodology (agile, test driven development) and so on.
Hiring the right people has always been, and will continue to be, a hard job. The only way to do it is to use common sense and actually read the CV's you're being sent, then talk to the people you think could do the job to see if they can.
Thank you. The entire article made me cringe for the exact reasons you specified. I would probably immediately junk a resume if I saw a list of design pattern names on it.
Ya, I'm not sure if the OP was a troll HN post or what the goal was but the bit about keywords to me made me immediately shake my head. The only people who want keyword stuffed resumes are recruiters.
Also, the poor capitalization/grammar in places. e.g. (which i will cover shortly)
Correct, and we also spell things with an s where you use a z and others such as we spell "color" as "colour". The problem is, if I were to correct it for the UK, the US complain, if I correct it for the US, the UK complain. Since I am from the UK I will definitely make US related mistakes because I have not learnt your English.
Still, a seasoned C developer of 10 years will not be as good as someone with 10 years in front end development experience. And vice-versa. That's the OP's point. You can substitute any technologies there and this will be true, all else being equal. It's not just about learning another language but also learning tools, libraries, systems, etc. and having the experience in a specific domain. What the OP describes is how just about every single company works. Is it ridiculous? Partly yes, partly not, but ridiculing it won't make it go away. The tech can be picked up, though even that takes time. There's no substitute for experience.
"True, but they'll be a damn sight quicker at picking it up than anyone else. And they'll write far better code when they're there."
Tried that with a few developers. Because it was such a change in thinking for them, the same standards didn't apply to javascript as it does for C, they would approach things the way C does instead of the way recommended by javascript etc. They were constantly fighting against their habits which they have had for 10 years. Soon as you add less, bootstrap, require, and so forth. Their learning curve starts becoming much higher and with the hindrance of their old habits. They end up worse and others have to refactor their code! This isn't opinion, it's happened a few times already at work.
"In my CV (highly rated by everyone i've given it to) you won't find a single one of these. Instead, you'll find real descriptions of what i've accomplished, who I worked with (mentoring etc), my methodology (agile, test driven development) and so on."
If you have a CV with the reputation like Jon Skeet, Rasmus Lerdorf or Douglas Crockford. Fair enough. But most people don't :)
"And UML... holy shit, yeah, no."
It's the best way to communicate how code design will be put together when talking to other devs. Instantly things like inheritance being used instead of aggregation, or composition being used when aggregation should be, or methods in the wrong classes. Even our IDE will produce UML which instantly lets devs see when they have placed something in the wrong place, set a method to public instead of private, and so forth.
If you can read the basics of UML it helps tremendously.
"The only way to do it is to use common sense and actually read the CV's you're being sent, then talk to the people you think could do the job to see if they can."
Interviewing someone is expensive. I have my usual job to do as a programmer, interviewing takes me out of action for hours. I have to work out who has the higher chance of being worthwhile interviewing. Which is why I wrote that blog post. Explaining what things I personally, and i'm sure other employers will look for especially when comparing to another developers CV.
Your blog should have been called "If you hire average programmers, try to get ones with related experience". Or perhaps "Beware: average programmers have a hard time quickly learning new paradigms".
Haha, you're probably right. If i change it now, the link will break and people who have already read it will likely be really annoyed if they stumbled on it with a different name lol
We haven't seriously looked at a resume in 2 years.
Phone screeners --- who barely count for anything in our process, but don't get me started on that --- might skim a resume just so they have something to start talking about.
Otherwise, our hiring process is resume-blind.
We bring people in directly out of school, from random line-of-business programming jobs all around the country, and from networking jobs for people who want to transfer into something more developer-y.
I should mention: our work is not easy. I can hold my own in an argument that says we're significantly more technical and significantly more sophisticated than the median Silicon Valley startup.
Resumes are worthless. Do not bother. If you're screening with resumes, you're doing something wrong.
A bit black and white there. I generally agree that resumes should not be a top indicator, but they can be useful to screen out some people.
For example, I once posted a job that included the word "Ruby". I thought the job posting made it clear that Ruby was a very, very small part of the job. But I still got several resumes from people who were Ruby experts or at least claimed to be, and that is all the experience they had given their resumes. They had little or no non-Ruby experience. At the time, I needed someone who could write Ruby code but had much more experience elsewhere.
So the resumes helped me screen out those candidates. And I also learned that my job posting was worded incorrectly.
And you talked to none of them? You just assumed that their resume told you everything you needed to know about their capabilities? And if it didn't, too bad for them for writing a shitty resume?
In this particular case, I received ~20 resumes for 1 job and 80% were not Ruby-only resumes. So yes the Ruby-only screened them out. However I would have gone back and contacted them if none of the other 80% of candidates worked out.
You will get better results if you build a process that doesn't screen people out because of their resumes. That doesn't mean you don't screen candidates, and it doesn't mean that you don't have a funnel that knocks out a big chunk of them before you get on the phone.
It just means: don't select people for their getting-a-new-job skills. Those skills aren't relevant to software development work.
You can read about tptacek's company's process here: http://matasano.com/careers/. It really does seem like a good way to learn whether a candidate will be able to perform the job.
I wonder that a lot too. I have friends who have tried it for sales and are liking it, but it's too early to tell. (It's not my process, by the way; here's a link 'tokenadult found about it: http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...)
So every single applicant that sends something in will have a discussion with someone one your team? And you find that time is a worthwhile investment?
We hire at a faster tempo than a typical startup but slower than any big tech company, and the investment we put into recruiting has paid obvious dividends. We're looking for more ways to pour time into it, not less.
"Any experience, languages or technology that does not apply to what we need in the team. Let us say we are looking for “A junior front end web application developer”. A seasoned C developer with 10 years experience can not instantly morph into an advanced front end web application developer"
I think this is a bit contrived. It's a long way from C to modern web development, but I see no reason why to skip extensive C# experience applying for a Java shop etc.
Or even experience with a different paradigm (such as functional programming). Having worked with a multitude of technologies is beneficial for a programmer. It enhances one's understanding of the craft. It also proves the programmer has flexed their "learning muscles" a lot, which again is an advantage in its own right, since learning is a job never done. Even if you have the just right experience right now, what happens in 3 years?
Of course directly relevant experience should be given clear priority over "other stuff", but I wouldn't be so harsh as to say it better be skipped altogether.
Do you really believe that your 10 years of C# would keep you more efficient than say...John Carmack...after a few weeks on the job?
If you find a great programmer and they don't have your keywords you shouldn't turn them away. As long as they are excited about learning a new language they will be out performing some of your veterans in little time.
I cannot imagine an article more wrong than this one.
* "A seasoned C developer with 10 years experience can not instantly morph into an advanced front end web application developer" - yes he can. Knowing things on bottom easily allows one to move up. It is the reverse that usually cannot happen.
* "Ignore the usual template based CV padding" - if you got the resume through an agency, it would have never made it to you without this bullshit. Sad but true
* "You often need specialists and not generalists." - false Specialists will become useless when that technology is no longer in use (you move form C# to java, for example). generalists will just help you with your next thing.
* "If you are looking for a C# or Java developer. You would expect their CV to contain those keywords, in context quite a few times." - false. If you have enough interesting things to put in your resume, there is no space to write "java" 1000 times.
* "I would expect to see some of the following throughout their CV; Design Patterns (MVC, Factories, Singletons, ActiveRecord), Classes, Objects, UML" - who the hell puts "classes" and "objects" on their resme. If i have to explain to you what OOP is and includes, I do not want to work for you!
* "Community participation" - maybe accurate. Some people do not like handing out their code for free on github, and instead get paid for it (people who contract for a living, for example). Really want to disqualify them?
* "if it becomes the next big thing, this person could be the one to keep your company at the forefront!" - If you hire based on technology instead of actual understanding (which it sounds like you do) then you will lose long term. Hire people who can actually learn, not those who happen to claim to know the latest buzzwords.
Of all the brilliant people I know, you would have discarded 100% at resume review stage. Probably not the best of ideas, that.
"Of all the brilliant people I know, you would have discarded 100% at resume review stage."
Not really, because no one would tick all the boxes. If they haven't keyword dropped, then you can't apply that filter. if they have a brilliant track history then that pulls up the others that have been missed far greater than if they had keyword dropped.
Unless you're someone like Jon Skeet or Douglas Crockford you can't get away with an average CV. Those people have ticked the other boxes so much (social side, conference speaking, etc) which would greatly outweigh some of the other points which may be all the "junior" has got.
Although, like what that blog posts states, if you were Jon Skeet or Douglas Crockford you would already have ticked several of those things in that blog post ;)
Just because I have some pointers does not mean common sense must go out the window.
So no, the brilliant people you know would not of had their CV discarded at the review stage.
That part made me laugh. Including "objects and classes" on a programmers resume is like a trucker including "steering and accelerating" on his.
Unfortunately the person who is going to hire you often has no programming experience. Or if they did it was an intro to vb course. So concepts like objects seem like very advanced stuff to them as its likely some thing they just barely were ever to scratch the surface on.
Truckers have the advantage that their employets probably atleast drive some thing on a daily basis.
2. Ask about their strongest points in that section.
3. Then go deep on their strongest point.
4. Note their ability to follow your deep dive
5. Repeat this multiple times
6. Review notes:
- The more sections they have where they can dive deep to a reasonable level the more senior they are.
- The deeper they can go, the more difficult an actual problem in the prospective job can be that you can throw at them.
So far, this gave me a very accurate picture of their skill set.
The keyword matching thing is one of my pet peeves. I was discussing a position once where they wanted firmware AND machine control AND computer vision AND WPF AND C++ AND SQL for their machine. Now this a machine I could produce myself from scratch I think. But the client wanted his keywords met I didn't have them all.
The recruiter had a laugh when I wrote this:
I’m not sure Michelangelo had painted a ceiling before he painted the Sistine Chapel. “Hmm, Mike I don’t see any ceiling painting experience on your resume’...”
Article missed to ignore gigantic blocks of technologies used. This is not a good place to figure out what the person is current in.
Side question: I keep hearing that ATS have filtering systems to block and auto reject candidates' resumes if they don't hit targeted keywords. Would like to know some of these companies / what the ATS actually is. I have worked with several ATS systems with several companies and each one always have to a human going through every single resume.
"A seasoned C developer with 10 years experience can not instantly morph into an advanced front end web application developer"
True, but they'll be a damn sight quicker at picking it up than anyone else. And they'll write far better code when they're there.
If you're looking for a permanent employee, all development experience is relevant -- there is a huge amount of overlap and retraining just for a different language is no biggie. They'll also have solved (i'd bet) far harder problems than "HOW DO I GET THIS UI WIDGET TO UPDATE WHEN THIS HAPPENS".
If you're looking for someone to hit the ground running from day 1, or work as a contractor, it's different. But you generalise too far here.
"However, they have failed to mention anything else to back it up. I would expect to see some of the following throughout their CV; Design Patterns (MVC, Factories, Singletons, ActiveRecord), Classes, Objects, UML…"
In my CV (highly rated by everyone i've given it to) you won't find a single one of these. Instead, you'll find real descriptions of what i've accomplished, who I worked with (mentoring etc), my methodology (agile, test driven development) and so on.
And UML... holy shit, yeah, no.
Community work? See Ashe Dryden's "The Ethics of Unpaid Labor and the OSS community", http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-an..., and James Coglan's "Why GitHub is not your CV", https://blog.jcoglan.com/2013/11/15/why-github-is-not-your-c....
Hiring the right people has always been, and will continue to be, a hard job. The only way to do it is to use common sense and actually read the CV's you're being sent, then talk to the people you think could do the job to see if they can.