Resume rules
Apr. 17th, 2012 02:00 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeurConducted an interview this morning; suffice it to say I wasn't blown away in general, but the worst of it was the resume, which was almost Platonically bad. Let's count up the problems, each of which serves as a cautionary tale:
Check your freaking English: seriously, if you're going for a professional position (and programming is definitely a profession), there is absolutely no excuse for poor English on the resume. It's not just a matter of using the right words -- syntax matters, and not knowing when to appropriately use "a" and "the" looks bad. (Moreso when you don't have the excuse of being Russian.) Having syntax errors in the very first sentence is going to handicap you from the get-go. If you're not a native speaker, have someone who is one check it over for you; if you can't even do that, I am forced to wonder whether you fail on "not a team player" grounds.
Additional buzzwords don't make it better: listing all of the source-management tools you've ever used doesn't impress me. Listing them all as "SourceSafe"s mostly convinces me that you don't know what you're talking about. So does listing "Agile" and "Scrum" as separate methodologies if you're not prepared to explain the difference to me correctly. Listing HTML as a "development language" isn't *quite* as bad as listing test-driven development as a "technology", but it's close.
Formatting matters: not quite as important as the proper English point above, but again goes to looking professional. Having most of the resume look like one run-on paragraph, with no variation in the line spacing to separate the jobs, makes it look like it was written by a tenth grader. (And really, most of the computer-savvy tenth graders can make it look better than that.) It doesn't have to be a work of art, but at least make the effort to find a decently readable template -- if it's slapdash and hard to read, it comes across as a disrespectful waste of my time deciphering it.
Know your resume: folks often point out that having a three-page resume can be a negative. Here's a sharper point on that: listing something on your resume that you don't remember clearly is a Very Very Bad Idea. As an interviewer, I'm going to ask you about the things you list. If you keep having to ask to look at my copy of the resume, and then have to spend thirty seconds remembering what that line was talking about, you're doing yourself a disservice. If it isn't important enough for you to make the effort to bone up on it and have it fresh in your mind, it isn't important enough to list on the resume.
Don't inflate: the uber-sin, that trumps all the others. If you list yourself as "Architect" -- if you claim that you have *ever* been an Architect -- I am going to treat you like one. And if I discover that your actual skills are those of a conventional Senior Software Engineer, it's going to go worse for you than if you said that in the first place. When you say that you "re-architected" a software system for a client, and I find on drilling down that all you did was perform fairly conventional refactorings, I'm going to get downright annoyed.
All of this boils down to two points, which (uncharacteristically) I'm willing to say are hard and fast rules if you're interviewing as a programmer:
Check your freaking English: seriously, if you're going for a professional position (and programming is definitely a profession), there is absolutely no excuse for poor English on the resume. It's not just a matter of using the right words -- syntax matters, and not knowing when to appropriately use "a" and "the" looks bad. (Moreso when you don't have the excuse of being Russian.) Having syntax errors in the very first sentence is going to handicap you from the get-go. If you're not a native speaker, have someone who is one check it over for you; if you can't even do that, I am forced to wonder whether you fail on "not a team player" grounds.
Additional buzzwords don't make it better: listing all of the source-management tools you've ever used doesn't impress me. Listing them all as "SourceSafe"s mostly convinces me that you don't know what you're talking about. So does listing "Agile" and "Scrum" as separate methodologies if you're not prepared to explain the difference to me correctly. Listing HTML as a "development language" isn't *quite* as bad as listing test-driven development as a "technology", but it's close.
Formatting matters: not quite as important as the proper English point above, but again goes to looking professional. Having most of the resume look like one run-on paragraph, with no variation in the line spacing to separate the jobs, makes it look like it was written by a tenth grader. (And really, most of the computer-savvy tenth graders can make it look better than that.) It doesn't have to be a work of art, but at least make the effort to find a decently readable template -- if it's slapdash and hard to read, it comes across as a disrespectful waste of my time deciphering it.
Know your resume: folks often point out that having a three-page resume can be a negative. Here's a sharper point on that: listing something on your resume that you don't remember clearly is a Very Very Bad Idea. As an interviewer, I'm going to ask you about the things you list. If you keep having to ask to look at my copy of the resume, and then have to spend thirty seconds remembering what that line was talking about, you're doing yourself a disservice. If it isn't important enough for you to make the effort to bone up on it and have it fresh in your mind, it isn't important enough to list on the resume.
Don't inflate: the uber-sin, that trumps all the others. If you list yourself as "Architect" -- if you claim that you have *ever* been an Architect -- I am going to treat you like one. And if I discover that your actual skills are those of a conventional Senior Software Engineer, it's going to go worse for you than if you said that in the first place. When you say that you "re-architected" a software system for a client, and I find on drilling down that all you did was perform fairly conventional refactorings, I'm going to get downright annoyed.
All of this boils down to two points, which (uncharacteristically) I'm willing to say are hard and fast rules if you're interviewing as a programmer:
- Make the effort to make your resume look adequately professional.
- Don't brag, don't inflate, don't fill it with puffery -- keep it real, honest, modest and limited to things you're prepared to talk enthusiastically and knowledgably about.
(no subject)
Date: 2012-04-18 12:53 pm (UTC)Sure -- but they still aren't rocket science. They boil down to "tell the truth and don't brag". Again, I think that's an appropriate minimum bar.
And the truth is that, in this particular case, I consider it possible that the candidate isn't *intentionally* fibbing -- he may just have no idea what he's talking about. But that's almost worse for someone with claims to have a decade-plus of experience. I'm fairly forgiving for someone who is applying entry-level, but if you're claiming to be senior, these rules become very sharp.
In fact, if the recruiter gives you a crappy resume, that reflects on the recruiter more than the candidate.
I have no idea whether this was through a recruiter or not, but that's true.
That said, it just underscores that you can't trust the recruiter to make it all better -- it behooves you to make sure your resume is as good as you can get it. (Remember, I did intentionally phrase this as lessons for readers to learn from...)