Junior developer resume: 10 mistakes that get you rejected

Sending your resume everywhere and never getting an interview? Most junior developer resumes aren't rejected for lack of experience. They're rejected because the reader can't find any proof that you can do the job. Let's fix the 10 most common mistakes on one sample resume.

Why did Minh send 30 applications and hear nothing back?

This is the first post in the series The junior journey, which follows Minh from writing a resume to the end of the probation period at a first job. Minh is a made-up character, pieced together from situations that fresh IT graduates in Vietnam will find very familiar. The story is fiction, but the mistakes and the fixes are real.

Minh has just graduated in Information Technology. Over two weeks, Minh sent the same resume to about 30 React job ads. Nobody called back, not even the companies that said clearly they hire fresh graduates. Minh started to think "I'm just not good enough yet" and was about to sign up for one more course.

Before signing up for anything, let's look at Minh's resume. Here's the whole thing, rewritten as plain text so it's easy to read (and translated from Vietnamese). The last line describes the file Minh actually sent:

**Le Van Minh** — minhdeptrai99@gmail.com — +84 9xx xxx xxx
Photo: taken at a café, wearing sunglasses

## Career objective
Seeking an opportunity to work in a professional, dynamic environment where I can
learn and grow, and contribute to the company's development.

## Skills
Javascript 80% · ReactJs 75% · NodeJS 70% · Java 60% · C++ 60% · Python 50% ·
PHP 40% · MongoDB · MySQL · Docker · AWS · Kubernetes · Figma · Photoshop ·
Teamwork · Works well under high pressure

## Projects
**E-commerce website** (graduation project, team of 4)
- Built an e-commerce website with ReactJs and NodeJS.
- Features login, shopping cart, checkout.

**Netflix clone** — Followed a YouTube course.
**Todo app**

## Education
X University, Information Technology, 2022–2026, GPA 3.1

## Hobbies
Reading, travelling, listening to music.

(File sent: CV-final-2.docx — 3 pages, two columns, skill % bars, coloured background)

Try counting how many mistakes you can spot before you read on. There are at least 10 in there.

What is the person screening resumes looking for?

To fix a resume properly, you first need to understand who reads it. At the screening stage, the person holding your resume might be a recruiter or a developer on the team. Either way, they're trying to answer three questions.

The first is whether you know the things this role actually needs. The second is whether you've built something that works on your own, and for a junior the answer almost always lives in the projects section. The third is whether you're careful, because typos, broken links and a carelessly named file all say "no".

A recruiter reads a lot of resumes for every opening, so they don't have time to dig for information on your behalf. Anything that isn't easy to see might as well not be there. The company cares about what you can do for the role, not about what you hope to get from it.

Keep those three questions in mind and the 10 mistakes below become easy to understand.

The first three mistakes: a resume not written for the role

1. One resume sent everywhere

Minh is applying for React roles, but the skills section puts Java, C++, Python and PHP on the same level as React. The reader has to find the relevant part among 15 skills on their own, and most readers won't bother.

The fix I recommend is to keep one complete master resume just for yourself. Each time you apply, make a shorter copy: move the skills and projects that match the job description to the top, and drop what isn't relevant. Use the exact words from the job ad too, such as "REST API" or "TypeScript", because many companies use software that scans for keywords to filter resumes before a human reads them. Each application takes about ten minutes longer, but ten tailored applications usually do better than thirty identical ones.

2. An empty career objective

"Seeking an opportunity to work in a professional, dynamic environment where I can learn and grow" appears on thousands of other resumes. It says what Minh wants, but nothing about what Minh can do.

Replace it with two or three lines summing up work you've done that the reader can check:

Recent graduate and frontend developer who has built 2 React + TypeScript apps with real users (links below). Used to working through pull requests on GitHub, writing tests with Vitest and deploying to Vercel.

Every phrase in that summary leads to something the reader can click and look at.

3. A skills list that reads like a keyword dump

Minh lists 15 skills, with percentage bars such as "Javascript 80%". The list includes Kubernetes and AWS, which Minh has only watched one video about. "Works well under high pressure" even sits in the middle of the technologies.

Percentage bars mean nothing to the reader, because nobody knows what the 80% is measured against. Listing too many skills is also more dangerous than you might think, because any skill on your resume can become an interview question. Write Kubernetes, and you'd better be ready to explain what a pod is. Later in this post I'll replay a short interview so you can see how that plays out.

The fix is to split your skills into two groups. "Proficient" holds the things you've used in a project and could talk about for ten minutes. "Familiar with" holds the things you've used and understand at a basic level. Every proficient skill must show up in at least one project further down. As for soft skills, prove them in a project description, for example "reviewed pull requests for 3 teammates", instead of just listing them.

The next four mistakes: a projects section that proves nothing

For a junior, the projects section is the deciding part. The reader wants to see that you've built something that works, by yourself.

4. Projects with no links, or broken ones

None of Minh's three projects has a link. The "E-commerce website" might be a good product, but the reader has no way to find out.

Every project needs a link to the repo and a link to a live demo. Before you send your resume each time, click every link again, on your phone too. Demos on free hosting plans can be paused after a while with no visitors, so open each one once to be sure it still works.

5. A repo with no README

Say Minh has added the repo link. The reader opens it and sees only src and public folders and a package.json file. They don't know what the project does, how to run it, or which part Minh built, so they close the tab.

A minimal README needs a screenshot, one sentence on what problem the project solves, the list of technologies used, and the commands to run it locally. The README is the first page anyone sees of your product, and GitHub's own guide to READMEs is a good place to start.

6. Describing features instead of what you did

Minh writes: "Built an e-commerce website with ReactJs and NodeJS. Features login, shopping cart, checkout." That's just a feature list. It doesn't show how good Minh is, and it doesn't say which part Minh built in a team of four.

Each bullet point should carry three pieces of information: what you did, how you did it, and what came of it. For a team project, state clearly which part was yours:

My part: shopping cart and checkout (React, Context API), plus the order management page. Cut the load time of the product list page with pagination and WebP image compression. Reviewed pull requests for the other 3 members; set up commit conventions with Conventional Commits.

The interviewer will dig into exactly the work you claim as yours. So only write what you can explain.

7. A tutorial project left exactly as the video built it

Minh writes "Netflix clone, followed a YouTube course" and "Todo app". Hundreds of other candidates have exactly these two projects.

There's nothing wrong with learning from videos; it's a good way to learn. But a project built along with a video doesn't yet show that you can solve problems on your own, because the person who made the video already solved them.

You have two ways to improve this. The first is to add things the video didn't have, such as real data storage, login, tests or deployment, and say clearly in the README what you added. The second, which I think is better, is to build a small project that solves a problem of your own. Minh dropped the Netflix clone and replaced it with an expense tracker you use by sending a message, which Minh uses every day. The next post in the series covers how to choose a project like that.

The last three mistakes: presentation ruins the content

8. Too fancy and too long

Minh's resume is three pages long, in two columns, with a coloured background and percentage bars, and saved as a Word file.

A two-column resume with icons and text inside images can look nice, but resume-screening software often misreads that kind of layout, so information gets jumbled or lost entirely. A Word file can also lose its formatting on the recipient's machine. A single-column resume with clear headings, a readable font and exported to PDF is enough. For a junior, one page is best, and ITviec, a Vietnamese IT job board, advises keeping a junior resume to two pages at most. If you run out of room, cut what isn't relevant to the role instead of shrinking the font.

9. Typos, wrongly spelled technology names and an unprofessional look

Minh's resume has "Javascript", "ReactJs", "NodeJS", the email address minhdeptrai99@gmail.com (roughly "minh-handsome-99"), a photo in sunglasses at a café, and the file name CV-final-2.docx.

Each mistake on its own is small, but added together, a developer reading it concludes that you don't pay attention to detail, which is exactly what a developer's daily work demands.

Write technology names the official way: JavaScript, TypeScript, React, Node.js, GitHub, PostgreSQL. Use an email address based on your name. Many IT companies don't ask for a photo, and if you include one, choose a neat portrait. Name the file something like LeVanMinh-Frontend-CV.pdf. Finally, read the whole resume out loud once and ask someone else to read it too.

10. A GitHub link to an empty profile

After fixing the nine mistakes above, Minh adds a GitHub link to the resume. The reader opens it and sees a few empty repos, and every commit just says "update" or "fix". In many cases that's worse than having no link at all.

Pin your three or four best repos to the top of your profile. It's also worth creating a profile README, a public repo with the same name as your username, because the README of that repo shows up right on your profile page. And from today on, write commits that mean something; the post on how to write good commit messages has a few templates you can use straight away.

Why does padding your skills list backfire?

Let's go back to mistake number 3. Say Minh keeps Docker and AWS in the skills section so the resume looks fuller, and gets invited to an interview. Here's a very typical exchange (an illustration):

Interviewer: I see you've listed Docker. Which project did you use Docker in? Minh: I've studied it a bit, I know how to run docker run. Interviewer: So how is an image different from a container? Does your e-commerce project have a Dockerfile? Minh: Um… I didn't use Docker in that project.

The exchange lasts three minutes. What the interviewer writes down isn't "Minh doesn't know Docker", because a junior not knowing Docker is perfectly normal. What they write down is "Minh puts things on the resume that Minh can't do". From then on, every other line of the resume, even the true ones, is read with a little suspicion.

This happens because interviewers usually prepare questions from your own resume; it's the fastest way to check a candidate. Every line on your resume is like an invitation: "ask me about this". List 15 skills and you've invited the interviewer to ask about 15 topics. List 8 skills you can each talk about for ten minutes, and you've picked a playing field that favours you.

On the fixed resume, Docker is still there, but in the "familiar with" group. When asked, Minh can answer honestly, "I'm just getting familiar with it, I use it to run a database on my machine", and for a junior that answer is completely fine.

Minh's resume after one evening of fixes

Same Minh, same projects, but after one evening of reworking it for a Frontend Developer (React) role, Minh's resume looks like this. This is the whole resume; you can copy it as a template and swap in your own details. The links and account names in it are examples:

**Le Van Minh** — Frontend Developer
minh.le.dev@gmail.com · +84 9xx xxx xxx · github.com/minh-le-dev · linkedin.com/in/minh-le-dev · Ho Chi Minh City

## Summary
Recent graduate and frontend developer who has built 2 React + TypeScript apps
with real users (links below). Used to working through pull requests on GitHub,
writing tests with Vitest and deploying to Vercel.

## Skills
- Proficient (used in projects): JavaScript, TypeScript, React, Next.js,
  HTML/CSS, Git, REST API
- Familiar with: Node.js, PostgreSQL (Supabase), Vitest, Docker

## Projects
**Expense tracker by text message** — personal project · repo · demo
- Send "coffee 35k" to log an expense; monthly totals. Next.js, TypeScript.
- Wrote the amount parser myself ("35k", "1tr2", "45.000": the shorthand people
  in Vietnam use for prices) with 11 tests; no external libraries.
- Used daily by me and a few classmates; fixed the bugs they reported.

**Coffee shop website** — graduation project, team of 4 · repo · demo
- My part: shopping cart and checkout (React, Context API), order management page.
- Cut the load time of the product list page with pagination and WebP images.
- Reviewed pull requests for the other 3 members; set up Conventional Commits.

## Education
X University — Information Technology, 2022–2026

(File sent: LeVanMinh-Frontend-CV.pdf — 1 page, single column, no background, no % bars)

On the real resume, each "repo" and "demo" is a clickable link to the GitHub repo and the live demo.

Put it next to the old one and the difference is obvious. The heading names the role, and the summary tells what Minh has done. The skills go from 15 down to 11, split into two groups, with no percentage bars and no Kubernetes.

Every project has links, Minh's own part and a concrete result. The Netflix clone and the Todo app are gone, replaced by a project Minh came up with. The whole resume fits on one page, in one column, saved as a PDF with Minh's name in the file name.

Scroll up, read the old version again, and compare it with this one. That's the fastest way to see the difference, faster than reading any guide, this one included.

What should you check in the ten minutes before you send it?

Then run through a few more points quickly. Every skill in the "proficient" group appears in at least one project. Every project has a repo link, a demo link, a README, and says clearly which part you built.

The resume has no empty career objective, uses one column, fits on one page, is saved as a PDF and has your name in the file name. Every link works, on a phone too. Copy these points into a note on your phone, and pull it out for a quick check every time you apply.

A good resume only gets you into the interview room. Any line on it can become a question, so make sure you can talk through each project in two minutes. The question "tell me about the project you're most proud of" has a ready answer in the interview question bank. There are more posts on job hunting and growing as a developer in the developer career topic.

What if the projects section is still thin?

Minh's resume is clean now. But putting it next to a job ad, Minh notices that the projects section is still thin. The graduation project was team work and Minh's part was only a small piece of it, while the personal project has only just started.

The next post in the series answers exactly the question on Minh's mind: which personal project makes a hiring team actually want to open it, and how far do you need to take it? You can follow the whole journey in the series The junior journey.