New to Typophile? Accounts are free, and easy to set up.
Create an account
Typophile RSS | More Feeds
Any tips / simple suggestions for formatting a resume?
I have a short resume I'm about to send out thats roughly a page and a half. I have set it in Univers.
This might give you some food for thought.
The 7 Deadly Sins of Resume Design
Give Your Resume a Face Lift
9 Resume Tips That Should Be Obvious, But Apparently Aren't
How to Write a Masterpiece of a Resume
How to Make an Impression with your Resume in 30 Seconds
Fixed Link: 10 Common Mistakes in Resumes and Cover Letters link credit: Ricardo Cordoba
Columbia College: Writing Resumes, Cover Letters, and other Essential Materials :Direct link to PDF, link credit: Michael Kostal
"I have a short resume I’m about to send out thats roughly a page and a half."
I'd recommend that you keep it to a page.
Where are you sending it too? A person? An HR department?
The typical advice is to keep it simple, don't 'over design' it, make it readable, and make it one page.
That said, in certain cases (namely large corporate HR departments), you may need to toss in a bunch of keywords to get by the resume filtering software.
I'm probably stating the obvious here, but remember that 'Résumé' has accents over both 'e' characters.
Here is the template I've used for my friends' resumes over the years. Always seems to get them the job. (I guess the fact that I have talented friends doesn't hurt.) I think it's best to keep it to one page. Don't be afraid to use columns for space efficiency and readability. The type is in Freight.
Nice work, Mr. Coles!
From the AIGA, Ten common mistakes in resumes and cover letters
I searched this Typophile for resume threads to find some nice examples. Once I developed a feel for what a good resume looks like, I designed my own.
Don't neglect design of the cover letter, follow-up letter, references list, and so on. You'll make a better impression if everything works together.
I don't see the need for "Relevant" - if it isn't relevant why include it in the first place? I'm also not wild about "Personal Skills" I think resumes should be just the facts ma'am.
Definitely keep it to a page. Feels padded otherwise. I sometimes attach a list of books I've designed (I'm a book designer) to the resume but the main resume itself fits on a page - even w/20 yrs experience.
You bring up a good point, Patty. You should tailor a new version of your resume for each new job app. In this sense, including the word "relevant" might be a little unnecessary.
I've read in resume books that you only need to include the word "relevant" if, for example, you've worked in different fields and therefore need to exclude jobs that don't pertain to your current job search.
the main resume itself fits on a page - even w/20 yrs experience
Wow, Patty, that's admirable!
awesome tips. thank you all very much.
I'm just applying for an internship.
Nice work Stephen. Sherry is lucky to have such a nice resume.
However, you should be using small caps for some things.
jlt : http://www.hewnandhammered.com
Haha. Like CA or E.I.T.? I dunno.
Since I have 45 years of experience, fitting it "all" in is a bitch, so I don't. I just detail the more current stuff and include a generalized brief paragraph sumary of the rest. I leave out the stuff where I helped Ben Franklin set type and that Summer internship with Homer doing layouts for the first edition of The Odyssey (he couldn't see his way to paying me so I left. In his eyes, it was a case of the blind leading the blind).
Here's one take on how resumes are read that you might find helpful.
I'm not quite your age, Chris, but I too leave out some of the older stuff.
Like the winter I helped Gutenberg with his en- and em-dashes and the pages of illustrations I did for The Book of Kells....
Stephen, I noticed a small grammar problem in Sherry's resume. May I suggest changing "Graphical Design in OpenGL" to "Graphical User Interface Design in OpenGL" or "GUI Design in OpenGL". That is, unless she actually designed graphs in OpenGL.
I know its nit-picky.
I do love the informal professional feel of your layout, it doesn't have that rigid/cold feel most black and white resumes have. Excellent font choice.
You sir, are a Font Savant!
I'll bet old Gut' sure looked dashing in 'em days Linda :-P
Nah, he wasn't my type.... ;-)
Some great info here folks. Makes me want to update mine...
You just had not found him justified to your measure :-)
I listened to his pitch, but as much as he pressed, he never got to the point. To cap it off, he was kind of lower cas(t)e.... ;-)
I guess his front didn't matter then.
Craig, that's a good link.
I never reacted well to "Objective" or "Summary of qualifications" or overly descriptive text in a resume. Nothing that smacks too much of self-promotion or filler. I want a concise job history with relevant (but not the word) responsibilities listed - ideally in bullet points. Education history, skills (software, foreign languages), awards are important too.
Re keeping it to one page - yeah, just edit the older stuff down to a line or two.
You can see the web version of mine at http://www.pattyfab.com if you want (click on Contact in the navigation) or download the pdf version if it would be helpful.
I'm with Patty on much of what she's suggested. "Relevant" is a dead giveaway that you're feeling awkward about your experience, and even if you are feeling awkward, that's the last thing you want to convey. Same goes for "personal" skills or anything along those lines. When I discuss résumé writing & formatting in class my foundation rule is to avoid, at all costs, claims of any kind. "I'm good with Photoshop." "6 years experience with InDesign." "If given the oportunity I will..." Crap, crap, crap. Like Patty pointed towards, prove it by listing what you've actually done. That said, don't let your résumé turn into a data file, it needs just a touch of personality (both in the design and the copy writing), but good writing and design are subtle (this isn't adverting, even if it is).
As for one page, I don't know about that. Mine's 9 pages long, and depending on the position/contract I'm going for I tend to edit it down to just the "relevant" stuff, which is still usually 5+ pages. While that first page has to do a lot of the work (almost all of it), one page always feels light to me. That said, if you've got a client list like Patty's, you don't need much else.
[Patty, you're stuff is too good to be represented by squooshed and pixelated graphics on your site. Kick your developer (or yourself) in the behind and reformat those graphics so that they display at their real size.]
I know its nit-picky.
Nit-picky is the name of the game. :-)
Jason, I agree with most of what you say; likewise with you, Patty. The resume is supposed to sell what you do best, etc. That said, my resume is 2 pages long (gasp!), and on the second page I do list which software programs I know and how long I've been using them. First and foremost is what I've done, though -- work experience and studies. I don't list references or bother to have a line that says they are available upon request. People know that stuff.
As for the "glimpse and a hook" article, that's the first time I've ever heard someone say they don't want a cover letter! Cover letters are supposed to show taht you, um, like, know how to communicate and stuff. ;-D
Jason - thanks. The person who did my site (not me) didn't know much about the nuts and bolts of web programming although I like the way it's designed. I'm gearing up to re-do it one of these days soon. But I'm not sure what you mean by squooshed and pixelated graphics - can you be more specific?
Perhaps he means that you should consider using GIF rather than JPEG for your type-based and flat colored images -- like your logo and name on the front page. JPEG tends to create artifacts and noise in these types of images.
Another problem is that it can take quite a bit of time to load all those wonderful images on one page (page 2). The covers should probably be split up between multiple pages, or at least be preceded by a preloader.
But we're digressing from the résumé discussion.
But we’re digressing from the résumé discussion.
Gee, like we never digress from topics here.... ;-)
One more note on Patty's site (in case it might be useful to others). The bug is that the images in your site are squished to fit in your HTML code; that is, the code is specifying dimensions that are not correct. Thus, when the image displays in a browser it's getting squooshed (that's the technical term) and thus ends up looking pixelated.
For instance, here's one of your graphics cropped in half but at its real size (approx. 400x400 pixels):
And here's what what it looks like on your site in my browser (your HTML code specifies the squooshed dimensions of 300x300 pixels):
It simply looks like your developer cut the corner of actually reformatting the images to the required size and instead just packed and crammed them into position in the HTML.
Part of the reason why the pages are so slow to download is that the image files are considerably larger (dimensions) than they need to be. If they were reformated to the correct dimensions, their files size would shrink quite a bit.
And while Stephen is right about the JPG artifacts, if you balance the optimization settings they're easily avoidable.
ps. Thanks a lot for bringing this up Eddie, now I've gone in to pare down my CV and I'd forgotten how painful it is to put these things together.
Thanks all. It also explains why when I created new pages I was finding the images not matching the previous pages.
I won't bogart this discussion anymore - but to ask one more question - if I were to manually reduce the jpegs to fit the 300 dpi the html calls for would they look better and load faster? Or do I need to get someone who knows their s**t to redo the code? I do know how to replace jpegs with gifs.
Yes, reformat the images to fit the code and they'll look fine and load faster (make sure not to change any of the file names [including extensions] or locations). Your code may be off by a pixel or two here and there, but the images will still look a lot better than they do now.
Thanks again. If I can actually find the few hours to fix this snafu I will.
"I won’t bogart this discussion anymore - but to ask one more question - if I were to manually reduce the jpegs to fit the 300 dpi the html calls for"
Just to clarify, HTML doesn't call for any DPI setting. It's merely saying the image is 300 pixels x 300 pixels, so you want to make your actual image 300 x 300 pixels. DPI is irrelevant.
Good point, sort of. DPI is, of course, relevant, because if the images were output as 300dpi JPGs then they're going to be squooshed in the HTML even more. I suppose I was assuming it obvious that graphics for web should be 72dpi, but the pixel dimenions of the graphics (in Patty's case) should match her HTML specs (eg. width="300" height="300").
yes that's very important - patty, my web builders implored me to supply my images to them at the pixel size i wanted them seen - at 72dpi. (exactly as jason explained above).
this also allows you to optimize the images for the reduced size. in my more complex illustrations, for example, i reduce them to the required size, duplicate the layer, slightly blur the top layer, then reduce it to 50% transparency. flatten again. this allows the original "bottom" layer to dominate, but it slightly forgives and softens the pixelation produced by radical reduction.
i do get into more specific tweaks but that's any easy formula for improved reductions.
DPI has nothing...zero...zilch...nada...to do with web graphics.
All that matters is the pixel dimensions. A 300px * 300px image should be specified as such in the HTML. Whether it was saved at 72dpi or 1000dpi is irrelevant.
Yes, OK, good clarification. But not everyone knows how to resample a graphic properly so that it displays at the desired pixel dimensions.
You can take a 300dpi (let's say 1780x1780px) graphic and downsample it to 72dpi, and it might still be 1780x1780px. If you squoosh that graphic into your HTML with specs of 300x300px, you end up with the right display size, but the file size is larger than necessary and (as in Patty's case) the image looks crappy. I'm not saying this is the right thing to do (it's the wrong thing to do), but many make this mistake.
On the other hand, you can resample that same 300dpi (1780x1780px) graphic down to 300x300px and leave it at 300dpi and you'll be good to go. No squooshing, file size is reduced, all good. Just don't try to use that one in print cause it'll only be one square inch.
The problem, in my experience, is that many folks do the former, or screw up the latter, and end up with graphics that are not the correct dimensions and/or resolution for their website, and the result is often similar to what Patty has run into.
i'm sorry, aluminum, but i disagree. its relevant because dpi is part of the image data whether "the web" cares or not, and because the web is always 72dpi, whether HTML knows it or not. dpi is part of rasterized imaging, regardless of platform, whether defined or not. 72dpi is the default for most familiar onscreen environemts.
patty's web problem is the proof.
her images were forced down to 300 pixels by HTML. the actual images are some other size when viewed at 72dpi, before involving HTML. The only way to make an HTML encoded graphic look lossless at 300 pixels is to supply it to the HTML at 300 pixels @ 72dpi. 1 to 1. no upsizing or downsizing, and defining 72dpi is part of that data, before it gets to HTML. any other dpi will result in interpolation of some kind, up or down.
believe me, i've been through this by trial and error. quality control dictates defining size at 72dpi for originals destined for the web at non-original sizes.
Actually Chris, while I was following your line of reasoning as well, Darrel (aluminum) is technically right. Check out this page as an example and you'll see that a 72dpi and 300dpi image display exactly the same, with or without width & height attributes, so long as the graphics are formatted to 300x300px.
well that's pretty cool but my own eyes have seen otherwise in hands-on situations.
perhaps there are other variables ? and what's going on in patty's case ?
I meant to say pixels, not dpi. I know web graphics should be prepared at 72 dpi. But I come from print so I'm used to thinking/talking in terms of dpi not in pixels.
Sorry if this caused confusion - my mistake.
But I didn't realize that the html coding in my site (which again I did not do) was forcing larger images into smaller frames or I'd have dealt with that sooner. As mentioned above I did run into confusion when I was trying to create new pages and the graphics were showing up at a different size.
"i’m sorry, aluminum, but i disagree."
This isn't an opinion issue. It's just how it is. ;o)
DPI is simply a setting that some desktop publishing products use to figure out default output if not otherwise specified.
For instance, if you set your DPI in photoshop, it will change the PRINT size if you print directly from photoshop. It doesn't change the number of pixels.
Save that image as a GIF or JPG to put it online, and the DPI info is gone and not needed, as the web doesn't have any use for it.
"dpi is part of the image data whether “the web” cares or not, and because the web is always 72dpi"
The web isn't any DPI. If anything it's measured in PPI (pixels per inch) and that varies from monitor to monitor and computer to computer.
Browsers may default to 72 or 92 DPI for printing a page, but, again, that's a browser setting and isn't anything related to your images. Browsers will also use default DPI settings to interpret type sizes, but it's not a direct correlation to a real inch in any shape or form (so only adds to the confusion).
"quality control dictates defining size at 72dpi for originals destined for the web at non-original sizes."
Try it. Save a 300x300 JPG and 1000dpi and at 50 dpi. Put them both on yoru web page. What do you see?
"But I come from print so I’m used to thinking/talking in terms of dpi not in pixels."
Right. DPI is a print concept. Toss it out the window when doing your web stuff. As you can see, it only confuses folks. ;o)
okay i bow to your expertise, tentatively... but why does an original 300x300 image at 300dpi look fine but the same image 300x300 at 72 dpi look crappy ?
i'm talking on-screen. print isn't even part of the workflow.
how could the conversion NOT involve interpolation ?
i don't come from print. i come from motion graphics. my life is on-screen, at 72 dpi.
i use lots of hi-res photoshop generated images, and dpi is a big part of the process and concern.
"but why does an original 300x300 image at 300dpi look fine but the same image 300x300 at 72 dpi look crappy ?
i’m talking on-screen."
I don't know what that is in reference too, but those two images would be exatly the same on screen.
"how could the conversion NOT involve interpolation ?"
There is no conversion. There is still the exact same number of pixels in each image.
Patty's issue was that a 300x300 image was set in the HTML to view at 200x200. Browsers dont' resize images very well, so doing that results in lesser quality than if you had resized the image to 200x200 in image editing software.
"i don’t come from print. i come from motion graphics. my life is on-screen, at 72 dpi."
No it's not. It's on screen as a pixel. ;0)
This is a subject that makes me cry and reminds me of how bad I am with numbers. I had both my boss and a co-worker sit me down not that long ago and help me understand the difference. I still don't fully grasp it. I live in a dpi print based world. But apparently the web doesn't care about dpi, only pixels.
DPI and PPI Explained
Display, Printing, dpi and ppi
The Difference Between DPI and PPI
okay i must be living in an alternate universe. every engineer i've ever depended on in 15 years of motion graphics production has agreed with me - taught me - that NTSC video is the equivalent of 72dpi. it's a functional equivalent, useful because so much of our material comes from graphics apps like photoshop. sometimes we prefer not to let the compositing software do the interpolation for us, but sometimes we do. it's case specific.
these dpi models have guided the work of me and my collegues for as long as i can remember. the advent of HD is a big headache for us, as there are so many more pixels to address "at 72 dpi".
Darrel, thank you. The light just came on for me when you wrote that it's on screen as a pixel.