Resume Tips for Freshers in India: What Actually Gets You Shortlisted
Most fresher resumes in India are rejected in under fifteen seconds, and almost never because the candidate was not good enough. They are rejected because the document made it hard to find the two or three things a recruiter is actually looking for. This guide is about fixing that.
Start with what the reader is scanning for
A recruiter screening thirty fresher CVs for a junior developer role is looking for four things: can this person code, is there any evidence of it, are they roughly in the right location and salary band, and can they be reached. Everything on page one should serve one of those four questions.
That means your objective statement is costing you space. Nobody has ever shortlisted a fresher because they were "seeking a challenging role in a dynamic organisation". Delete it and put a two-line summary of what you actually build there instead.
Projects beat coursework, always
For a fresher, the projects section is the resume. It is the only evidence you have that you can do the work, and it should sit directly under your contact details, above education.
Write each project in three lines:
- What it does, in one plain sentence a non-technical person would understand.
- What you built and with what, specifically — the framework, the database, where it is deployed.
- One concrete detail that shows depth: a problem you hit and how you solved it, or a number.
Compare "E-commerce website using MERN stack" with "A grocery ordering site where shop owners manage stock from a phone. React and Node with MongoDB, deployed on Render. Rewrote the product search to use a text index after the naive version took four seconds on 5,000 items."
The second one is a conversation starter. The first is a line in a list of two hundred identical lines.
Two or three real projects, not eight tutorials
A recruiter can tell the difference between a project you built and a tutorial you followed. Eight tutorial clones read as weaker than two projects that solve a real problem, however small. If you built something your college society actually used, that beats a copy of a popular app every time.
Put the GitHub link on every project, and make sure the repository has a README that explains what it is. A dead link or an empty repo is worse than no link.
Get past the keyword filter without keyword stuffing
Many companies run a keyword match before a human reads anything. The safe way to handle this is not a hidden white-text block of skills; that gets you blacklisted. It is to use the exact words from the job description in the places they naturally belong.
If the posting says React, Node.js and MongoDB, those exact strings should appear in your projects section, because you actually used them. If the posting says something you have never touched, leave it out. Getting an interview for a skill you do not have wastes everyone time, most of all yours.
Formatting rules that matter
- One page. You are a fresher; there is not two pages of material yet.
- A single column. Two-column templates confuse many parsing systems and your skills section can vanish.
- Send a PDF, named FirstName-LastName-Resume.pdf, not resume_final_v3.pdf.
- A plain readable font at 10 or 11 point. No photo, no age, no marital status.
- Include your percentage or CGPA once. If it is below the usual cutoffs, put it at the bottom and let the projects do the work.
The mistakes that actually cost interviews
A Gmail address like coolguy_rahul99 undermines everything above it. A phone number with a typo means nobody can reach you. A skills section listing fourteen technologies at "intermediate" level invites an interviewer to pick the one you are weakest at.
List five or six skills you would be comfortable being questioned on for twenty minutes. That is a stronger position than a long list you have to defend.
Before you send it
Read the job description once more and check that the top third of your resume answers it. Ask one person who has hired before to read it for ten seconds and tell you what they remember. If what they remember is not what you wanted them to remember, the layout is wrong, not your experience.
