It’s all very well designing your future but now you need to actually engineer your future by building something. An obvious place to start is with your CV or résumé, because that’s where most people start testing their designs. Just like with code, the hardest part isn’t writing it but debugging and rewriting it, repeatedly. 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 a crucial part of your future so how can you debug them? 🕷
Your future is bright, your future needs debugging, so let’s start debugging your future.
By the end of this chapter you will be able to
- Structure and style the content of your two page CV and one page résumé appropriately13
- Articulate your story14 by providing convincing evidence of your
- Identify and fix bugs in CV’s by:
content(what you’ve done and who you are) and
presentation(how you style your CV)
- Constructively criticising other people’s CVs
- Asking for, listening to, and acting on constructive criticism of your own CV
- Quantify and provide convincing evidence for any claims you make you on your CV
- Identify gaps (mostly
contentbugs) in your own CV and how you might begin to fill them
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 some of the biggest technology employers in the world: Apple, Microsoft and Google. She has also authored a cracking series of books on technology careers, particularly Cracking the Coding Interview (McDowell 2015) which we’ll discuss in chapter 13. Gayle refers to the employer “black hole” described in figure 8.2.
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 an employers black hole, see section 11.4.10. Employer practices vary, but according to some estimates the person reading your CV will typically:
- Spend around 7 seconds (or less!) deciding if your CV is interesting enough to shortlist and read in a bit more depth. This is a pessimistic view, see the discussion by Andrew Fennell for a more complete story (Fennell 2022)
- Shortlist about 20% of the all CVs they get sent (Fennell 2022)
- Interview about 2% of the candidates on their shortlist (Fennell 2022)
So, the first thing your CV or résumé needs to do is:
- catch attention so it ends up in the lets read that a bit more pile.
Having passed the 7 second test, the second thing your CV or résumé needs to do is:
- 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.
Résumés and CV’s have reigned supreme in the kingdom of employment and recruitment for many years but their demise has often been predicted, see figure 8.3.
While it is true that some employers don’t accept CVs or favour online application forms or digital profiles, it is still worth writing a CV 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.2 (Gallagher 1995)
- 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 8.7.7 and figure 8.3
- Your CV helps you script and practice your “lines” for interviews, see chapter 13
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.
You can of course augment your CV with various public digital profiles such as LinkedIn, Github etc. A public digital profile can help employers find you, see section 11.3.3.
Wherever you’re putting information about yourself for potential employers, on a CV, Résumé, LinkedIn profile the same principles apply. See the checklist in section 8.9 and for specific advice on LinkedIn see:
An age old trope in Computer Science that engineers use to pass off their mistakes as deliberate features is the bug/feature distinction, see figure 8.4.
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. (Lerner 2022) Most employers (particularly large and well known ones) have to triage hundreds or even thousands of CV’s for any given vacancy. This means the person reading your CV is as likely to be looking for reasons to
REJECT your CV, than
ACCEPT it, because that’s a sensible strategy for shortlisting from a huge pool of candidates. A buggy CV, application and covering letter could ruin your chances of being invited to an interview, see chapter 13.
Like writing software, the challenging part of writing a CV isn’t the creation but in the debugging and subsequent re-writing. 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 readers. So, this chapter just describes some general debugging guidelines, rather than rigid rules.
It is good practice to triangulate responses from your readers. For example, if three different people point out the same bug in your CV you can be confident that it is a bug that needs fixing. The more friendly critics (see figure 8.22) who can give you constructive feedback on your CV before you send it to employers, the better it will get.
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 8.7.5) will:
- allow your reader to quickly skim, scan and scroll through your CV because employers don’t actually read CVs (Richards 2019b)
- highlight your key activities
- avoid long sections of flowery prose which the reader will very probably skip anyway. Instead, you can use your beautiful prose to demonstrate your excellent written communication skills on your covering letters or personal statements instead, see section 8.10
You’re not trying to tell your whole life story from section 2.2.2 but to distill the essentials into several short stories which can be summarised into a handful of bullets or sentences. Your CV should be punchy like the blurb or synopsis on the back of a novel, can you entice the reader into wanting to find out more (by inviting you to an interview)?
Just as you can’t edit a blank page, you can’t debug an unwritten CV either, see figure 8.5. Debugging and editing your CV can be time consuming but wherever criticism of your CV or résumé comes from, don’t take it personally - it is probably one of the first you have written.
It might help to think of first version of your CV as an alpha or beta version that you continuously test, release and redeploy. If it was an iPhone, its a first generation iPhone - with many future iterations to come! 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 about Computer Science graduates lacking good written communication skills. Written applications and CV’s are a common example of this. Here are some common bugs (or are they features?) to pay attention to on initial draughts of your CV:
- 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 8.6.2
- 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 8.6
NUMBERS: Have you quantified the context, action, results and evidence of the short stories on your CV where possible? See (
C.A.R.E.) in section 8.6.7
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 8.7.5
STYLE: Does it look good, with a decent layout with appropriate use of LaTeX or Word or whatever? (Hull 2023b) Are there any spelling mistakes, typos and grammar? Don’t just rely on a spellchecker, some errors will only be
spittedspotted by a human reader see section 8.7.8
- LENGTH: Does it fit comfortably on (ideally) one page (for a Résumé) or two pages (for a CV)? See section 8.7.4
- SEE ALSO: This is just a quick checklist to get you started, see the longer CV checklist in section 8.9
How you structure your CV and Résumé will depend on who you are and what your story is. Recruiters at Google suggest you have four or five sections, that follow a header section. Before we zoom in on those, let’s look at some broader points about CVs and Résumés. Start by watching the short video shown in figure 8.6.
As Jonathan Black, director of the careers service at the University of Oxford points out in figure 8.7, there are three key things you want to demonstrate in your CV:
- that you can take responsibility
- that you achieve things
- that you are good company (or at least a valued team member)
How will you demonstrate and provide evidence each of these traits?
Quantifying and providing evidence for any claims you make will create a much more convincing CV. Numbers can transform meaningless assertions described in figure 8.7 into meaningful evidence. So for example:
…is a bit vague, what were the results exactly, can you measure them somehow? Or at least describe them?
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 were the results of your actions? What’s the story, coding glory? (Gallagher 1995)
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 8.8 for Alan Turing. That’s it!
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, photo15 and home address aren’t relevant. 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 such as your postal address are an irrelevant distraction at this point. After your header I suggest you have around five sections. Technical recruiters at Google (see figure 8.6) suggest you have just five sections that cover some or all of the following:
Education: the formal stuff, see section 8.6.2
Experience: paid work, see section 8.6.3
Projects: personal, school, social, side or University projects see section 8.6.4
Leadership and awards: your trophy cabinet, see section 8.6.5
Optional: but don’t call it that, see section 8.6.6
Let’s look at each of these sections in turn:
Unless you have a significant amount of experience, the
Education section of your CV should be the first “real” section, after the header. Your education section is important, see figure 8.9, so your description of it needs to strike a balance between:
- Describing in enough detail what you’ve studied and any
Projects16 you’ve completed at University as part of your formal education
- Keeping it short and sweet by avoiding getting bogged down in tedious and irrelevant educational details that will be of little interest to your readers
You’ve invested a significant amount of time and money in getting your degree. At this stage, your degree justifies a longer description than a rather terse one line
BSc (Hons) 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, course code with a mark for each. Neither do you need to give your result to FOUR or FIVE significant figures:
71.587%17. Two significant figures will do just fine:
72% (first class). You might like to pick out relevant modules, or the ones you enjoyed most. 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 Résumé, you’ll probably only have two or three lines to summarise some of the modules you’ve studied at University. 🎓
You should include details of your high school education, after University so that it is in reverse chronological order. Start with last set of exams you sat before University, bearing in mind that some employers screen job candidates by UCAS Tariff points. (Administrator 2023; Accountant 2015) How far you go back will depend on how much space you have available, especially on a one pager. It is debateable how far back you should go, exams that you sat aged ~16 (like GCSE’s) aren’t always relevant now that you’re older. (Advisor 2020)
Experience is where you can talk about any paid or voluntary work experience you have. For paid work call it
EXPERIENCE rather than
WORK EXPERIENCE as the latter can imply work shadowing, see section 5.3. Work shadowing is valuable, but paid work is even better so you should make it clear if your experience was paid or not. 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 too, 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.
If you don’t have much experience, don’t worry, there are plenty of opportunities to get some more . For details, see chapter 5 experiencing your future.
Are you experienced? Whatever it is, make sure you add it to your
experience section. 💰
Projects section of your CV is where you can describe all your other activities. Your projects will include activities that you haven’t already described in your
Education or your paid
Experience section such as:
- personal side projects, see section 5.3.7
- social responsibility projects, not neccesarily technical, see section 5.3.6
- open source projects, see section 5.3.5
- entrepreneurial projects, your “side hustles” (if you have any)
- hackathons, olympiads and other competitive or collaborative events, see section 5.3.7
- University projects:
- these sometimes fit better in your
Educationsection, depending on how many non-Uni projects you have
- If you are publishing a group project, you will need permission from all of your team to make the code public
- Be careful publishing coursework. If someone copies your coursework, you will BOTH be guilty of academic malpractice because you have colluded in plagiarism.
- … but final year (“capstone”) projects are great as these will tend to be unique, distinguishing you from everybody else in your year group
- these sometimes fit better in your
Your projects will most likely be unpaid because paid work tends to fit better under the heading
experience, see section 8.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, the codecrafters-io/build-your-own-x repository is a good starting point alongside free-for.dev which lists software that has free tiers for developers to play with. Building and creating new things is a great way to understand them, just ask Richard Feynman shown in figure 8.11. What you cannot create you do not understand. Another great way to learn is to get involved with open source projects which we describe in section 5.3.5.
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:
or even just
By themselves, those project names are pretty opaque. They are OK for giving the context of your story but don’t tell the reader anything about what you did or what the software/hardware/project did. What was the story (the context, action, result and evidence (
CARE) we described in section 8.6.7) 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?
It’s often better to describe what YOU did before you describe what the software, hardware or project did. Your reader is much more likely to be 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:
Instead, you could reverse ↑↓ the order to change the emphasis like this:
The latter has all the same information, but by reversing the order, you’ve emphasised what you did, rather than what the software did. Much more interesting. 💪
If you can demonstrate leadership, you may want to dedicate a whole separate section to it. Experience of tutoring or mentoring other students, can serve as a good example through peer-assisted study schemes (like PASS) for example. Teaching is a different kind of leadership to running a small business or captaining a sports team, but it is leadership nonetheless. A
awards section is also a good place to add any prizes you’ve won, see figure 8.13
If you’ve been granted any interesting awards or honours be sure to mention them, because they provide evidence to the reader that a third party has endorsed you. Other people think you are good at something, and this says much more than you thinking you’re good at something. You’ll typically need a bit more than this:
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. You might talk about your ranking e.g.
Again, congratulations, but
third prize out of how many?
3/3? Not so impressive
3/3000? More impressive
Numbers can speak louder than words, so if you’re going to mention awards, quantify18 where you can so the reader can understand what the prize was for. YOU may well be intimately acquainted with the international flibbertigibbet competition but your reader probably won’t of heard of it, so give some context.
awards section might also include any courses you’ve done outside of the formal (compulsory) and university courses described in your
Education section19. Extra skills and knowledge you’ve picked up from Massive Open Online Courses (MOOCs) or any other credentials you’ve collected such as those described in sections 18.4.3 and 19.4, are worth mentioning. 🏆
If you have anything else you want to highlight besides your
Leadership and Awards you may still have room for one more optional section. Try to come up with a better names for this section than:
Other highlights and activities
You could opt to have a
hobbies and interests section 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 provides evidence of your teamwork, commitment, reliability etc, see figure 8.14. Other collaborative activities outside of sport will also demonstrate your communication skills. (Cheary 2021)
The fact that you enjoy
hiking is vague and pretty boring, making it unlikely to be a factor in the decision to invite you to interview. 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
- gained certification in a musical instrument
- organised, hosted and participated in a book club
- won some awards for your hobby, like a black belt or chess championship for example
- regularly participated in or organised competitive sports matches (for example)
In this case, the way you have engaged with your hobbies demonstrates your softer, communication and leadership skills. So in this context, your hobbies are worth talking about if you have any space left. However, if they are just hobbies that enable you to amuse yourself, you should probably leave them out as they are unlikely to be of interest to an employer. Sure, they add colour to your CV, but you’ve probably got more interesting and important things to say about who you are.
Of course, you might get lucky and your interviewer(s) could be intrigued by (or even share) your esoteric passion for Quidditch (say), but you can’t rely on it. So, I reckon if you’re going to mention hobbies and interests at all then …
- pick the unusual hobbies that make you unique
- describe the interests that add some colour and personality to your CV
- be specific, e.g.
reading japanese novels from 20th centurymight sound more interesting (and convincing) than just
- highlight any
actionsyou’ve taken, see chapter 10
… or just leave them out altogether. That option is up to you.❓
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 of skills, with its own dedicated section. There are at least five problems with Rick’s not so skilful approach:
- ❎ No
Contextto 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.
- ❎ No
Actionsto demonstrate what he’s done with his Python skills. So Rick claims he knows Python. So what? What did he use them for? We don’t know because he hasn’t told us.
- ❎ No
Resultsgiven 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.
- ❎ No
Evidenceto support his claims. Perhaps he DOES have Python skills, perhaps he DOESN’T. Is he telling lies and peddling fake news (see section 11.4.5)? It’s difficult to tell.
- ❎ No
C.A.R.E.There’s no story told for that skill, see figure 8.15. This makes for a very dull and boring read. Yawn. NEXT! 🥱
So, this doesn’t mean Rick shouldn’t mention his Python skills. Where he can, he needs to give us the
C.A.R.E.) of his story described in section 8.6.7. 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. It is often better to mention the context in which you’ve used the skills you mention on your CV. So, if you’re going to have a skills section:
- keep it short, no more than two or three lines on a one-page CV
- 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 vague metrics of skill like
advancedas these are very subjective and won’t help the reader much. You might under-estimate or over-estimate your skill level anyway. Some people choose to quantify coding skills with
years of experienceor the
lines of code(LoC), but these still don’t tell the reader very much. (Alpernas, Feldman, and Peleg 2020)
- avoid listing mass marketed office products of Microsoft (e.g. Word etc) as a skill, they are not generally very interesting skill because almost everyone has them. They won’t set you apart much from your competition, so don’t waste valuable space talking about office applications unless you’ve done something interesting with them, like some advanced integration with other software. Cloud services can be a slightly different matter, see section 18.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 and critically, reason, problem solve, analyse, generalise, 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.
Having zoomed in on the details of sections you’re likely to have, we’ll zoom back out to take a bird’s eye view of your whole CV. The issues in this section apply to the whole of your CV, rather than individual sections.
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.
Seemingly trivial typographical details can make a big difference to the overall look and feel of your document. The devil is in the details, for example the repeated text the quick brown fox jumps over the lazy dog in a bulleted list doesn’t use a proper indent…
The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog
… whereas the same text below does use a proper indented bullet. The latter looks more professional and is easier to read, especially when you have multiple bullet points:
The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog
Whatever your typographical style is, portable document format (
cv.pdf(not a very descriptive filename)
ada_lovelace.pdf(a descriptive filname)
cv-version1-final-FINAL-version-USE-THIS-ONE.pdf(reveals more about you than you might want to!)
alan_turing.pdf(a descriptive filname)
It’s fine to author your CV in Microsoft Word, but you’ll want to save it as (or print to) PDF to make it more platform independent. LaTeX and overleaf.com can be used to create professional PDFs and there are plenty of good templates at overleaf.com/gallery/tagged/cv. See Getting started with LaTeX (LaTeX4year1) if you’ve not used LaTeX before, or you need to refresh your memory. (Hull 2023b)
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. What’s your story, coding glory? (Gallagher 1995) The
C.A.R.E. 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 could 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? All of the above?
ACTION: What did you do with
Python? Did you use some particular library? Did you integrate or model something? What verbs can you use to describe these actions, see chapter 10
- 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 highlight it. That could be a quantification, for example describing a result in numbers (see
as measured bybelow) or it might be badges or certification described in chapter 19. If you’re talking about software, point to a copy online if you can, see section 11.3.3. Nothing says “I can build software …” quite like “ … and here’s one I made earlier”.
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 8.6) advise candidates to describe their experience and projects using this simple pattern:
Where accomplished is
Result, measured by is
Evidence and doing is the
Action. So instead of just saying:
You could say:
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 10 for examples.
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 8.18.
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 8.17. 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 8.19.
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 cut?
- Can you save a wasteful word here or a lazy line there?
- Check for any spurious line breaks, like a line with just one or two words on it, because every pixel counts.
Your two page CV is still a good store of stuff you might want to add to customised one-page résumés. If you find yourself cutting important stuff, you could list it somewhere else (like LinkedIn etc, see section 11.3.3) and link to it from your CV.
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.
you could say:
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 10 for examples.
- careerset.com, a free service provided by a UK based company, careerset Ltd. If you’re a University of Manchester student, you can login using your Uni credentials at careerset.com/manchester
- jobscan.co, a free service provided by an American company not really a CV checker
- kickresume.com AI-powered resume builder also does cover letters
Besides providing feedback on the content of your CV, using these systems can help address issues such as the use of tables, columns or layout which may cause problems for some systems. For example, some Applicant Tracking Systems (ATS) will erroneously ignore the second column of a two-column CV because they can’t parse the PostScript reliably to identify columns. (Bichl 2020) Some things to check with automated CV screens:
- Have you used standard headings for the sections? Unusual or non-standard section headings like
most proud of(see maybe ignored or misunderstood
- Have you used appropriate verbs to describe your actions?
- Is your layout and design robot friendly? Sometimes tables and two column layouts can get horribly mangled, see what happens to tables and columns in an applicant tracking system (Henderson 2023)
Bots, grammar checkers, Artificial Intelligence (AI) and spell checkers can help improve your written applications and CV. However, you can’t rely on machines and their algorithms completely. The résumé robots described in section 8.7.7 will just encode the prejudices of whoever wrote their algorithms and whatever bias there was in the data it was trained on, see section 4.6.3. Basic spellcheckers can’t be relied on completely either, as shown in the poem below:
Eye halve a spelling checker It came with my pea sea It plainly marques four my revue Miss steaks eye kin knot sea Eye strike a key and type a word And weight for it to say Weather eye am wrong oar write It shows me strait a weigh As soon as a mist ache is maid It nose bee fore two long And eye can put the error rite Its rare lea ever wrong Eye have run this poem threw it I am shore your pleased two no Its letter perfect awl the weigh My chequer told me sew ---Anon
While automation can help improve your writing, ultimately there is no substitute for people (you know: actual humans) reading your CV, and the more people that read it the better. This could be potential employers, your critical friends shown in figure 8.22 or just reading it out loud to yourself described in section 4.6.1.
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 anyway. Employers typically ask for your referees much later, when you’ve been offered or are about to be offered the job
- references disclose personal information. 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.
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.
- How long is your CV? How long should it be?
- One column or two column layout?
- How long should your personal statement be your CV, like Mike Rokernel has for example?
- Should you put education or experience first? Which is most important?
- How many of my hobbies and personal interests should you list? (Cheary 2021)
- How can you beat the black hole mentioned in section 8.2? See Your Résumé vs. Oblivion (Weber 2012)
- How many employers actually read the covering letter that accompanies your CV?
- 🔲 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 8.7.4 Does the style look good? Is it easy on the eye? Is there adequate whitespace, not too much (g a p p y) or too little (cramped)? See section 8.7.2
- 🔲 Is your year of graduation, degree program, University and expected (and/or achieved) overall degree classification clear with GPA as a percentage? See section 8.6.2
- 🔲 Have you eaten your own dogfood (woof) by reading it out loud, see section 4.6.1? Is everything relevant? e.g. no swimming certificates from ten years ago?
- 🔲 Have you spell-checked using both automatic and manual (proof-reading) techniques? See section 8.7.8.
- 🔲 Have you got a second opinion from a “résumé robot”? Is it robot proof? See section 8.7.7 🤖
- 🔲 Have you shown you
C.A.R.E? Are the
Evidencedescribed in section 8.6.7 clear? Have you added
contextusing relevant hyperlinks that an interested reader can click on? See section 8.7.6
- 🔲 Is it in reverse chronological order with the most recent things first? Can your timeline be easily followed, with all dates clearly aligned for easy reading? See Neil Pointer as an example with a clear timeline using right-aligned dates.
- 🔲 Have you avoided using too many personal pronouns?
I, me, my ...everywhere? See section 8.7.5
- 🔲 Have you made it clear what you have actually done using prominent
verbs? See chapter 10
- 🔲 Have you given sufficient information on your education without going into too much detail? Have you mentioned courses you are studying now (and next semester)? See section 8.6.2
- 🔲 Have you quantified and evidenced the claims you have made where you can? See section 8.6
- 🔲 Is it balanced, including both technical and non-technical (softer) skills? See section 5.3.8
- 🔲 Does it have a good, clear structure? Not too many headings, around five sections for a one-pager see section 8.6.1?
- 🔲 Have you clearly distinguished between paid, unpaid and voluntary
experience? Have you done the same for your
projects, see section 8.6.4? Have you included all of the relevant experience that you can fit on including casual work, see section 5.3.8?
- 🔲 Has your CV been reviewed by other people? Do a CV swap with a critical friend (see figure 8.22) 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
- 🔲 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 figure 8.25. See the examples in chapter 9. Who would you want to interview and why?
- 🔲 Have you used past tense consistently e.g.
Applications and CV’s are often accompanied by covering letters or include some kind of personal statement or summary. They are your elevator pitch shown in figure 8.23. Whereas a lot of your CV is essentially a bulleted list of facts, numbers and evidence, 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 include a
personal statement or
profile on your CV keep it short, unlike Mike Rokernel who waffles on for ages (yawn) without actually providing any evidence for his assertions. This kind of information usually fits better in your covering letter anyway, because there isn’t much space for it on a CV.
Let’s say you’re applying for a widget engineering position at the world famous widget manufacturer:
widget.com. There are three things you need to convey in the following order:
Why them? Why are you applying to
widget.com, look at the employers values, how do they align with your own? See section 6.6
Why that role? Employees of
widget.comhave many different roles and responsibilities but what is it about being a junior
widget engineeror trainee
widget scientist(say) that attracts you?
Why you? Why should
widget.comemploy you? What skills and experience make you stand out from all the other hopeful widgeteers? What are your Unique Selling Points (USPs)? Say why you would be good for them (not why widget.com would be good for you and your career).
You can see some examples of answers to these questions at:
Some employers will read your covering letter very carefully, others less so. It is not always clear which employers will bother and which won’t.
Even if nobody reads your covering letter, it is still worth writing one because formulating answers to the three basic questions in section 8.10 will force you to rehearse standard interview questions.
You can think of your covering letter as writing and rehearsing some of the lines of your elevator pitch shown in figure 8.23.
You might be tempted to embed a short summary or
personal statement section at the top of your CV after your header. If you’re thinking about doing this, keep it short or just leave it out altogether. Why? Here’s an example of how not to do it from the (fictional) Sir Don Malaka FRS who is the Banterian Professor of Rhetoric at the University of Oxford:
I have a proven track record of delivering excellent teaching and outstanding learning experiences for all of my students, whatever their background. I am also a committed and diligent leader who can deliver large and ambitious projects on time and to budget. I am also capable of leading cross-disclipinary teams of colleagues towards excellent and innovative results that align closely with strategic educational objectives.
Are you persuaded by Professor Malaka’s personal statement? I hope you are not convinced because it smells of bullshit, see figure 8.24. One of the reasons the statement smells dodgy is because it makes lots of assertions without providing any actual evidence. Is Professor Hotair trying to persuade us to disregard the truth? Without evidence, it is hard to tell which of their assertions are true or false, so the whole statement risks being ignored as bullshit or lies. (Frankfurt 2005)
On a one page CV, you rarely have space to include any of this kind of hot air anyway. High level statements usually fit better on a covering letter see section 8.10. A shorter, less bullshitty personal statement from a student is shown below:
Hello, my name is Mike Rokernel. I am a second year student in Computer Science at the University of Poppleton looking for an industrial placement in software engineering
Is this better? Personally, I think you should only include a personal statement on your CV if you’ve got space to do so because you’ll often just repeat facts from your CV anyway, like Mike’s example above. Save the beautiful persuasive rhetorical prose for your covering letters and make reference to key facts on your CV. There are usually much more interesting and appetising things you can say about yourself on your CV. 💩
Too long, didn’t read (TL;DR)? Here’s a summary:
Your future is bright, your future needs debugging. Debugging your future will help you test future. Testing your future will help you to start coding your future. One of the best ways to debug your own CV is to fix bugs in other peoples CVs, see figure 8.25
In this chapter we have looked at how to debug your future, with a particular focus on your CV21 and any supporting written communication. If you fix the bugs we’ve described here, before an employer sees your CV, you’ll stand a much better chance of getting an interview. The checklist in section 8.9 is a good place to start debugging your CV.
Some of the strategies you apply to debugging your actual code, can also be applied to debugging your future:
- Inspect, don’t squash bugs, take time to reflect (see section 18.6) and understand any bugs you find in your future (Evans 2022)
- Being stuck is temporary, see section 20.10
- Check your assumptions, especially if debugging the
contentbugs described in section 8.1 makes you anxious or depressed, see chapter 3
- Don’t go it alone, grow your network, see section 11.2.5
- Build your debugging toolkit by identifying your strengths and weaknesses, see chapter 2
Debugging your future can be an enjoyable adventure! Debugging your future is Coding your future.
In the next part, chapter 9: Hacking your Future you’ll improve your CV writing skills by going beyond debugging your own CV and debugging other people’s instead.