7 Debugging your future

It’s all very well designing your future but now you need to actually engineer it by building and testing. An obvious place to start is with your CV, because that’s where most people get going. How can you create a bug-free CV, résumé or completed application form? How can you support applications with a strong personal statement or covering letter? These documents are crucial part of your future so how can you debug them? 🐛

Is that a bug or a feature in your CV? To stand a chance of being invited to interview, you’ll need to identify and fix any bugs in your written applications. If you don’t, your application risks being sucked into a black hole and will never be seen again. Features not bugs picture by Visual Thinkery is licensed under CC-BY-ND

Figure 7.1: Is that a bug or a feature in your CV? To stand a chance of being invited to interview, you’ll need to identify and fix any bugs in your written applications. If you don’t, your application risks being sucked into a black hole and will never be seen again. Features not bugs picture by Visual Thinkery is licensed under CC-BY-ND

7.1 What you will learn

By the end of this chapter you will be able to

  • Structure and style the content of your CV and résumé appropriately
  • Describe your story5 of your relevant experience, projects and education etc
  • Identify and fix bugs in CV’s by:
    • Constructively criticising other people’s CVs
    • Asking for, listening to, and acting on constructive criticism of your own CV
  • Quantify and provide evidence for any claims you make you on your CV

7.2 Beware of the black hole

Before we get started, let’s consider some advice from software engineer Gayle Laakmann McDowell. Gayle is an experienced software engineer who has worked at the biggest technology employers in the world, Apple, Microsoft and Google. She’s also authored a cracking series of books on technology careers, particularly Cracking the Coding Interview (McDowell 2015) which we’ll discusses in chapter 10. Gayle refers to the employer “black hole” described in figure 7.2.

Beware of what software engineer Gayle Laakmaan McDowell calls the employer “Black Hole,” especially if you’re applying to large employers. “Getting through the doors, unfortunately, seems insurmountable. Hoards of candidates submit résumés each year, with only a small fraction getting an interview. The online application system – or, as it’s more appropriately nicknamed, The Black Hole, – is littered with so many résumés that even a top candidate would struggle to stand out.” (McDowell 2011, 2014) Laakmann portrait by Gayle Laakmaan is licensed CC BY 4.0 via Wikimedia Commons w.wiki/wiu adapted using the Wikipedia app

Figure 7.2: Beware of what software engineer Gayle Laakmaan McDowell calls the employer “Black Hole,” especially if you’re applying to large employers. “Getting through the doors, unfortunately, seems insurmountable. Hoards of candidates submit résumés each year, with only a small fraction getting an interview. The online application system – or, as it’s more appropriately nicknamed, The Black Hole, – is littered with so many résumés that even a top candidate would struggle to stand out.” (McDowell 2011, 2014) Laakmann portrait by Gayle Laakmaan is licensed CC BY 4.0 via Wikimedia Commons w.wiki/wiu adapted using the Wikipedia app

If you’re applying to big employers, you’ll need to create a CV that is good enough to stand out before it disappears over the event horizon and into the employment black hole. It needs to be good enough to persuade an employer to invite you to an interview. You can start with an employer-agnostic CV but you may need to come back and revisit the issues in this chapter once you have identified some target employers, so that you can customise and tailor your CV and written applications.

7.3 The CV is dead, long live the CV!

Résumés and CV’s have reigned supreme in kingdom of employment and recruitment for many years but their demise has often been predicted, see figure 7.3.

The seemingly contradictory phrase the king is dead, long live the king simultaneously announces the death of the previous monarch and the accession of a new one. Likewise, the death of the CV (and résumé) has long been hailed but it keeps coming back to reign again. The CV is dead, long live the CV! The résumé is dead, long live the résumé! Public domain image of a painting of Charles VII of France by Jean Fouquet on Wikimedia Commons w.wiki/3e3K adapted using the Wikipedia app

Figure 7.3: The seemingly contradictory phrase the king is dead, long live the king simultaneously announces the death of the previous monarch and the accession of a new one. Likewise, the death of the CV (and résumé) has long been hailed but it keeps coming back to reign again. The CV is dead, long live the CV! The résumé is dead, long live the résumé! Public domain image of a painting of Charles VII of France by Jean Fouquet on Wikimedia Commons w.wiki/3e3K adapted using the Wikipedia app

While it is true that some employers don’t accept CVs or favour online application forms, it is still worth writing one because:

  • Your CV provides a record for you of relevant things you’ve done
  • Your CV enables you to get your story straight, What’s your story, coding glory? see section 2.2
  • Your CV forces you to articulate who you are and what you want, see chapter 2
  • Some employers will still ask you for one, see section 7.7.6 and figure 7.3
  • Your CV helps you script and practice your “lines” for interviews, see chapter 10

Even if an employer never asks you for your CV, you’ll frequently want to use the content of your CV in applications and interviews. So this chapter looks at how you can debug your written applications, whatever the mechanism is for submitting them.

7.4 It’s not bug, it’s a feature

It’s an age old trope in Computer Science that engineers use to cover their mistakes, passing off their accidental bugs as deliberate features of their work, see 7.4.

Do you have software bugs or undocumented features on your CV or résumé? Although tolerated in software, bugs in your CV, résumé and written applications can be fatal. Picture of gold-dust weevil Hypomeces squamosus by Basile Morin is licensed CC BY SA via Wikimedia Commons w.wiki/3E62 adapted using the Wikipedia app

Figure 7.4: Do you have software bugs or undocumented features on your CV or résumé? Although tolerated in software, bugs in your CV, résumé and written applications can be fatal. Picture of gold-dust weevil Hypomeces squamosus by Basile Morin is licensed CC BY SA via Wikimedia Commons w.wiki/3E62 adapted using the Wikipedia app

Nobody likes buggy software, but unfortunately we routinely have to tolerate badly-designed, low quality, bug-ridden software in our everyday lives. (Mann 2002; Charette 2005)

In contrast, buggy CVs are rarely tolerated, they will usually end up in the bin. Even a tiny defect, like an innocent typo, can be fetal fatal. Most employers (particularly large and well known ones) have to triage hundreds or even thousands of CV’s for any given vacancy. This means they are looking for reasons to REJECT your CV, rather than ACCEPT it, because that’s a sensible strategy for shortlisting from a huge pool of candidates for interview. A buggy CV, application and covering letter could ruin your chances of being invited to an interview, see chapter 10.

Like writing software, the challenging part of writing a CV isn’t the creation but in the debugging. Can you identify and fix the bugs before they are fatal?

⚠️ Coding Caution ⚠️

If you ask three people what they think of your CV, you will get three different and probably contradictory opinions. CV’s are very subjective and very personal. The advice in this chapter is based on common sense, experience and ongoing conversations with employers. What makes a good CV will depend on the personal preferences and prejudices of your reader. So, this chapter just describes some general debugging guidelines, rather than rigid rules.

While referring to this guide, remember that:

  • The main purpose of your CV is to get an interview, not a job. Your CV should catch attention and provide talking points for an interview
  • Your CV will be assessed in seconds, rather than minutes so brevity really is key
  • Bullet points with verbs first (see section 7.7.4) will:

You’re not trying to tell your whole life story from section 2.2 but to distill the essentials into several short stories which can be summarised into a handful of bullets or sentences. It’s a bit like the blurb or synopsis on the back of novel, can you entice the reader into wanting to find out more?

7.5 Is it a bug or a feature?

Wherever criticism of your CV comes from, don’t take it personally - it is probably one of the first you have written. Think of your current CV as an alpha or beta version that you continuously test, release and redeploy. There are many chances to debug and improve your CV during your study but before potential employers read it. The aim of this chapter is to help you improve your CV, whatever stage you are at. Employers often grumble that Computer Science graduates lack written communication skills. Written applications and CV’s are a common example of this.

  1. EDUCATION: Is your year of graduation, degree program, University and expected (or achieved) degree classification clear? Have you mentioned things you are studying now, not just courses you have finished? See section 7.6.2
  2. STYLE: Does it look good, decent layout, appropriate use of LaTeX or Word or whatever? Are there any spelling mistakes, typos and grammar? Don’t just rely on a spellchecker, some typos can only be spitted spotted by a human reader
  3. LENGTH: Does it fit comfortably on (ideally) one page (for a Résumé) or two pages (for a CV)? See section 7.7.3
  4. STRUCTURE: Is the structure sensible? Is it in reverse chronological order? Most important (usually recent) things first? Not too many sections or anything missing? See section 7.6
  5. VERBS FIRST: Have you talked about what you have actually done using prominent verbs, rather than just what you think you know? Avoid long sections of prose, see section 7.7.4
  6. RESULTS: Have you also demonstrated and quantified the outcomes of your actions where possible, see Context, Action, Result & Evidence (CARE) in section 7.7.2
  7. SEE ALSO: This is just a quick checklist, see the longer CV checklist in section 7.9

7.6 Structure your CV

How you structure your CV will depend on who you are and what your story is. Recruiters at Google suggest four or five sections, that follow a header section. Before we look at those, lets look at some general points about CVs, watch the videos shown in Figure 7.5.

Recruiters at Google, Jeremy Ong and Lizi Lopez outline some tips and advice for creating your résumé. (Ong and Lopez 2019) The image in this figure is a screenshot, you can watch the eight minute résumé tips video at youtu.be/BYUy1yvjHxE.

Figure 7.5: Recruiters at Google, Jeremy Ong and Lizi Lopez outline some tips and advice for creating your résumé. (Ong and Lopez 2019) The image in this figure is a screenshot, you can watch the eight minute résumé tips video at youtu.be/BYUy1yvjHxE.

As Jonathan Black, director of the careers service at the University of Oxford has pointed out, (Black 2019) a key part of your story that you want to communicate in your CV is that you :

  1. take responsibility
  2. achieve things
  3. are nice to have around

How can you demonstrate this? Watch the short video in Figure 7.6.

Jonathan Black, head of the careers service at the University of Oxford, explains how to create a top notch CV by replacing meaningless assertions with meaningful evidence. (Black 2019) The image in this figure is a screenshot, you can watch the 11 minute video on creating a top notch CV at youtu.be/yjdvCHWVtE4.

Figure 7.6: Jonathan Black, head of the careers service at the University of Oxford, explains how to create a top notch CV by replacing meaningless assertions with meaningful evidence. (Black 2019) The image in this figure is a screenshot, you can watch the 11 minute video on creating a top notch CV at youtu.be/yjdvCHWVtE4.

Quantify and provide evidence of any claims you make. This can turn meaningless assertions described in figure 7.6 into meaningful evidence. So for example:

* Achieved excellent results

…is a bit vague, what were the results exactly, can you measure them somehow? Or at least describe them?

* Worked in a team

So you worked in a team? Worked is vague. What was your role and contribution exactly? How long did the project last? How many people were on your team? What was the result of your action? What’s the story?

7.6.1 Your header

The first thing in your CV is the header, a simple section giving your name, email, phone number and any links shown in the CV in Figure 7.7 for Alan Turing. That’s it!

Keep the header of your CV simple. Just your name, email, phone number and any relevant links are all you really need. Any additional information risks wasting valuable space and distracting your reader.

Figure 7.7: Keep the header of your CV simple. Just your name, email, phone number and any relevant links are all you really need. Any additional information risks wasting valuable space and distracting your reader.

Your header doesn’t need to include any more information than your name, email, phone and any links. This means your birth date, marital status, photo6 and home address aren’t relevant and you don’t need to give multiple phone numbers or emails either, just one of each will do. If an employer wants to invite you to an interview, they’ll get in touch by email, phone (or possibly LinkedIn, github etc) so other contact details are irrelevant at this point. After your header I suggest you have about five sections that cover some or all of the following:

  1. 🎓 Education: the formal stuff
  2. 💰 Experience: paid work
  3. 💪 Projects: personal, social, side or University projects
  4. 🏆 Leadership and awards
  5. ❓ Optional section

Let’s look at each of these sections in turn:

7.6.2 Your education

Unless you have significant amount of experience, the education section of your CV is likely to be the first real section, after the header. Your education section needs to strike a balance between:

  • Describing in enough detail what you’ve studied and any projects you’ve completed at University as part of your formal education
  • Keeping it short and sweet and avoiding getting bogged down in the details.

You’ve invested a significant amount of time and money in getting your degree. At this stage, your degree justifies more description than a terse one line BSc Computer Science. You’ll need to:

  • say more than Pen Tester and Rick Urshion, who haven’t said enough about their University education
  • say less than Mike Rokernel, who has given way too much information on his degree.

You don’t need to name every single module and give a mark for each. Neither do you need to give your result to FOUR or FIVE significant figures: 71.587%7). Two significant figures will do just fine: 72% (first class). You might like to pick out relevant modules, or the ones you got most out of. Employers like Google encourage applicants to emphasise courses on data structures and algorithms, but you’ll need to tailor your description to the role and be brief. On a one page CV, you might only have two or three lines to describe your higher education.

7.6.3 Your experience

Experience is where you can talk about any paid or voluntary work experience you have. Don’t discount the value of casual labour, such as working in retail or hospitality, these demonstrate your work ethic and ability to deal with customers, often under pressure. You are more than just a techie, so anywhere you’ve worked in a team is experience worth mentioning, even if that team was just two people. Two people is still a team.

Are you experienced? What have you done outside of your formal academic education? Experience sketch by Visual Thinkery is licensed under CC-BY-ND

Figure 7.8: Are you experienced? What have you done outside of your formal academic education? Experience sketch by Visual Thinkery is licensed under CC-BY-ND

If you don’t have much experience, don’t worry, there are plenty of opportunities to get some. For details, see chapter 5 experiencing your future.

7.6.4 Your projects

The Projects section of your CV is a where you can describe all other things you get up to. These might include:

  • personal side projects
  • social responsibility projects
  • open source projects
  • entrepreneurial projects
  • University projects

They will most likely be unpaid because paid work fits better under the heading experience, see section 7.6.3. Perhaps you’ve completed some courses outside of your education such as a massive open online course (MOOC) or similar. Hackathons and competitions, fit well here too. (Fogarty 2015) You don’t need to have won any prizes or awards, although be sure to mention them if you have. Participating in hackathons and competitions clearly shows the reader that you enjoy learning new things. Demonstrating an appetite for new knowledge and skills will make your application stand out. If you’re looking for some inspiration for side projects, Dani Stefanovic’s build-your-own-x repository is a good starting point. Building and creating new things is a great way to understand them, just ask Richard Feynman shown in 7.9. One way of doing this is with open source projects which we describe in section 5.3.3.

Physicist Richard Feynman once chalked “What I cannot create, I do not understand” on his blackboard at the California Institute of Technology while teaching the The Feynman Lectures on Physics. (Way 2017) Creating software and hardware in personal side projects is a great way to build new understanding and help your CV stand out see github.com/danistefanovic/build-your-own-x. Public domain image of Richard Feyman by The Nobel Foundation on Wikimedia Commons w.wiki/3Xoy adapted using the Wikipedia app

Figure 7.9: Physicist Richard Feynman once chalked “What I cannot create, I do not understand” on his blackboard at the California Institute of Technology while teaching the The Feynman Lectures on Physics. (Way 2017) Creating software and hardware in personal side projects is a great way to build new understanding and help your CV stand out see github.com/danistefanovic/build-your-own-x. Public domain image of Richard Feyman by The Nobel Foundation on Wikimedia Commons w.wiki/3Xoy adapted using the Wikipedia app

Any longer projects you’ve done at University are worth mentioning. Your projects are important because they differentiate you from everyone else in your year group. Try to be more descriptive than this:

* First year team project

or perhaps

* Second year team project

or even just

* Final year project

By themselves, those project names are pretty opaque. They are OK for giving the context of your story but don’t give the reader much else to go on. What was the story (the context, action, result and evidence (CARE) we described in section 7.7.2) of those projects? How many people were in your team? How long did you collaborate for? What did you build? What was it called? What did it do? What roles and responsibilities did you have in the team? Was their conflict in the team? How did you resolve it? How did you motivate the free-riders in the team to contribute? This is all excellent CV fodder, see 7.10

Perhaps you managed to turn a project around when things were not going very well (pear-shaped)? Perhaps you’ve learned from painful mistakes you previously made? This is all great fodder (content) for your CV because mistakes can be good, see section 14.5, as long as you don’t repeat them. CV fodder sketch by Visual Thinkery is licensed under CC-BY-ND

Figure 7.10: Perhaps you managed to turn a project around when things were not going very well (pear-shaped)? Perhaps you’ve learned from painful mistakes you previously made? This is all great fodder (content) for your CV because mistakes can be good, see section 14.5, as long as you don’t repeat them. CV fodder sketch by Visual Thinkery is licensed under CC-BY-ND

It’s often better to describe what YOU did before you describe what the software, hardware or project did. Your reader is likely to be more interested in the former than the latter. Let’s imagine you’ve developed a piece of software called WidgetWasher. You might describe it like this:

* WidgetWasher is a web service that washes widgets
* Makes use of an HTTP API and secret keys
* Tested WidgetWasher on a range of different operating systems
* Collaborated with one other contributor over two days
* Designed and implemented an API

Instead, you could reverse the order to change the emphasis like this:

* Designed and implemented an API
* Collaborated with one other contributor over two days
* Tested WidgetWasher on a range of different operating systems
* Makes use of an HTTP API and secret keys
* WidgetWasher is a web service that washes widgets

The latter has all the same information, but by reversing the order, you’ve emphasised what you did, rather than what the software did.

7.6.5 Your leadership & awards

If you can demonstrate leadership, you may want to dedicate a whole separate section for it. This is also a good place to add any prizes you’ve won. If you’ve been granted any interesting awards or honours be sure to mention them. You’ll typically need a bit more than:

* Awarded scholarship / prize

Congratulations, but how many people were awarded that prize? How many applicants or entrants were there and what percentage were successful? Was it a regional, national or global award? How frequently is the award given? It is unlikely that your reader will have heard of the award unless it is widely known. So if you’re going to mention awards, give the context where you can.

7.6.6 Your optional extras

If you have anything else you want to highlight besides your education, experience, projects and awards you may still have room for one more optional extras section. Try to come up with a better name than Miscellaneous or Other highlights (which sound like dumping grounds). You might decide to have a dedicated skills section but see 7.6.7.

People often list hobbies and interests which can add a bit of colour to what can otherwise become quite a dull list of facts. However, it is debatable how many (if any) hobbies and interests you should list on your CV. For a one-pager you’re usually pushed for space and looking for things to edit out (rather than add in), so if you’re going to list hobbies, I’d stick to those that are relevant to the job or those that demonstrate particular transferrable or soft skills. Organising or participating in team sports is a good example of a relevant hobby as it demonstrates teamwork, commitment, reliability and so on. Other collaborative activities outside of sport will also provide evidence of your communication skills. (Cheary 2021)

The fact that you enjoy swimming, reading and hiking is a bit vague and not likely to be a factor in the decision to interview you. There’s nothing wrong with these pastimes but there’s not much point mentioning them on your CV unless you have, for example:

  • coached a swimming team
  • trained as a mountain leader
  • organised and hosted a book club

In this case, the way you have engaged with your hobbies demonstrates your communication and leadership skills. So in this context, your hobbies are worth talking about.

7.6.7 Your skills?

You may be tempted to dedicate a whole section on your CV to skills, particularly the technical ones. Maybe it makes you feel good listing them all in one place like a stamp collection. If you’re going to have a skills section, keep it short. Why? Let’s imagine, that like Rick Urshion, you include Python in a long list skills, with its own dedicated section. There are at least five problems with Rick’s not so skilful approach:

  1. No Context to give the reader an idea of where he’s developed or used his Python skills. Was it during his education, as a part of his work experience or his personal projects? We don’t know because he doesn’t say.
  2. No Actions or evidence to back up his claims of having skill with Python. So Rick claims he knows Python. So what? What did he do with those python skills? We don’t know because he hasn’t told us.
  3. No Results given for what the outcome of using the skills was. Did he save his employers some money? Did he make something more efficient? Did he learn some methodology? We will never know.
  4. No Evidence to support his claims. Perhaps he DOES have Python skills, perhaps he DOESN’T. Is he telling lies and peddling fake news (see section 8.3.4)? It’s difficult to tell.
  5. No C.A.R.E. There’s no story told for that skill, see figure 7.11. This makes for a very dull and boring read. Yawn. NEXT! 🥱
(What’s your Story) Morning Coding Glory? What is the Context, the Actions, the Results and the Evidence for the stories that you are trying to tell? Show your C.A.R.E. in storytelling. CC BY portrait of Noel Gallagher by alterna2.com on Wikimedia Commons w.wiki/3bimy adapted using the Wikipedia app

Figure 7.11: (What’s your Story) Morning Coding Glory? What is the Context, the Actions, the Results and the Evidence for the stories that you are trying to tell? Show your C.A.R.E. in storytelling. CC BY portrait of Noel Gallagher by alterna2.com on Wikimedia Commons w.wiki/3bimy adapted using the Wikipedia app

So, this doesn’t mean Rick shouldn’t mention his Python skills. Where he can, he needs to give us the context, action, result and evidence (C.A.R.E.) of his story described in section 7.7.2. This will make his Python story much more convincing and interesting to read. Showing a bit of C.A.R.E. will improve his chances of being invited to interview.

This applies to soft skills too, not just hard technical skills. Best to mention the context in which you’ve used any skills you mention on your CV. So, if you’re going to have a skill section:

  • keep it short (one or two lines maybe) but personally I’d avoid dedicating a whole section to it
  • stick to your strongest and most relevant skills that you are comfortable to answer questions on in your interview, rather than an exhaustive encyclopædic inventory
  • avoid listing mass marketed office products of Microsoft (e.g. Word etc) as a skill, they are not generally very interesting skill because everyone has them. They won’t set you apart much from your competition, so don’t waste valuable space talking about office unless you’ve done something interesting with them, like some advanced integration with other software. Cloud services are a slightly different matter, see section 11.4.1.

If you’re a computer scientist, you also have demonstrable “meta” skills like the ability to learn things quickly. You can also think logically, reason, problem solve, analyse, generalise, criticise, decompose and abstract - often to tight deadlines. These computational thinking skills are future-proof and will last longer than whatever technology happens to be fashionable right now. Employers are often more interested in these “meta” capabilities and your potential than in any specific technical skills you may or may not have.

7.7 Birds eye view

Having looked at the sections you’re likely to have, we’ll take a birds eye view of your whole CV. The issues in this section apply to the whole of your CV, rather than individual sections.

7.7.1 Your style

Making your CV look good can take ages, but a well presented CV will stand out. While its worth making an effort to style carefully and consistently, you need to be be wary of the huge time sink of typography.

Does your CV need a little work? The truth is your CV is never finished, you will be continuously developing, debugging and releasing it throughout your life. It’s such a crucial document because it will determine if you are interviewed, so its important to spend time getting it right. CV work sketch by Visual Thinkery is licensed under CC-BY-ND

Figure 7.12: Does your CV need a little work? The truth is your CV is never finished, you will be continuously developing, debugging and releasing it throughout your life. It’s such a crucial document because it will determine if you are interviewed, so its important to spend time getting it right. CV work sketch by Visual Thinkery is licensed under CC-BY-ND

Whatever your typographical style is, portable document format (PDF) is the safest way to deliver it. It’s called portable for a reason. While Microsoft Word is fine for editing, it is difficult to ensure that a Word document doesn’t get mangled by transmission via the web or email. PDF is much safer, you can be more confident that it will work well on a range of different operating systems and devices. Try opening a Word document on any smartphone or tablet and you’ll see what I mean. It helps if you can give the file a descriptive name so ada_lovelace.pdf is a better filename than my_cv.pdf.

It’s fine to author your CV in Microsoft Word, but you’ll want to save as PDF to make it more platform independent. LaTeX and overleaf can be used to create professional PDFs and have many templates, see Getting started with LaTeX (LaTeX4year1) if you’ve not used LaTeX before, or you need to refresh your memory. (Hull 2021a)

7.7.2 What’s your story, coding glory?

One way to structure descriptions of items within each section of your CV is to use Context, Action, Result and Evidence (C.A.R.E.) to tell your stories. This method can also be useful for structuring answers to interview questions, especially if you get nervous. So for example, rather than just listing Python as a skill, you should tell the reader more about the context in which you’ve used python, what you actually did with it and what the result was. You really need to spell it out.

  • CONTEXT: So you’ve used Python, but in what context? As part of your education? For a personal project? As a volunteer? In a competition?
  • ACTION: What did you do with Python? Did you use some particular library? Did you integrate or model something?
  • RESULT: What was the result and how can you measure it? You picked up some new skills? What was the impact? Perhaps you made something that was inefficient and awkward into something better, cheaper or faster? Some things are hard to measure but you should quantify results where you can.
  • EVIDENCE: Where evidence exists, you should point to it. It might be a certificate, a badge (see chapter 12) or the actual software itself

You don’t have to stick rigidly to the order C.A.R.E. as long as they appear somewhere. For example, recruiters at Google (see figure 7.5) advise candidates to describe their experience and projects using this simple pattern:

* Accomplished [X], as measured by [Y], by doing [Z]

Where accomplished is Result, measured by is Evidence and doing is the Action. So instead of just saying:

* Generated reports for end users

You could say:

* Generated daily reconciliation report for team by automating workflow of 8 different tasks

The latter is better because it is more specific, captures the result (accomplishment), by giving evidence (8 different tasks) and talks about the actions (the doing part). Choose the verbs you use carefully, see chapter 18 for examples.

7.7.3 Your length

How long should your CV be? Many people start with a two page CV, which is a sensible starting point shown in figure 7.13. It is also advisable to create a one page Résumé. (David 2017)

How long should your CV be? Should you write a two page European style CV or an American style résumé (one pager)? (Hull 2021b) The image in the figure is a screenshot, you can watch the five minute video on how long your CV should at youtu.be/0abDOKHS5T0.

Figure 7.13: How long should your CV be? Should you write a two page European style CV or an American style résumé (one pager)? (Hull 2021b) The image in the figure is a screenshot, you can watch the five minute video on how long your CV should at youtu.be/0abDOKHS5T0.

At this stage in your career you should be able to fit everything on to one page. However, it can be challenging and time consuming squeezing it all on, see figure 7.14.

I would have written a shorter letter, CV, Résumé but I did not have the time. This quote (or meme) is frequently attributed to Blaise Pascale’s Lettres provinciales (O’Toole 2012). Public domain image by Gallica on Wikimedia Commons w.wiki/3Uzn adapted using the Wikipedia app 🇫🇷

Figure 7.14: I would have written a shorter letter, CV, Résumé but I did not have the time. This quote (or meme) is frequently attributed to Blaise Pascale’s Lettres provinciales (O’Toole 2012). Public domain image by Gallica on Wikimedia Commons w.wiki/3Uzn adapted using the Wikipedia app 🇫🇷

It takes more time to write less. Writing a one page résumé is a valuable exercise, because it forces you to distill and edit out any filler or fluff, which you sometimes find on two page undergraduate or graduate CVs. It is much better to have a strong one-page résumé than a weaker two-page CV that is padded out with filler to make up the space, as described in the video in figure 7.13. Adding more features (pages and content) to your CV doesn’t necessarily make it better. Sometimes adding more features to your CV will make it worse, as shown in figure 7.15.

If it ain’t broke it doesn’t have enough features yet. Adding more features to software doesn’t necessarily make it better. Likewise, adding more pages and content to your CV or résumé won’t always improve it. It’s often better to be precise and concise, rather than bloated and potentially more buggy. An engineering state of mind by Visual Thinkery is licensed under CC-BY-ND, with help from Dilbert cartoonist Scott Adams

Figure 7.15: If it ain’t broke it doesn’t have enough features yet. Adding more features to software doesn’t necessarily make it better. Likewise, adding more pages and content to your CV or résumé won’t always improve it. It’s often better to be precise and concise, rather than bloated and potentially more buggy. An engineering state of mind by Visual Thinkery is licensed under CC-BY-ND, with help from Dilbert cartoonist Scott Adams

If you’re struggling to fit all the information onto a one page résumé, revisit each section and item carefully. Is there anything you can drop? Can you save a wasteful word here, or a lazy line there? Check for any spurious line breaks because every pixel counts. Don’t throw your two page CV away, it is still a good store of stuff you might want to add to customised one-page résumés.

7.7.4 Verbs first: lead with your actions

A simple but effective technique for emphasising what you have done, rather than just what you know, is to start the description of it with a verb. Employers don’t just want to know what you know, but what you have actually done. So, for example, instead of saying e.g.

* In my second year CS29328 software engineering module I used Java, Eclipse and JUnit to test and build an open source Massively Multiplayer Online Role-Playing Game (MMORPG)

you could say:

* Built and tested a large open-source codebase using Eclipse, Ant, JUnit and Jenkins”

followed by:

* Added and deployed new features to a Massively Multiplayer Online Role-Playing Game (MMORPG) in Java

The latter examples get to the point much quicker and avoid the problem of using I, me, my... too much which can sound self-centred and egotistical. Although your CV is all about you so it is natural to have a few personal pronouns in there, too many can look clumsy and give the wrong impression. Choose the verbs you use carefully, see chapter 18 for examples.

7.7.6 Robot proofing your CV

It’s a good idea get feedback from as many different sources as you can on your CV. By sources I don’t just mean humans, but also robots. Larger employers will use automated Application Tracking Systems (ATS) to log and trace your application. These “résumé robots” (if you like) are unlikely to have arms and legs like the one in Figure 7.17, but they will be looking for keywords and standard headings in your CV. You can get automated feedback from a range of different automated systems, though it is a good idea to remove any personal information like phone numbers and emails before using these free services. You might also want to check what the services privacy policy says about what they do with your personal data. Résumé robots include:

  • careerset.io, a free service provided by a UK based company, careerset Ltd.
  • resume.io, a free service provided by a Dutch company, Imkey BV
  • jobscan.co, a free service provided by an American company
Although they often struggle to get up the stairs, résumé robots are likely to play an important role in decisions made about if you are worth interviewing, especially if you’re applying to bigger companies. Make sure your CV is résumé robot friendly by feeding it through a robot . Machines by Visual Thinkery is licensed under CC-BY-ND

Figure 7.17: Although they often struggle to get up the stairs, résumé robots are likely to play an important role in decisions made about if you are worth interviewing, especially if you’re applying to bigger companies. Make sure your CV is résumé robot friendly by feeding it through a robot . Machines by Visual Thinkery is licensed under CC-BY-ND

Besides providing feedback on the content of your CV, using these systems can help address issues such as the use of tables or layout which may cause problems for some systems. For example, some systems ignore the second column of a two-column CV because they can’t identify it. Some things to check with automated CV screens:

7.7.7 Your references

You might be tempted to put your referees details on your résumé. Don’t bother because;

  • references waste valuable space. You can say much more interesting things about yourself than who you referees are
  • references aren’t needed in the early stages of a job application. They are typically taken up much later, when you’ve been offered or are about to be offered the job
  • references give personal information out. Do you really want to be giving personal details out to anyone that reads your CV? It could easily be misused.

It’s not even worth saying references available on request - that just wastes space as well and is implied information on every CV anyway.

7.8 Breakpoints

Let’s pause here. Insert a breakpoint in your code and slowly step through it so we can examine the current values of your variables and parameters.

* PAUSE ⏸️
* RESUME ▶️

7.9 Checklist: Big Bad Bugs

Here is a quick check-list for debugging your CV before you send it off to an employer:

  1. ✅ Does it fit comfortably on exactly one page (résumé) or two pages (CV)? Definitely not one-and-a-half pages or more than two? See section 7.7.3
  2. ✅ Does the style look good? Is it easy on the eye? Is there adequate whitespace, not too much (gappy) or too little (cramped)? See section 7.7.1
  3. ✅ Is your year of graduation, degree program, University and expected (or achieved) overall degree classification clear? See section 7.6.2
  4. ✅ Have you eaten your own dogfood (woof), see section 4.4.1? Is everything relevant? e.g. no swimming certificates from ten years ago?
  5. ✅ Have you spell-checked using both automatic and manual (proof-reading) techniques?
  6. ✅ Have you got a second opinion from a “résumé robot?” Is it robot proof? See section 7.7.6 🤖
  7. ✅ Have you added context using relevant hyperlinks that an interested reader can click on? See section 7.7.5
  8. ✅ Is it in reverse chronological order? Most recent things first. Can your timeline be easily scanned, e.g. all dates clear and left or right aligned for easy reading?
  9. ✅ Have you avoided using too many personal pronouns? I, me, my ... everywhere? See section 7.7.4
  10. ✅ Have you made it clear what you have actually done using prominent verbs? See chapter 18
  11. ✅ Have you given sufficient information on your education without going into too much detail? Have you mentioned courses you are studying now (or next semester)? See section 7.6.2
  12. ✅ Have you quantified and provided evidence of claims you make where you can? See section 7.6
  13. ✅ Is it balanced, including both technical and non-technical (softer) skills? See section 5.3.5
  14. ✅ Does it have a good, clear structure? Not too many headings, around five sections for a one-pager see section 7.6.1?
  15. ✅ Have you clearly distinguished between paid, unpaid and voluntary experience? Have you included all of your experience including casual work, see section 5.3.5?
  16. ✅ Has it been reviewed by other people? Do a CV swap with a critical friend (see figure 7.18) and score each others CV’s using this rubric. This is a bit like pair programming. According to Linus’s law “given enough eyeballs all bugs are shallow” (Raymond 1999) so the more people who give you feedback the better
  17. ✅ Have you reviewed other people’s CV’s? This will put you in the shoes of an employer or recruiter, thereby helping you to write a better CV yourself. See the examples in chapter 15
Showing your CV to somebody else is one of the best ways to debug it. You need to find a critical friend, somebody who won’t just tear it apart (hostile witness) or tell you it’s simply wonderful (uncritical lover) but tell you how to improve it, whatever state it is in. Critical friend by Visual Thinkery is licensed under CC-BY-ND

Figure 7.18: Showing your CV to somebody else is one of the best ways to debug it. You need to find a critical friend, somebody who won’t just tear it apart (hostile witness) or tell you it’s simply wonderful (uncritical lover) but tell you how to improve it, whatever state it is in. Critical friend by Visual Thinkery is licensed under CC-BY-ND

7.10 Covering letters & personal statements

Applications and CV’s are often accompanied by covering letters or include some kind of personal statement. Whereas a lot of your CV is essentially a bulleted list of facts and statements, a covering letter or personal statement gives you a chance to really demonstrate your fluent written communication skills in clear prose. If you’re going to have a personal statement or profile on your CV keep it short, unlike Mike Rokernel who waffles on for ages without providing any evidence. Usually this kind of information is better in your covering letter.

Let’s say you’re applying for a widget engineering position at Widget.com. There are three things you need to cover in approximately this order:

  1. Why them? Why are you applying to Widget.com
  2. Why that role? Widget.com employees have many roles and responsibilities, so what is it about widget engineering that attracts you?
  3. Why you? Why should they employ you? What makes you stand out from all the other widget engineering candidates? What is your Unique Selling Point (USP) or points?

7.10.1 Does anyone actually READ covering letters?

Some employers will read your covering letter very carefully, others less so. It’s not clear which employers will bother and which won’t.

Even if nobody reads your covering letter, it is still worth writing one because it forces you to rehearse standard interview questions shown above. See e.g. www.careers.manchester.ac.uk/applicationsinterviews/cl for further information. Think of it as practicing the lines of your elevator pitch.

7.11 Debugging summary

Too long, didn’t read (TL;DR)? Here’s a summary:

This chapter we’ve looked at how to debug your CV. It’s important to try and squash any of the bugs we’ve described here, before an employer see’s your CV. The checklist above in section 7.9 is a good place to start.