What actually happens to your resume

Two things read your resume, usually in this order. First, an applicant tracking system parses it into structured fields. If your PDF is an image, or your layout uses multiple columns and text boxes, the parser mangles it and your experience section can arrive empty.

Second, a human skims it. Not reads, skims. Six to ten seconds on the first pass, and in that window they are looking for three things: does this person do the kind of work we need, have they done it at real scale, and is there a number anywhere that proves it. If none of those land, you are in the no pile before anyone has read your third bullet.

Everything below follows from that. Write for a parser and a skimmer, not for a careful reader who does not exist.

The shape of a good resume

One page. Single column. Sections in the order of what makes you hireable. For a student or a fresher that usually means:

1. Name and contact details
2. Summary, two or three lines
3. Experience, if you have any
4. Projects
5. Skills
6. Education
7. Achievements or certifications, only the relevant ones

If you have two or more real internships, experience goes above projects. If your projects are stronger than your internships, flip them. The rule is simple: the strongest evidence goes highest, because the skim starts at the top and stops early.

A real before and after

Same person, same experience, same projects. The only thing that changed is how specific and verifiable every line is. This is the exact difference between a resume that gets skimmed and ignored, and one that gets a reply.

Notice the before version is not badly written, it just hedges everywhere: vague adjectives, a bullet list of skills nobody can verify, an email address that looks unprofessional, and duties instead of outcomes. The after version says less overall and lands harder, because every line either proves scale, proves difficulty, or proves impact.

The summary

Your summary has one job: make the next ten seconds worth spending. Three sentences, maximum. Who you are, your single strongest proof point with a number in it, and what you are looking for.

The adjectives everyone uses, like hardworking, passionate, detail-oriented and quick learner, carry zero information because nobody has ever written the opposite. Delete them and use the space for a fact.

Both are three sentences. The second one tells a recruiter you can ship, you handle traffic, and you can pass a DSA screen. The first one tells them nothing they could not assume about any applicant.

Experience

This is where most resumes quietly collapse into a job description. People list what they were assigned instead of what changed because they were there.

Use this pattern for every bullet:

Action verb → what you built or changed → the measurable result → how you did it

Notice what the good versions share. They contain a before and an after. They name the technique, so a technical interviewer has something to ask about. And they are falsifiable, which is exactly why they are believed.

One more thing about the word increased. “Increased website traffic by 60%” is weaker than it looks, because it says nothing about what you actually did. The number sits there with no mechanism attached, and an interviewer cannot follow up on it. Write “Grew organic traffic 60% in 4 months by publishing 24 technical tutorials and rewriting the docs IA” instead. Same metric, but now it is a story about your work rather than a statistic that happened near you.

Three to four bullets per role. The fifth bullet is almost always your weakest one, and it drags the average down.

Projects

For students and freshers, projects often carry more weight than internships, because they show what you do when nobody assigns you anything. But a project only counts if it shows evidence of engineering rather than evidence of following a tutorial.

Three things make a project entry land:

• Real usage. Users, requests, downloads, stars, anything that proves it left your laptop.
• A hard problem you solved. Not “built a CRUD app” but the specific thing that was difficult and how you handled it.
• A stack that matches the job. Trim the projects that do not, even if you are proud of them.

The first one describes a tutorial that ten thousand other applicants also built. The second one describes an engineer. Same effort, different framing, and the framing is the part you control.

Link the repo or the live site. A recruiter who clicks is a recruiter who is interested, and a dead link is worse than no link at all.

Skills

Group them by category and keep them honest. Languages, frameworks, tools. That is usually enough.

Do not list proficiency bars or star ratings, they are unverifiable and they eat space. Do not list twenty technologies you touched once in a weekend, because the interviewer picks the one you are weakest at and asks about it. Every item in that section is something you are volunteering to be tested on.

If a skill matters, it should also appear inside an experience or project bullet doing actual work. A skill that appears only in the skills list reads like a keyword, because that is usually what it is.

Education and extras

Degree, institution, years, and your CGPA if it is above roughly 7.5. Below that, leave it out and let your projects carry the page. Coursework lists are filler unless the role specifically asks for a subject you studied deeply.

Certifications and achievements belong at the bottom and only if they are relevant. A hackathon win, a competitive-programming rank, a real open-source contribution, a cloud certification for a cloud role: those earn their space. A generic six-hour course completion certificate does not.

Finding numbers when you think you have none

“I do not have any metrics” is the most common objection I hear, and it is almost never true. You have not measured them yet, which is a different problem with an easy fix. Go looking for:

• Scale: users, requests, records, files, rows, concurrent sessions, repositories
• Time: build time, load time, latency, hours saved per week, deployment frequency
• Quality: test coverage, bug count, crash rate, incidents per month, review turnaround
• Reach: stars, forks, downloads, readers, attendees, community members
• Scope: team size, number of services touched, number of endpoints, features shipped

Open your analytics, your repo insights, your database, your project board. The numbers are sitting there. If something is genuinely unmeasurable, describe the scope and difficulty concretely instead. “Migrated 40+ components from JavaScript to TypeScript with zero runtime regressions” works perfectly well without a percentage.

Estimates are fine as long as they are honest and you can defend them in an interview. “Roughly 200 daily active users” is far better than silence.

Formatting and typography

Good formatting is invisible. It should never be the thing someone notices. A few settings do most of the work:

Export as a text-based PDF, never an image and never a screenshot. Open the file afterwards and try to select your name with the cursor. If you cannot highlight it, no parser can read it either, and you have effectively submitted a blank application.

Name the file properly too. Rohan_Sharma_Resume.pdf rather than resume_final_v3_updated.pdf.

Mistakes I see constantly

• Writing duties instead of outcomes. If your bullet could appear in the job posting, it is describing the role and not you.
• One resume for every application. Reorder your projects and rewrite two bullets per role. Fifteen minutes of tailoring beats fifty untailored sends.
• Photos, graphics and colour blocks. They break parsers, and in most markets a photo introduces bias you do not want.
• Padding to fill the page. A dense two-thirds page beats a padded full page every time.
• Vague seniority words. “Led” and “spearheaded” mean nothing without a team size or a scope attached.
• Typos in the first three lines. Read it backwards, bullet by bullet. It breaks the autocomplete your brain runs when re-reading your own writing.
• Dead links. Click every one before you send.

The final checklist

Before you send it anywhere, go line by line:

• Does every bullet contain either a number or a concrete technical detail?
• Could a stranger tell what you actually built from the top third of the page alone?
• Is it one page, one column, with selectable text in the PDF?
• Have you removed every adjective that describes your personality rather than your work?
• Does the strongest thing you have ever done appear above the fold?
• Do the links work, and does the filename have your name in it?

If all six are yes, send it. Then keep a copy of every version you send, because six months from now you will want to know which one got replies.