The campus placement resume

Campus placement is not the same problem as applying to jobs online. You submit one PDF, once, to a placement cell that will forward the same file to every company on the calendar. You cannot tailor per company, you often cannot revise it after the deadline, and the shortlist is drawn from a few hundred people whose marks look a lot like yours.

That changes what a good resume looks like. It has to be general enough to send everywhere and specific enough to stand out in a stack, which is a narrower target than the usual advice acknowledges.

Follow the cell’s format, exactly

If your placement cell publishes a template, page limit, font size, file naming convention or a required photo, follow it to the letter. Cells reject on format, and a rejection here is not a company’s decision about you — it is an administrative one you could have avoided. Read the circular twice. If it says one page, one page means one page even when your second page is good.

Where the template leaves you freedom — bullet wording, project selection, the order of optional sections — use all of it. That is the part that decides shortlists.

You are being compared, not evaluated

A recruiter reading four hundred resumes from one department is not asking “is this person good?” They are asking “which twenty of these do I take?” Everything that is identical across the batch — the same degree, the same core courses, the same three lab projects — does no work for you. What differentiates is:

• A project with real users, however few. Three hundred students using your app beats a technically harder project nobody ran.
• Something built outside coursework. It signals that you write code when nobody is grading it.
• An internship where you shipped something, described by what changed rather than by what you were taught.
• A position of responsibility with a number attached.“Coordinated a technical fest with 1,200 attendees and a ₹4L budget” is concrete; “core member, technical team” is not.
• A competitive-programming or Kaggle record, if you have one. Rating and platform, stated plainly. Leave it out if it is unremarkable — a weak rating is worse than no rating.

One resume, many companies

Because you cannot tailor per company, put the general-purpose evidence first and let the specifics sit underneath. Two practical tactics:

• Write the summary for the largest group of recruiters on your calendar — usually software services or product engineering — and keep it factual enough that a bank or an analytics firm reading the same file is not put off.
• Order projects by breadth, not by pride. The project you find most interesting is often the most specialised. Lead with the one that demonstrates the widest applicable skill.

Interview-proof every line

A campus interview is frequently a walk through your own resume, line by line, with fifteen minutes per candidate. Two consequences:

• Do not list a skill you cannot be questioned on for ten minutes. A padded skills line is the most reliable way to lose an interview you were winning.
• Know your own numbers. If a bullet says 300 users, expect “how do you know?” Have the answer. If you estimated, say you estimated and explain how — that answer is respected; a made-up number that collapses under one question is not.

The mechanics, briefly

• PDF, real text, one page, named as the cell asks — and if it does not ask, rollnumber-name-resume.pdf makes their job easier, which is never a bad thing.
• Standard section headings. Companies still run your file through a parser after the cell forwards it. See the ATS resume guide.
• Marks with their scale, and Class XII included — the India fresher format page covers this.
• No declaration, no father’s name, no date of birth — unless the cell’s template has a field for it, in which case fill it in and move on.
• Get one person to read it who is not in your branch. If they cannot tell what you built, a recruiter reading four hundred files will not either.