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.