PS: this is slightly biased towards IT people
I've been giving a lot of interviews over the past 6 months and I have both learned a lot from both sides of the fence along with what makes a good resume. I figure it's time I post some of this info as I've seen a few mistakes pop up for many candidates.
Here's some pet peeves on resumes:
1. Since other developers often approved your resume from a technical aspect, they have many projects & deadlines and reading your resume is not one of them. In fact people are generally lazy and don't have time to read. Anything past the first page may not be read. This means your best choice is to create two resumes, a one pager and a full resume.
2. If your last page contains 1 or 2 sentences it's time to learn how to set your margins, font sizes or just general size tweaking, stop wasting the paper. If you don't this shows a lack of attention to detail and I'm guessing your work ethics and code aren't much better.
3. When listing your job history, when you worked, and the name of the company isn't as important as you think. Focus more on your title and a short summary of your job function. Don't bold the company name or dates, bold your job title instead because that's what people are really looking for. Don't be afraid to change your job title if the official one you had isn't an accurate description, but don't lie or choose a title that's simply not correct.
4. Spelling errors!!! Even crappy text editors have a spell check, use it. Also it's a resume, proof read it.
PS: I hold my blog to a low standard, I try to spell check it but I rarely proof read. Let's not forget that until Google has a good blog search engine, blog posts are very disposable (for now) so I'm not going to spend too much time on them.
Update July 2015: how ironic that back in 2005 I wrote about blogs not being searchable (parseable) and now we have social media, which replaced blogs and are very searchable.
Pet peeves during the interview process:
1. When talking about a past project, don't focus in on company names or acronyms or about the people you work with or any "funny" story you had. Chances are it only matters in your head. Most importantly is listing all the 3rd party "companies" your clients or project related to, the truth is, you could tell me General Mills or Kodak and it won't change the value of the story, so it doesn't matter, it's not worth mentioning. IOW simply using the term "clients" is more than enough, don't names them, ask if I've heard of them or give me a mini history of them, it doesn't apply. I'm only interested in how you created your database, if you normalized the structure, how your app uses the data. The fact you created this for John Doe, the IT Director of Bling Bling Inc, is totally irrelevant.
2. Ask questions.... the less questions you have, the more of a sheep you look like. I don't want to hire sheep, I want go getters. Even questions that I can't answer are fine, I often find it amazing when people don't ask about health insurance info, how much vacation time you will get, or if the environment is a high stress or low stress environment. If you are a developer you should be finding out how big the dev team is, how big IT is and if there's a formal project manager and who determines deadlines.
3. Learn in your spare time. IT is too busy of an industry to never read up on new stuff in your spare time. If you stop learning, you'll be no different than those 45yr olds who still develop on a green screen mainframe in databases that use string only data types. Trust me, your super cool VB6 skills are starting to look really dated to a .Net team. In fact if you are an active .Net coder and haven't at least tried VS2005 and know what ASP.Net offers (if you're into web dev) you've already raised a red flag with me. You don't have to be an expert in emerging technologies but at least know they are there and can summarize them.
Well that's enough from me now, chit chatting about interviews and resumes has perked my interest lately (I even talked about the subject at my local .Net user group). Maybe I'll post more or elaborate in the future. I'm definitely on a crusade for having the best resume ever and will be making some big changes to my 1 pager and I'll post it here when done.
ORIGINALLY POSTED ON MONDAY, OCTOBER 03, 2005 11:29 PM
I've been giving a lot of interviews over the past 6 months and I have both learned a lot from both sides of the fence along with what makes a good resume. I figure it's time I post some of this info as I've seen a few mistakes pop up for many candidates.
Here's some pet peeves on resumes:
1. Since other developers often approved your resume from a technical aspect, they have many projects & deadlines and reading your resume is not one of them. In fact people are generally lazy and don't have time to read. Anything past the first page may not be read. This means your best choice is to create two resumes, a one pager and a full resume.
2. If your last page contains 1 or 2 sentences it's time to learn how to set your margins, font sizes or just general size tweaking, stop wasting the paper. If you don't this shows a lack of attention to detail and I'm guessing your work ethics and code aren't much better.
3. When listing your job history, when you worked, and the name of the company isn't as important as you think. Focus more on your title and a short summary of your job function. Don't bold the company name or dates, bold your job title instead because that's what people are really looking for. Don't be afraid to change your job title if the official one you had isn't an accurate description, but don't lie or choose a title that's simply not correct.
4. Spelling errors!!! Even crappy text editors have a spell check, use it. Also it's a resume, proof read it.
PS: I hold my blog to a low standard, I try to spell check it but I rarely proof read. Let's not forget that until Google has a good blog search engine, blog posts are very disposable (for now) so I'm not going to spend too much time on them.
Update July 2015: how ironic that back in 2005 I wrote about blogs not being searchable (parseable) and now we have social media, which replaced blogs and are very searchable.
Pet peeves during the interview process:
1. When talking about a past project, don't focus in on company names or acronyms or about the people you work with or any "funny" story you had. Chances are it only matters in your head. Most importantly is listing all the 3rd party "companies" your clients or project related to, the truth is, you could tell me General Mills or Kodak and it won't change the value of the story, so it doesn't matter, it's not worth mentioning. IOW simply using the term "clients" is more than enough, don't names them, ask if I've heard of them or give me a mini history of them, it doesn't apply. I'm only interested in how you created your database, if you normalized the structure, how your app uses the data. The fact you created this for John Doe, the IT Director of Bling Bling Inc, is totally irrelevant.
2. Ask questions.... the less questions you have, the more of a sheep you look like. I don't want to hire sheep, I want go getters. Even questions that I can't answer are fine, I often find it amazing when people don't ask about health insurance info, how much vacation time you will get, or if the environment is a high stress or low stress environment. If you are a developer you should be finding out how big the dev team is, how big IT is and if there's a formal project manager and who determines deadlines.
3. Learn in your spare time. IT is too busy of an industry to never read up on new stuff in your spare time. If you stop learning, you'll be no different than those 45yr olds who still develop on a green screen mainframe in databases that use string only data types. Trust me, your super cool VB6 skills are starting to look really dated to a .Net team. In fact if you are an active .Net coder and haven't at least tried VS2005 and know what ASP.Net offers (if you're into web dev) you've already raised a red flag with me. You don't have to be an expert in emerging technologies but at least know they are there and can summarize them.
Well that's enough from me now, chit chatting about interviews and resumes has perked my interest lately (I even talked about the subject at my local .Net user group). Maybe I'll post more or elaborate in the future. I'm definitely on a crusade for having the best resume ever and will be making some big changes to my 1 pager and I'll post it here when done.
ORIGINALLY POSTED ON MONDAY, OCTOBER 03, 2005 11:29 PM
