Slashdot Mirror


CV Tips for Software Developers?

drylight asks: "When writing a CV, what do people find to be an effective format that gets possible employer's attention and/or the desired job? Is Keeping things short, preferable or will two or more pages be acceptable? Is a complete work history desired, or would a list of applications and projects that you've been involved in a better idea? Any links to online examples of good CVs would be greatly appreciated. What are some other tips on how to get someone's attention when applying for a job?"

2 of 88 comments (clear)

  1. Focus on achievements not tools by DamienMcKenna · · Score: 4, Insightful

    Focus on the achievements you've made, not strictly the tools used. For example, don't tell them that you wrote a 1000 line perl script using bazillions of modules, rather tell them that you fixed a problem the company had for years which boosted sales/productivity/profits using a perl script you wrote. You can be trained in tools, life experience and achievements are what set you apart from other people.

    Damien

  2. Optimize, optimize, optimize! by Chemisor · · Score: 4, Funny

    What programmer can resist overoptimization? Here it goes:

    > Is Keeping things short preferable, or will two or more pages be acceptable?

    The most obvious error is the extra capitalization of Keeping. After fixing that simple bug:

    > Is keeping things short preferable, or will two or more pages be acceptable?

    Know your API. The english language has a wonderful word for "two or more" that ensures you don't have too many "or"s. This also removes the need for a comma:

    > Is keeping things short preferable or will several pages be acceptable?

    Making it obvious that the advice is for "you" saves the reader a few brain cycles:

    > Should I keep things short or in several pages?

    If the first part is true, then the second part is necessarily false. This useful fact allows further contraction and removes a syntax ambiguity between "things" and "pages" that helps brain compiler writers keep their parser simple:

    > Should I keep things short?

    If you keep "things" short, some people may want to reuse the question for other "things":

    > Should things be short?

    There. Only 23 characters instead of the original 76. This 70% reduction in size will save brain space and processing power that could be used to write another resume.