Read fifty CVs for an AI role and about forty of them are the same document with different names on top: a skills list containing every library in the ecosystem, three projects with the same titles, and bullet points that describe what a tutorial did rather than what the candidate decided.
The problem is not the skills, it is the evidence
Almost everyone applying for a junior AI role can list Python, pandas, scikit-learn, TensorFlow or PyTorch, and now LangChain. The list is table stakes and it separates nobody, because it describes exposure rather than capability.
What a hiring manager is trying to work out in fifteen seconds is whether you have made decisions under constraint. Did you choose something over something else, and can you say why? That is the difference between someone who has followed instructions and someone who can be given a problem.
Rewrite your project bullets around decisions
A project bullet that says "Built a chatbot using LangChain and OpenAI" tells a reader nothing they did not already assume. It describes the category, not the work.
The stronger version names a decision, a constraint or a result. "Built a document Q&A system over 4,000 internal PDFs; switched from naive chunking to section-aware splitting after retrieval accuracy on a 50-question test set stayed below 60%." That sentence demonstrates that you measured something, that the first approach failed, and that you knew what to change.
You do not need impressive numbers. You need real ones. "Below 60% on a 50-question test set" is more convincing than "improved accuracy by 40%", because the first is specific enough to be questioned and the second is the kind of figure everyone writes.
- Name the problem, not the technology category.
- Say what you measured, even if the measurement was crude.
- Say what you changed after measuring. That is the whole story.
- Prefer a real small number to a round impressive one.
What to leave out
A skills section listing thirty technologies invites the interviewer to pick the one you are weakest at. List what you would be comfortable being asked about for ten minutes.
Certificates from short online courses are worth less than the projects you did during them. If the course produced something you built, put the thing on the CV and mention the course in passing, or not at all.
Self-assessed proficiency bars — Python 90%, SQL 70% — are read by technical interviewers as a claim to be tested, and the number is always either indefensible or unnecessary.
Tailoring, without rewriting it every time
The advice to tailor your CV to every application is correct and impractical as usually stated. Rewriting a two-page document forty times produces forty worse documents and one exhausted applicant.
What actually works is keeping one strong CV and changing two things per application: the order of the project bullets, so the most relevant one is first, and the specific technologies named in the skills line, so they match the posting where you genuinely have them. That is a five-minute edit rather than an afternoon, and it captures most of the benefit.
The thing not to change is the substance. If a posting asks for something you have not done, the answer is to say so in the cover note or to leave it out — not to stretch a description until it technically covers it. Stretched claims are found in the interview, and being caught is much more costly than being under-qualified.
- Reorder project bullets so the relevant one leads. One minute.
- Match the technology names to the posting where you honestly can. Two minutes.
- Leave everything else alone.
Length, and what to cut
One page for under five years of experience, two beyond that, is the convention and it is worth following — not because a rule exists, but because a reviewer reads the first half of the first page carefully and skims everything after. Material below that line is not read, so putting your best work there is the same as deleting it.
The things that usually go, in order: a career objective that says you are seeking a challenging role, a list of school results if you have a degree, soft skills asserted without evidence, and any technology you would not want to be asked about. That normally recovers a third of a page, which is enough to move a project up into the part that gets read.
The portfolio question
For AI roles specifically, a public repository with a working project and a README that explains the decisions is worth more than an additional half page of CV. The README is the part people skip, and it is the part that does the work: what the problem was, what you tried, what failed, what you would do differently.
One finished, documented project beats four half-built ones. Reviewers open the first repository, read for ninety seconds, and form a view. Make sure the first one they open is the one you are proud of, and pin it.
A realistic expectation
A good CV does not get you a job. It gets you read, and then a conversation. Most rejections at the CV stage are not about quality at all — the role was filled internally, the requirements shifted, two hundred people applied. That is genuinely not a judgement on you, and treating every rejection as feedback about your worth is both painful and inaccurate.
What you control is whether the document communicates what you actually did. That is a solvable problem, and it is the only part worth spending your energy on.
Key takeaways
- 1.Skills lists separate nobody. Decisions under constraint separate everybody.
- 2.Rewrite project bullets to name what you measured and what you changed as a result.
- 3.A real small number beats a round impressive one, because it survives a follow-up question.
- 4.One finished documented project outranks four half-built ones. The README does most of the work.
Do it now, free
AI Resume Analyzer
Paste your CV and it will quote the lines that are weak and show stronger versions of them. It works on the text you give it and nothing else — no invented experience, no invented numbers.
No sign-up. The internship is free to join too, with real project briefs and reviewed submissions.