The idea of a one page resume

I used to be in favour of one-page CVs, but after talking to a friend recently who had to look through CVs at work (non-games) most were two or three pages (with the occasional four page one) and that was both accepted and normal practice. Now my target is two pages. Although they indicated that three pages was fine, I don't personally think you should go to three pages unless you've got, say, 20+ years experience and have a lot of previous jobs you need to list.

The majority of raw college graduates who don't yet have much work experience are better served by a one-pager. Once there's stuff that can't or shouldn't be omitted from the resume to make it fit on one, then go to a second.
I've learned that if you have a three-pager, some impatient hirers will never notice that there are more than two. They're not expecting more than two.

[Edited by - Tom Sloper on October 22, 2009 11:31:59 AM]

I'll agree with Mr. Sloper a little bit on this one. I have been in the position of hiring people before and it's a pain to wade through resumes that are 8-9 pages long. Personally, I think 1-2 pages is a decent length, depending on the experience you have. As you stated, the first page should be enough to convince me to pay attention to you, and anything extra should add to making me want to interview you. Normally when I get a resume that is longer than 2 pages, the candidate is simply trying to pad the resume with as many keywords and good-looking things as possible in order to stand out from the rest of the crowd, though it doesn't make me want to interview them any more than the guy who's got an awesome 1-2 resume (actually, it often makes me want to interview them less...).

Recruiters stop reading your resume on the third page not because they're lazy but because it shows you either don't know what skills are required/relevant for the job, or you don't care.

You can summarize the skills you have that are required/relevant for almost every job in a single page, any other unnecessary skills mentioned are just there showing you don't know what the job is about.

It also shows you can't decrease the size of the fonts on a word processor, which is always a bad sign.

There are lots of little things on your resume that I wouldn't put on a resume but you are the more successful, so perhaps I should learn rather than criticize.

Things I would have left off:
Development environments.

Everything on the second page except for college. No offense but no one cares where you went to high school. Under personal projects I don't see any personal projects just course work, and frankly course work stopped mattering after the work experience section. I would have had a link to personal projects and publications. Unless you were applying for a technical writing position then I would swap Published software and publications.

I view the one-page-requirement for resumes in the same line as the always-use-the-C++STL advice. There are situations in which you will want to use more than one page, but when you reach that point you will be experienced enough to be able to know when you need to and what experience to put where.

People new to the hiring process tend to bloat up their resume with a lot of unneeded crap that hiring managers don't care about. Also, a multi-page resume is only going to have that second, or third, page read after its been screened several times. That means if you do not organize the information so that the most important stuff comes early on the first page, you are likely to get your resume thrown out prematurely.

A person with many years of experience may need to have two or three pages, but he or she is also more likely to know how to organize that experience to get through resume screening, and not bloat up their resume with unneeded entries.

Quote:

Original post by stonemetal Everything on the second page except for college. No offense but no one cares where you went to high school.

The non college stuff was filtered out after this particular version was done.

Quote:

Under personal projects I don't see any personal projects just course work, and frankly course work stopped mattering after the work experience section.

Actually, based on my experiences and informal conversations with other industry friends, this is really a good section, especially leading into the interview. It frames me as someone who is highly motivated when it comes so software, has team experience, can talk about projects retrospectively, and so on. Game developers in particular tend to value that independent drive heavily.

Quote:

I would have had a link to personal projects and publications.

Nobody will bother to look at that. Nobody ever wants to see my demos, either. They're more interested in what I have to say about them.

Quote:

Unless you were applying for a technical writing position then I would swap Published software and publications.

Eh? Published software is first. Why would it be the other way around?

Quote:

Original post by Rycross I view the one-page-requirement for resumes in the same line as the always-use-the-C++STL advice. A person with many years of experience may need to have two or three pages, but he or she is also more likely to know how to organize that experience to get through resume screening, and not bloat up their resume with unneeded entries.

A person with many years of experience has many years of experience that are no longer relevant and probably shouldn't be on a resume. Your first job out of college isn't relevant 20 years latter even if it is in a relevant field job responsibilities, type of work performed, etc. are vastly different between entry level positions and upper level positions. Promit's resume is probably the right length for what he has listed, but I doubt any one reads below the tech skills section.

Quote:

Actually, based on my experiences and informal conversations with other industry friends, this is really a good section, especially leading into the interview. It frames me as someone who is highly motivated when it comes so software, has team experience, can talk about projects retrospectively, and so on. Game developers in particular tend to value that independent drive heavily.

Yes if they were personal projects. All I see listed is course work.

Quote:

Original post by stonemetal Quote: Actually, based on my experiences and informal conversations with other industry friends, this is really a good section, especially leading into the interview. It frames me as someone who is highly motivated when it comes so software, has team experience, can talk about projects retrospectively, and so on. Game developers in particular tend to value that independent drive heavily. Yes if they were personal projects. All I see listed is course work.

Recent stuff is course work because I've been in school. The last entry isn't coursework and older stuff got filtered out. More to the point, my "personal" projects are published open source projects with users. I can see an argument for retitling the last section -- but coursework vs personal projects is a fairly trivial distinction.

Oh, also my two pages is kind of a stretch, but one and a half looks pretty awful so I end up with a bit of padding here and there. "Development Environments" actually makes the page and section breaks line up.

[Edited by - Promit on October 22, 2009 1:41:39 PM]

Here's my take on this subject, which is from the hiring side of things, not from the applicants side of things...

I'm a solutions architect consultant, which means that usually when I'm called in it is to lead or assist a team in designing and developing software solutions for large business problems. Usually there will be a team in place, but throughout the development cycle of the software required new people will be needed to be hired, and fired. That means that I usually end up in some position where I'm reviewing new applicants for positions within the team. This advise though applies to pretty much any job, except perhaps designer positions.

So a few things about your resume and what I'll look for when I have a stack of five hundred or more resumes sitting on my desk for a job position: Now, I'm certainly not going to read through all five hundred resumes, that would be a waste of time since most of them are probably not worth the paper they are printed on. That means I need a way to quickly eliminate the majority of them and reduce it down to a small core set that I can then actually focus my attention on. Now, some might point out that any process of elimination that's fairly rapid will probably eliminate potential candidates too, and they would be correct.

So, what sorts of quick and easy to use methods are there to eliminate a large number of resumes quickly? Well, one of the quickest and easiest is just plain old color. If your resume isn't on white paper, preferably of a decently heavy weight, I'm probably going to chuck it. Also, is it too long? If it's over 3 pages, then it probably is. My goal in reading your resume is to get an idea of your character, what you've done, and how much skill you have, not to read a biography of your life. Then there's elimination through the identification of fluff. What is fluff? Well, simply put: If you're taking more than two sentences to describe any project you've worked on, then you're fluffing. Don't. If you have only a single page of experience then make that the best damn page I've ever seen, don't bloat it up to two pages by being overly descriptive of your magical role in helping save old people's pension plans from being spent by old people through the clever use of various life insurance programs. I don't want to read a story about how you saved a development team from being late and having their project canceled by magically summoning up script fairies that coded up the missing chunks for that overly important demo the next day. Anyone who has had to be in the position to review people for a position can usually easily identify fluff.

Now, college applicants have one huge disadvantage over most other applicants, and that is experience. You have been in college for four years, have your bachelors, but have nothing else behind you. In come the personal projects. Having a finished or even moderately complete personal project on your resume tells me two things: 1. you have the gumption to finish a project that you've started, and 2) you enjoy software development enough that you're willing to practice it on your own free time. Now, personal projects should be available in some format or another that I am able to query for. You should be able to produce source copies on demand, or a link to the work online. I do not need this with your resume. I do not have the time to view your source code when reviewing resumes.

Finally, there comes the cover letter. ALWAYS have a cover letter. NEVER use a form letter. Let me be quite frank here: I can spot a form cover letter a mile away. If the cover letter is a form letter, why should I bother to read the rest of the resume? You couldn't make the effort to customize a letter to me about why I should hire you, so I'm not going to waste the effort to read your resume. Personalize it; tell me about what you know of my company, why you think you would fit in, and how your experience can add value to my team.

So, let us look at Promit's resume:

1. Summary and Objectives:
   Good, this is something that I can take a look at quite quickly and immediately get a feel for the candidate. It also shows me that they understand that their resume is not going to be read in full, so they put the most important information right where I can find it the easiest.


2. Work Experience:
   The most important kind of experience in my opinion. Short and to the point, one to two sentences per job explaining position and responsibilities. No real fluff there.


3. Technical Skills:
   Good to know, if I'm hiring for a C developer on a project building COM components, then knowing you have C or at least C++ experience is important. The operating systems information isn't really all that important unless you have some oddball ones (for instance development work on the PS3/XBOX or *nix development experience. Development environments are also a good thing to know, although not supremely important.


4. Published Software:
   Probably more important to me than your technical skills (which can be trained) . Short and to the point descriptions of the software helps. Providing short links to the software also helps. Having his name on the front page of SlimTune also helps. Have to do a bit more browsing work to find the same information on the SlimDX page though.

Overall, from a first page perspective this is starting out good. There's an acceptable amount of information that focuses on the core components I care about. On the second page we get more meat and potatoes, and things look quite good there too. I would probably drop the high school component, as I could care less if you got a GED or graduated from high school. Having a college education is all that matters there, and what level of a college education.

After reviewing this resume, I would probably give the applicant at least a first round of interviews. Depending on those, what kind of chemistry we developed, how I felt about them personally, how I felt on that day (was I angry, sad, hungry, etc.) I will frequently host my second interviews over a private lunch, that way I can see how they react in a more public environment and in a more relaxed atmosphere. No one reacts as they do normally during a first interview, but usually over a lunch for the second, they'll be more their normal selves.

On the interviewing side of things: Shower. SHOWER. SHOWER! Also, do not wear anything I can smell. No perfume, use odorless deodorant. The last thing I want to smell is your Axe body spray, your cologne, or your perfume. I'm not there to sniff your ass, I'll leave that to the dogs.

Also on the hiring side, but with less experience than Washu.

3 Pages is too long. More than maybe 8-10 years ago I don't really care about. I don't care about cover letters. I don't care about objectives (though a summary like Promit's is good). Don't kiss my ass, don't sell me, show me the goods (your experience).

I like Promit's resume. Terse without being curt. Even though it's 2 pages, there's not a lot of cruft to read through. Better to have 2 pages with good formatting and font size instead of 1 page of stuff packed in there.

If this should go in its own topic you can tell me and delete the message and I'll repost it.

How do you address indie games that actually get major portal coverage? I'm not talking about some little game you hawk on your personal site using a PayPal account. But something like on Big Fish Games or Mumbo Jumbo where its more "commericalized"? I could argue that it might be professional work in that you may have got an advance and are getting royalties. Then again since you aren't working for anybody it could just as easily be a personal project.

Quote:

Original post by jtagge75 If this should go in its own topic you can tell me and delete the message and I'll repost it. How do you address indie games that actually get major portal coverage? I'm not talking about some little game you hawk on your personal site using a PayPal account. But something like on Big Fish Games or Mumbo Jumbo where its more "commericalized"? I could argue that it might be professional work in that you may have got an advance and are getting royalties. Then again since you aren't working for anybody it could just as easily be a personal project.

Note: I am NOT a lawyer, and what is presented below is NOT legal advice.
This really should be another topic. The legality and ownership of side projects is a controversial area, and in general you should check with your lawyer or company's lawyer before trying to self publish software, or anything really, that might come into conflict.

Most companies will have you sign an NDA or other contract when you start work for them; some of the clauses in there may or may not be valid within the state or country you work in. Again, this is an area that is best addressed by a lawyer. A few things to note though: Read through the contract, be very careful of the wording. Words in formal English can mean entirely different things than in casual, and legal English is strictly formal. Most contracts will have an ownership clause, be careful of these. Most employers are fairly decent and only demand ownership of the work on the clock. But some attempt to claim ownership over all work you produce while employed by them. Those are the ones you typically should negotiate, either for the removal of, or rewording of. A prime example of a company that tries to do that is RHI. In general you should just avoid those employers if you can. Furthermore, even if they don’t own work off the clock, you have the issue of competition and IP. Your work could be claimed to be derived from, or based on, information you obtained through employment there, and thus they might have a legal claim to your IP or that your work violates the competition clause. Again though, some of those might not be valid in the state or country you work in (a prime example is that most times a non-compete clause is deemed invalid if it will prevent you from being able to practice a livelihood).

I was asking more about where commerical indie game stuff should go on a resume. If you are making a decent living doing casual games on the side that seems like its more then a personal project to me. As well if you got your act together and got a registered company for said games. To use Promit's resume as an example there should be no issues if you put said games in published work but maybe not work experience? But then there is the arguement that managing even a small company with a team is 'work'.

Since this thread has kind of turned into different parts of a resume I thought this might be a place to start. Is there anyway to move these posts into a thread of their own? If not I'll start a new thread in the business section and delete the content of these posts.

Quote:

Original post by jtagge75 I was asking more about where commerical indie game stuff should go on a resume. If you are making a decent living doing casual games on the side that seems like its more then a personal project to me. As well if you got your act together and got a registered company for said games. To use Promit's resume as an example there should be no issues if you put said games in published work but maybe not work experience? But then there is the arguement that managing even a small company with a team is 'work'. Since this thread has kind of turned into different parts of a resume I thought this might be a place to start. Is there anyway to move these posts into a thread of their own? If not I'll start a new thread in the business section and delete the content of these posts.

Ahh, no, I would suggest putting that under "Work Experience" rather than personal projects.

Quote:

Original post by jtagge75 If this should go in its own topic you can tell me and delete the message and I'll repost it.

I'm not deleting the message. But it should be obvious that your successful indie effort does not fall under the category of "should a resume be one page." Please start a new thread when you have a new topic.

Quote:

Original post by Tom Sloper I'm not deleting the message.

But I am closing the thread.