From time to time people ask me to help them write a résumé for a job application or review their CV. I have also noticed the topic popping up elsewhere, so I decided to write down some of my general advice and recommendations for everyone to see (and discuss). These guidelines are intended for programmers, software developers, system architects, system administrators, technical support staff and other people applying for technical and engineering positions, but many of the ground rules are valid for any profession.1

The Anatomy of a Résumé

The main purpose of a résumé2 is to get you an interview. It’s fair to assume that your résumé will only be one in a large pile of applications, and that whoever is reading them is a busy person who’s time is limited and/or valuable. Therefore, it’s important to note that a potential employer wants to learn as much as possible about you, your skills and your experience by reading as little as possible.

With this in mind you should keep it short and to the point. Few people bother to read anything longer than three pages, and some may only read the first page or the first few paragraphs during the initial screening. Therefore, put the most important information first, and make your first page a memorable one. As we all know, you don’t get a second chance to make a first impression.

To help your readers easily locate the information they are looking for, I recommend following a traditional CV layout with a structure your reader is already familiar with:

  1. Personal details and contact information.
  2. Work experience (in reverse chronological order).
  3. Education and training (in reverse chronological order).
  4. Optional sections (order may wary).

While the sections in the fourth part may appear in any order, I do not recommend changing the order of the first three parts. These should appear in the order listed to make quick scanning as easy as possible. It also shows that you know how to set up a résumé properly, thereby implicitly indicating that you have a certain level of professionalism.

1. Personal Details and Contact Information

Maybe the most important part of a résumé is your personal details and contact information. It doesn’t matter if you have the best qualifications in the world if a potential employer doesn’t know who you are or how to get in touch with you.

I recommend always including the following on the first page:

  • Your full name and date of birth. If your have a foreign or uncommon name, or your name is commonly used by both men and women, including your gender may also bee a good idea.

  • Your home address. This is important to show your geographical location. If you are applying for a job in a different region or country than where you are currently living, providing some information about whether you will be locally available for an interview is also recommended. If you are staying on a temporary address while applying for jobs (i.e. while visiting abroad), also include the temporary address to show that you are locally available.

  • Your phone number and e-mail address. Obviously, you must provide this in order for a potential employer to contact you. If you are living in a different time zone and/or country from where the employer is located, it may also be a good idea to include some information about when you will be available via phone or when you will be replying to e-mails. This also applies if you are only available at certain times because of your current job or other factors. In general, you should only list phone numbers and e-mail addresses that you will be able to respond to immediately or within a short time frame. A potential employer trying to call you only to be met by an answering machine or an endless ringing may not bother to call back, so make yourself as available as possible.

  • Address of your homepage, blog or otherwise relevant web site. This should only be included if the site(s) contain information about you or your technical skills and experience that is relevant to the position(s) you are applying for. A good example of this would be a link to a software project you are participating in or a technical blog you are contributing to. Such sites can provide useful background information for an employer and is a good way to show your interest for projects outside of work.

Some people also like to include their marital status and number of children (when applicable) with their personal details. Some argue that including such information can be beneficial in helping the reader get an overall impression of you as a person (i.e. are you a family person or not), and it can be useful as a casual conversation topic during an interview, but not including it is not likely to affect your application negatively.

Often people ask if they should include a picture of themselves. Personally I don’t have any strong opinions on this, so feel free to do it if you want to. In some countries pictures are more common, but they are hardly ever required for technical positions.

Update: As several readers have pointed out, including your age, date of birth, gender, ethnicity, marital status, picture and other “trivia” is not recommended in many countries (including the EU), due to the employer’s possibility of rejecting the application in fear of discrimination lawsuits.

Quick Summary

Since résumés are typically scanned very fast, I recommend to include a short—one or to paragraphs–”snippet” about yourself at the top of the first page (after the basic personal information, contact details, etc.). If someone only reads the first few sentences of your résumé, this is your only chance to make a good first impression.

A good way to quickly give the reader an overview of your skills and qualification is to also summarize your areas of expertise and key domains with a few keywords on the first page. Again, this is your first impression for lazy and busy readers, so put “trigger” keywords here that will make people interested in reading more. For example:

Key areas:
programming, quality assurance, usability, networking (TCP/IP), enterprise systems, distributed applications, Scrum, security, databases (SQL), test-driven development, real-time graphics (2D/3D).

Don’t fall for the temptation to put a lot of buzzwords in this section. It’s not likely to impress anyone and you risk appearing to be trying too hard. It’s much better to use plain, regular words to describe your skills and areas of expertise. However, if you are responding to a job opening where experience with specific technologies or domains are required, you should list them (given that you have the required skills and experience, of course), even if they seem a bit “buzzy”. After all, if the employer listed them, they hopefully know what they mean and why they are important. Also, never include words or technical phrases if you are not absolutely confident you know what they mean. If something is on your résumé, be prepared to answer questions about it during an interview.

In conclusion, the first page is the most important page of your résumé. Ideally, this page should contain enough information to still make you an interesting candidate for the job, even when your cover letter and original application is lost (believe me, it happens) and somebody forgot to staple the pages together after printing, so only the first page makes it to the reviewers desk (yes, this also happens).

2. Work Experience

Work experience should be listed in reverse chronological order with the newest positions/projects appearing first. It’s also quite common to elaborate more on the most recent entries and provide less detail for older ones.

To make the list easy to scan, I recommend laying it out as a two-column table, listing the year in one column and position/project description in the other. For positions or projects lasting shorter than a year, list the year in the left column and provide a note about the duration in the right column. For anything lasting more than a year, provide a number range in the left column. To keep the list as simple as possible, you should avoid specifying dates in the left column. If anything needs further clarification or specification, write it as a part of the description in the right column.

An alternative to the two-column table layout is to write out each entry as a separate paragraph, with the paragraph heading containing year or year range (possibly with duration) and job title or project name.

How much detail should be provided with each entry in the work experience list is a hard to say in absolute terms, as this will depend on how much experience you have and how much there is to tell about each position or project. If you have many entries in your list (i.e. due to participation in many projects or extensive work experience over many years), you may have to shorten your descriptions to avoid making the résumé too long. If you lack experience, it’s fine to elaborate on whatever experience you do have, but avoid writing too much just to fill up the page. Again, the less is more principle applies, so chose your words carefully and keep it short and to the point.

It’s also a good idea to include keywords for your work experience. If you write a few sentences about each job position or project, also include some keywords about the languages, concepts and technologies used. Again, this is to make the list easier to scan for people who don’t have time to read it all or who are looking for specific “triggers”.

Example:

2006: Mad scientist assistant, Insanely Rich Man Inc., Secret Place.
      Worked as an assistant for a mad scientist on a private research
      project funded by an insanely rich man. Developed humanoid robots
      to feed and play with his pet tigers while he was on vacation.
      Project duration: 6 months

      Keywords: Python, C++, Scrum, robotics, micro-controllers,
      animal psychology.

3. Education

Your education should be listed in a similar way to the work experience, preferably with the same layout (i.e. a two-column table or separate paragraphs with accompanying headers).

If you have taken certifications or training courses after graduating from a university, college or other higher education, I recommend listing them separately in a section after your “traditional” education. There’s nothing wrong with interleaving the two, but separating them often make it easier to scan the page and quickly locating your formal eduction and your certifications independently of each other (i.e. an employer may not care whether you have a master or bachelor degree, but just wants to see if you have a given certification or have attended a certain training course).

4. Optional Sections

The final sections of the résumé do not follow the same strict rules as the ones describe above, and opinions on what to include and not include vary greatly. However, some sections are more common than others. One of the most common to include is a list of spoken and written languages. Some also like to include a listing of volunteer work they have done or organizational positions they hold or have held (i.e. coaching a junior soccer team or working Monday nights in a soup kitchen). This information may not be directly relevant to the position you are applying for, but it can provide an indication of commitment, social skills or leadership talent (even if the experience is informal).

Hobbies and Interests

I also recommend to list your hobbies and interests. They tell something about you as a person and it gives the interviewer a chance to “break the ice” and make you relax with some smalltalk. You might be surprised how often geeks (even geek bosses) share similar interests, also outside the domain of computers and natural sciences.

If you have participated in any hobby or open source software projects or published any articles or other manuscripts, I also recommend making a section describing those. This can be particularly beneficial if you lack formal work experience or formal education, as describing hobby projects or other relevant experience shows that you have an interest in your field and are eager to learn.

Skill Table

If you have experience in many programming languages or technologies, it might be useful to list them in a three-column table listing the language or technology, years of experience and your subjective experience level. For example:

  Language    Level           Known since
  C++         Basic           2005
  Perl        Basic           2007
  PHP         Intermediate    2004
  Java        Advanced        2003

This gives the reader a quick overview of your experience levels and allows you to list many entries in a compact and clean way. The table can consist of any skill, technology or domain you want to emphasize and is of course not limited to programming languages.

References

Some people recommend listing references on your résumé. Personally, I don’t see any need for this, as references are usually not relevant until further down the line. It’s very unlikely that anyone would need to check your references before an initial interview, so I doubt anyone would require them on a résumé. That being said, having references on your résumé will never hurt. I can imagine some employers prefer it that way, as this may save them some time when looking up your references later (i.e. they don’t have to remember where they wrote down the names and phone numbers during the interview). Anything that will make life easier for the employer is likely to be seen as positive.

Even if you don’t list the actual references, it can be useful to indicate that references will be provided upon request, either on your résumé or in the cover letter. This way you show that you have someone who is willing to be your reference, which is always a plus. Also, make sure that if you do include include named references with contact details, that you have talked to them beforehand and that they are ready to be contacted by potential employers.

The Cover Letter

As the résumé is meant to get you an interview, the cover letter is meant to get your résumé read. If you are sending your résumé in response to an advertised job opening, always include a cover letter. Including a cover letter is also recommended when sending a general application or offering your services without anyone actually requesting them. In fact, I can’t think of a single situation where not including a cover letter would be a good idea. So, to summarize: always include a cover letter with your résumé.

The cover letter should contain information about why you are sending your résumé and what job you are applying for. Remember, the people receiving your letter are busy, so keep in mind that sending a long cover letter is almost a certain guarantee that it will not be read and your résumé ignored. I can’t think of a single reason why a cover letter would ever need to be longer than a few paragraphs, so keep your cover letter as short as possible.

For example, there is no reason to write about how talented you are or how eager you are to start working at your potential employer’s company. They already know you are interested in the job by the fact that you applied, and the résumé will show your skills and experience. That being said, the cover letter is a good place to put a few sentences about your current job/study situation and why you are applying. If you are sending a general résumé with your application, the cover letter can also be useful for highlighting skills and experience that is particularly relevant for the position you are applying to. In short, the cover letter itself should be the job application, while the résumé should be the document convincing your future employer that you are the right person for the job.

If you are in doubt whether you should include something in the résumé or put it in the cover letter, I would recommend putting it in the résumé. The main reason for this is the simple fact that whoever is reviewing your résumé may never see your cover letter. It’s quite common that the person doing the initial screening—to pick out which résumés should be considered for further review—is not the same person who will do the second screening, and there is no guarantee that your cover letter will be passed along to the next step (even if both steps are done by the same person).

A common example of this is when a middle manager performs the initial screening of potential candidates and distributes their résumés to other technical personnel for a more in-depth analysis of skills and experience. There is also a chance that your résumé will be considered for other positions than the one you applied to—either immediately or at a later time—in which case the initial cover letter may no longer be considered relevant.

Common Pitfalls

There are many common pitfalls to writing and sending out résumés and job applications. I won’t be able to cover them all in depth here, but here is a short summary of what you should do to avoid some of the major ones:

  • Check your spelling and grammar. It’s amazing how many people seem to neglect this. I have seen applications from higly educated and well experienced people who did not appear to care much about their spelling or grammar. You may be lucky and have your application read by someone who will not notice or who does not care, but that’s not a chance I recommend you take. Since finding your own errors can be quite hard, it’s usually a good idea to have someone read through both your résumé and cover letter before sending it.

  • Make it clear what position you are applying for. This is preferably done by writing something like “Application for <position>” or “Job application: <position>” in the subject of your e-mail. Again, it’s amazing how many people actually forget this. It’s quite common for companies to use the same e-mail address for many job openings, and the person reading the e-mail may very well not be qualified (or have the time) to guess which position you applied for, so make sure there is no doubt.

  • Check for copy/paste errors. Sending out multiple applications at the same time or using a previous application as a base for a new one is all good, but please, do remember to check that you send it to the correct address and provide the correct company name in the cover letter. Copy/paste errors are usually obvious to the receiver, and it sends a signal of sloppiness, which you are better to avoid.

  • Use a standard file format for your résumé. What is considered standard may vary, but usually PDF is the best choice. Word or HTML format may also be accepted, but if in doubt, use PDF. Sometimes the employer will specify which format they want the files in, in which case you should of course use whatever format they request. Don’t try to embed the résumé in your e-mail. It may look good on your screen, but you have no idea what it will look like for others. Also, it makes it harder to distribute the résumés separately.

  • Remember to include your résumé. It sounds stupid, I know, but it still happens, so make sure to double-check that attachment before hitting “send”. It doesn’t look good when you forget.

  • Do not send your cover letter as an attachment. When sending an application via e-mail there is no reason whatsoever why you should not make the cover letter a part of the e-mail. Sending an extra attachment just creates more work for the receiver, and thus reduces the chance of your letter ever being read.

Related links:

Notes:

  1. The recommendations are based on my own experience and preferences after reading hundreds of résumés over the years, and also writing a few of my own. Of course, I can’t guarantee that whoever is reading your résumé feels the same way as me, but judging from the feedback I have received on my own résumés and advice given to others, I feel safe saying that at least someone out there agrees with me.
  2. Note that I do not distinguish between a résumé and a curriculum vitae (CV). Some industries and academic institutions may have specific requirements for the layout and presentation of your résumé/CV, but if you are qualified to apply to either, you are probably already aware of this. Unless you are applying to a very conservative company or an academic position, the difference is not likely to matter, and the format described here is probably what you want.

As a programmer I spend a significant amount of my time punching keys on a keyboard while writing code, and even documentation. Over the years I have also accumulated a wide variety of shortcut key combinations that I use for everyday tasks. Because of this, a keyboard’s layout and physical design is very important to me. In fact, I’m so dependent on a decent keyboard that I bring my own keyboard to work.

Although programming and writing in general is possible with almost any input device, I prefer my keyboards to have certain qualities:

  • It should have the standard 104/105 key layout. If the keyboard provides additional keys, they should not be located in places where any of the standard keys normally are. Manufacturers not following this simple rule is especially annoying for people like me, who use keyboard shortcuts from muscle memory without conscious effort. For example, I once had a keyboard with a “power off” button in the Pause/Break location. After accidentally shutting down Windows several times when trying to access the System Properties dialog (Win+Break), I removed the offending keys permanently.

  • The keys should be somewhat durable. I don’t require the stamina of a Model M, but the keys shouldn’t fall off during the first week either.

  • When the keys do fall off, they should be possible to put back on. This is useful for fixing stuck keys or cleaning the keyboard.

  • The keys should be fast and agile. When I press a key it should respond immediately, and when released it should pop right back into place. I’m not a fan of the “machine gun” sound of buckling springs, but the keys must feel “real”.

  • It must be able to keep up with my typing speed. I find this especially annoying with many RF-based wireless keyboards, as they don’t respond fast enough. As a minimum it should be able to cope with the typematic rate settings of shortest repeat delay and fastest repeat rate.

  • It should be as slim and minimalistic as possible. I’m not fond of extra stuff like embedded palm wrists and other “ergonomic improvements”. I want the keyboard to take up as little space on my desk as possible.

Of course, these are only my personal preferences. What works for me may not work for you, but if you are looking for a decent keyboard for programming or extensive writing, here are some of my recommendations:

So, how important is your keyboard? Are you comfortable typing on anything from a Happy Hacking to a Microsoft Natural, or do you have some special preferences?

Guns of the Patriots

I am not easily impressed by the technical aspects of graphics in computer games, but every few years a game comes along that really blows me away. In 1993 it was Doom, in 1995 it was Descent, in 1996 it was Quake, in 1999 it was Quake 3, in 2004 it was Doom 3 (and Far Cry, but mostly for the AI). In 2008 it was Metal Gear Solid 4.

It may sound harsh to say I’m not impressed by the technology used in games—because many do have great graphics—but since game developers are limited by the hardware currently available on the mass market, they usually can not use the latest rendering techniques right away. They have to wait until the players have the required hardware. Because of this, new visual effects are often seen in white papers and technical demos years before they appear in mainstream games.

Even if a few games do use the latest technology available when released, they will often be alone to do so for a long of time, and the number of players able to take advantage of the new features will be limited. For example, Age of Conan has been developed with DirectX 10 features, but they were not enabled when the game was released. And even when the game is updated, it will only benefit players who are running Windows Vista with the latest graphics hardware.

Maybe I have not been paying attention to the gaming scene the past few years, but Metal Gear Solid 4 caught me totally off guard. I did not expect to see so many advanced rendering techniques in one place at the same time. They were using all the neat tricks I had been waiting for since the introduction of pixel shader 2.0, and they were using them well. I knew the PlayStation 3 was powerful, but the previous games I had played apparently used very little of that power.

I think it’s very exciting that this kind of graphics power is now finally available to mainstream games, because it allows much greater creative flexibility than before. Techniques such as high dynamic range rendering, out of focus blurring, reduced depth of field and full screen filters—previously only possible in movies, photography and pre-rendered animations—can now be used extensively in computer games, taking us one step closer to the interactive movie.

Here’s some of the things I found especially fascinating in Metal Gear Solid 4:

  • The in-game engine is used for rendering all non-interactive scenes. This improves the feeling of the interactive movie concept by blurring the lines between interactive and non-interactive content. For example, if you decide to put on a mask right before a cutscene, the mask will stay on during the entire scene. Sometimes this rule is broken by the script (i.e. the character will switch to a certain weapon for a specific scene), but it still adds a nice touch to the game.

  • When you turn the camera around fast, the screen gets blurred, just like it would if you were using a real camera.

  • When a car drives past the camera in high speed while it’s raining, water drops will hit the camera. In the same way, if you are in the middle of a building falling apart, dust and sand will cover the camera lens. The effect is also used with blood and snow in various scenes around the game. Although some people don’t like this effect—because it breaks the illusion by revealing the presence of a camera—I think it’s rather cool. It gives a sort of documentary, “fly on the wall”, feeling to the scene.

  • When people talk in cutscenes, the camera shifts focus depending on who’s talking. In fact, this is so common in the movies, many people may not even notice it on a conscious level. However, it does make the scene appear more realistic.

  • Very good use of high dynamic range rendering and pixel shaders for lighting and other effects. For example, when you encounter a helicopter, a pixel shader is applied to distort the image in the same way heat would affect the air around a real engine.

  • Impressive texture and model detail. This is especially noticeable during cutscenes, when you can literally read the labels on people’s clothing and see their hair and clothes move as they walk around.

  • Extensive use of well-known Hollywood movie techniques, such as color tinting, camera shake, panning, zooming, slow motion, selective focus, reduced depth of field and ambient lighting. Some are more subtle than others, and some may even be considered clichés, but I think they add great value to the interactive movie concept.

  • Realistic physics and animation. It’s as if you’re watching a real-time rendering of a Pixar movie.

None of these things are unique in themselves. In fact, most, if not all, have been seen in games before. What makes Metal Gear Solid 4 stand out is how they use all the techniques in the same game, at the same time! It’s also showing that they spent a lot of time (and money) on directing the game as if it was a movie, with, in my opinion, great success.

I am looking forward to more of this kind of gamemaking in the upcoming titles Rage and Mirror’s Edge. Things can only get better after this.

Related Links:

Some of you may wonder, what happened to WinCue? The web site has not been updated for over four years, and there has been no activity whatsoever on the SourceForge project.

I recently received an e-mail from a user who wanted to report a bug. Here’s my reply:

Date: Thu, 10 Apr 2008 11:16:27 +0200
From: “Anders Sandvig” <anders@wincue.org>
To: …
Subject: Re: WinCue bug

Sorry about the late reply, I don’t check this e-mail address as often as I should.

Thank you for your interest in WinCue. It’s great for me to see that people still use the plug-in, even after all these years. I feel a bit bad about “abandoning” the project, but my time has been limited, and I guess I have lacked the motivation to pick it up again. Personally I’m not very pleased with the direction that Winamp has taken, so I have been looking for other solutions.

I still think the core idea of WinCue is relevant, because even now that every media player on the market has a built-in media library with searching capabilities, I have yet to find a player that is as easy to use as the WinCue library. That is of course just my personal opinion, but I happen to know that there are a few other people out there who think the same.

Anyway, because of this I started thinking about creating a new media player with the WinCue media library sort of integrated. The plan was to make a general media library implementation with searching functionality and add that to an existing player source with a nice GUI on top. I even started implementing the new library for Wincue2 (the source code for the library in the new player and Wincue2 would be the same), but then I sort of stopped working on it due to lack of time.

I haven’t decided if I will continue with the Wincue2 project, but if people (like you) request changes to the existing 1.40 version, I might be able to fix that in much shorter time.

So, I guess my answer to your question is that I don’t really know what will happen in the future, but I will look into the possibility of releasing an updated version of WinCue 1.40.

Anders

As explained in the e-mail, I feel a bit bad about abandoning the project. Now, this happened for several reasons, the two major ones being lack of time and interest. Up until now I was also under the impression that the previous user base of WinCue was long gone, and had moved on to better software for managing their musical experience. When I finally tok the time to go through my web site statistics, I was a bit shocked to see that www.wincue.org still has thousands of visitors every month. Even in April 2008, WinCue 1.40 had more than thousand downloads. As outdated as I feel the current version is, the numbers make me suspect that there are still people out there who use Winamp and my plug-in.

Again, I must apoligize for staying out of reach for so long. The site forum was hacked years ago, and I never bothered to fix it. I hardly ever checked my wincue.org e-mail, and the few times I did, I rarely took the time to write you back.

So, the question is now, what will be the future of WinCue? Should I pick up the project again, and if I do, should I fix bugs in the old version of rewrite the entire thing from scratch? Is Winamp even worth using these days? As I mention in the e-mail I have also thought about writing a new media player alltogether, but I realize this might be a huge and time-consuming project, so any suggestions are welcome.