How to Write a CV

A CV is not a job description and it is not a diary. It is a short document that has to answer one question fast: why should we interview this person? Everything below is about making that answer obvious to a human reader and to the applicant tracking systems that sit in front of them.

When you want a second opinion on your own words, run it through Banana CV first, then use this guide to decide what to change.

A recruiter or hiring manager usually reads a CV for about six seconds before deciding whether to keep reading. Some read it for three. That is the only design constraint that matters, and most weak CVs fail it in the same way: the most valuable information is buried at the bottom, and the top is filled with text that says nothing.

So the goal of every line is simple. Give a reader enough specific, relevant evidence that they want more. "Hardworking team player" gives them nothing to hold on to, so it earns no attention. "Cut weekly reporting from 90 minutes to 30 by rebuilding it in Excel" gives them something concrete, and now they want to know what else you can do like that.

A CV does not need every section ever invented. It needs a small number of well-built ones, in an order that matches how the evidence builds.

• Contact details: name, email, phone, city, and a LinkedIn or portfolio link if you have one. Include the country or time zone if you are applying remotely.
• A short summary, three lines at most. Use it to say what you do and what you are looking for, not to list adjectives.
• Experience: your strongest evidence first, most relevant role first. For each role, a few bullets that show what you did and what changed because of it.
• Education: degree, subject, institution, and years. Add a grade only if it is genuinely strong and relevant.
• Skills: only the ones you could be asked about in an interview. A long list of keywords you have never used dilutes the ones that matter.
• Projects: for students, career changers and anyone whose experience section is thin. This is where you show what you built.

The most common CV mistake is describing activity instead of effect. "Responsible for reports and helping the sales team" describes a job. It does not tell a reader whether you are worth a conversation.

Rewrite the same role in three parts: the action you took, the tool or method you used, and the change that resulted. You do not always need a number, but you always need a specific.

• Weak: Responsible for social media accounts and posting updates.
• Stronger: Rebuilt the weekly content calendar, replacing ad-hoc posting with a two-week rolling schedule.
• Weak: Helped with customer queries and emails.
• Stronger: Handled first-line support for around 40 tickets a week and documented repeat issues for the product team.

Numbers make a claim checkable, which is why they are persuasive. They are also the easiest place to accidentally make your CV untrue, and a single inflated figure can cost you the interview and your credibility.

The safe rule: use a number only if you can say where it came from. Team size, ticket volume, percentage change, number of users, time saved. If you did not measure it, describe the change in words instead of inventing a percentage. "Cut report preparation from 90 minutes to 30" is a number you can defend because you watched it happen.

Hiring managers do not skip the skills section; they test it. Listing twenty technologies spreads your credibility thin and makes it easy for an interviewer to find one you cannot discuss.

List fewer skills, grouped by what they let you do, and be ready for any of them to come up. "React, TypeScript, Vite, REST APIs" is stronger than "React, JavaScript, HTML, CSS, Git, Excel, SQL, MongoDB, AWS, Docker" when you can actually talk about the first four. If you have used something, keep it. Do not remove a skill just because it is common; remove the ones you would struggle to be asked about.

If you are a student, a career changer, or rebuilding your CV after a gap, projects are where you prove you can finish something. The rule is the same as experience: name what you built, what problem it solved, and what you specifically did.

A project does not need to be famous or have users. A small tool that solves a real annoyance for a few dozen people is more useful on a CV than a vague claim that you are "comfortable with full-stack development". Link it, and make sure the link opens.

• Name the project and what it does, in one line.
• State the stack and the scale, if either is relevant.
• Describe the problem, your decision, and the result.
• Link to the live version, the repository, or a short write-up.

Applicant tracking systems are used to collect, store and route applications. Most of them extract text from your file and check it against the job description for terms. That is the part you need to care about.

The widely repeated idea that a specific single-column template is required is largely a myth. What is not a myth: readable text, standard section headings like "Experience" and "Education", your name and contact details near the top, and file formats that extract cleanly. If your CV looks like a design experiment, keep a plain text version ready for upload even if you send a nicer one.

Be careful with images of text, text in headers and footers, charts and unusual symbols. Many parsers simply do not read them.

Sending the same CV to fifty different jobs is the norm, and it is why so many applications feel generic. Tailoring is not rewriting; it is reordering and re-weighting.

Read the job description, list the requirements it names, and move the experience and skills that match those requirements to the top of the relevant section. If a requirement appears nowhere in your CV, decide honestly whether you have it. If you have something adjacent, say so plainly. If you do not, do not pretend.

These are the problems that show up again and again, and none of them are about formatting taste.

• Vague verbs: "helped with", "assisted in", "responsible for", "worked on". Replace them with what you actually did.
• Repeated filler: if three bullets all say you are a team player, you have used three lines to say nothing.
• Hidden dates: month and year ranges let a reader understand your career without a separate calculation.
• Unverified claims: every line should survive one follow-up question.
• Typos in names, employers and dates: these look worse than any layout choice.
• No next step: say where you want to work and why, so the reader knows how to reply.

You do not need a second pair of eyes for the basics, but a short checklist catches most of what a hiring manager would notice.

• Read only the first ten lines. Can you tell what you do and what you want?
• Check every bullet: is it specific, and can I defend it out loud?
• Replace every vague verb with a concrete one.
• Check dates, employer names and your contact details against reality.
• Confirm the file opens on a phone, since many applications are reviewed there.
• Spell-check it, and remove anything you would not say out loud in the interview.

Banana CV reads the words on your page and tells you which ones are vague, repeated or unsupported. It is free, needs no account, and works in English or Malayalam.