How to rip apart a programmers CV
codercramp.com
codercramp.com
"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.
Also, the poor capitalization/grammar in places. e.g. (which i will cover shortly)
I'm amazed this was upvoted.
Mainly to do with the fact I am from the UK and we spell things differently to people in the US.
Fair enough but I'd suggest in the future you proofread more before self-submitting to HN.
"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.
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.
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.
It just means: don't select people for their getting-a-new-job skills. Those skills aren't relevant to software development work.
It would be helpful to know more about what you do versus what you don't.
Which is why I wrote that blog post. Just to make sure it stands less of a chance to get screened.
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.
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.
* "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.
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.
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.
1. Take a section of their C.V.
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.
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’...”
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.