How to Write Resume Bullets That Actually Get You Shortlisted
Most Indian student resumes describe what someone did. The ones that get shortlisted describe what resulted from what they did.
This is not a small difference. A recruiter spends roughly nine seconds on a resume — enough time to scan six to eight bullet points and decide whether to keep reading. "Developed a web application using React and Node.js" loses that decision. "Built a React + Node.js food-delivery app handling 500 daily orders — cut average checkout time by 35% after a UX redesign" earns it. Same project, same technology, completely different signal.
This post shows you exactly how to write the second kind, with concrete before/after rewrites for the four roles that dominate shortlisting season in India.
What recruiters are actually trying to figure out
Recruiters are not reading your resume to understand your responsibilities. They are reading it to answer one question: can this person produce a result, or do they just complete tasks?
"Responsible for database management" is a task description. "Reduced query time by 60% by rewriting N+1 queries in the reporting module" is a result. The person who wrote the second bullet is not necessarily more impressive — they just showed their work differently.
The second thing bullets do is anchor your interview conversation. A vague bullet ("worked on ML model") leaves nothing to ask about. A specific bullet ("trained a gradient boosting model on 200K rows of clickstream data that predicted churn with 82% precision") hands the interviewer a ready-made question: How did you handle class imbalance? What features mattered most? Those are questions you have already answered by doing the work. Vague bullets produce vague follow-ups, which you scramble to answer in real time.
Most candidates treat resume bullets as a summary of what they did over the past year. The ones who get shortlisted treat each bullet as a pitch for why an interviewer should bring up exactly that story.
The XYZ formula
Google's recruiting team popularised this structure:
Accomplished [X], as measured by [Y], by doing [Z].
You don't have to use it verbatim, but the three components are what make a bullet land:
- X — what you built or achieved
- Y — how you know it worked (a metric, a scale, an outcome)
- Z — what specifically you did to get there
The majority of student resumes have X and Z but no Y. That missing metric is what separates a description from evidence.
If you don't have a precise number, estimate and say so. "~500 users", "roughly halved the time", "handled 3,000+ registrations" — an honest rough figure is more credible than a precise-sounding fabrication. Recruiters probe the numbers that sound too clean. If you genuinely cannot put a number on something, focus on scope ("across 4 college departments") or a qualitative outcome ("replacing a fully manual paper process"). What you must never do is leave the bullet as pure activity with zero signal of what changed.
Before/after: the same project, rewritten
Here is a real-shaped bullet from a typical NIT/IIT student resume, then the same information rewritten with XYZ:
Before:
Developed a hostel management system for the college using React, Node.js, and MongoDB.
After:
Built a hostel room-allocation system used by 1,200+ students, replacing a paper-based process and cutting allocation disputes from ~15/week to fewer than 2 — built with React, Node.js, and MongoDB.
Why the second one works:
- Scale ("1,200+ students") makes the project real, not a toy.
- Impact (replaced a paper process, cut disputes) shows that something actually changed in the world.
- Technology is still there, but it is at the end of the bullet, not the headline — because what you built matters more than what you used to build it.
Same student. Same project. The second version gets a recruiter's attention; the first gets scrolled past.
Full examples by role
The XYZ structure is universal. What you emphasise inside it changes by role.
SDE / Software roles
Technical recruiters for SDE positions care about scale, performance, and evidence that you understood the hard parts. Numbers that land: concurrent users, latency improvements, test coverage added, code complexity reduced.
Weak:
Implemented authentication module for an e-commerce platform.
Strong:
Built JWT-based authentication with refresh-token rotation for an e-commerce app; load-tested to 2,000 concurrent logins on a single t3.medium with zero token collisions — used Node.js, Redis for token blacklisting.
The phrase "zero token collisions" is the result. "Load-tested to 2,000 concurrent logins" is the scale. Together they tell a recruiter you understood what security actually requires — not just that you wired up a library.
Weak:
Worked on optimising database queries.
Strong:
Reduced API response time from 1.8s to 320ms by converting 14 ORM-level N+1 queries to raw SQL joins; profiled with Django Debug Toolbar before each change.
That second bullet is worth ten minutes of interview time on database optimisation — exactly the conversation a strong SDE candidate wants to have.
Data / Analytics roles
For data roles, the most common failure is stopping at the model. Libraries are nearly irrelevant; business outcomes are everything. Numbers that land: dataset size, model precision/recall, error reduction, and — most valuable — the decision that your analysis drove.
Weak:
Created a churn prediction model using Python and scikit-learn.
Strong:
Trained a gradient boosting churn model (82% precision, 78% recall) on 18 months of 400K customer records; findings revealed 60% of churn was concentrated in the first 30 days, driving a redesign of the onboarding email sequence that reduced 30-day churn by 12% the following quarter.
What makes this work: it does not stop at accuracy metrics. It connects the model to a business change. A data candidate who can name the decision their work influenced is rare — most can only name the algorithm.
Weak:
Analysed sales data and presented findings to the team.
Strong:
Identified a 23% revenue concentration in three SKUs through two years of cohort analysis on 180K transactions; presented findings to the category head, which led to a SKU rationalisation freeing up ₹40L in working capital.
The rupee figure is specific enough to be memorable and defensible. If an interviewer asks how you calculated it, you can walk them through the inventory days × unit cost arithmetic. That is exactly the kind of follow-up you want.
Product / APM roles
PM-track recruiters are looking for three things in every bullet: evidence of user empathy, a metric that proves something worked, and some sign that you influenced people beyond yourself. Your technical projects absolutely count here — frame them as product decisions, not engineering ones.
Weak:
Managed a college fest app and handled registrations.
Strong:
Led a 3-person team building the college fest registration app; simplified the sign-up flow from 12 fields to 4, which lifted form-completion rate from 61% to 87% and handled 3,200 registrations on the day without downtime.
Weak:
Conducted user research for a product design course project.
Strong:
Ran 8 user interviews and a 120-response survey for a fintech app redesign; identified that 70% of drop-offs occurred at the OTP confirmation step, which drove a redesigned flow that cut prototype drop-off by ~40% in moderated usability testing.
Both bullets show the PM reflex: find where users get stuck, measure it, fix it, measure again. That loop — not the Figma skill or the familiarity with PRDs — is what APM interviewers are hiring for.
Consulting / Non-tech roles
In consulting resumes the currency is structured analysis, a defensible recommendation, and a business result. Case competition placements are highly credible signal — but only if you name the competition, the client situation, and what you actually recommended, not just that you "participated."
Weak:
Participated in a national case competition and worked on a strategy for a retail client.
Strong:
Reached national finals of XL-IMIT CaseComp 2025 (top 6 of 340 teams); recommended a tier-2 city expansion strategy backed by a unit-economics model showing 18-month payback — judged best-supported recommendation by a panel of three industry judges.
Weak:
Handled social media for a student club.
Strong:
Grew the club's Instagram from 400 to 2,800 followers in 4 months by switching to a weekly case-snippet format; average post reach increased 6× versus the prior semester, and follower demographics shifted to 80% final-year students (the target audience).
The demographic detail in the second consulting bullet matters: it shows you defined a goal, measured against it, and could tell the difference between vanity growth and useful growth.
Common mistakes — and how to fix each
Mistake 1: The "Responsible for" frame
This is the single most common resume failure. "Responsible for managing the team's Jira board" tells a recruiter only that you were assigned a task. Every bullet must start with an action verb and end with a result. Replace every instance of "Responsible for X" with "Did X, which resulted in Y." If you cannot name a result, the bullet probably should not exist.
Mistake 2: Technologies as achievements
"Used React, Redux, Node.js, Express, MongoDB, and Docker to build a web app" is a shopping list, not evidence. Technologies belong at the end of a bullet as context, after the outcome, not at the start as the headline. What you built matters more than what you used to build it.
Mistake 3: Coursework and certification bullets without outcomes
"Completed a 40-hour Python certification on Udemy" has near-zero signal — every resume in the pile says something similar. If a course led to something tangible — a project, a skill you applied in an internship, a competition placement — say that. If not, cut it. Filler bullets crowd out your real evidence and dilute the page.
Mistake 4: One resume for every role
A data-heavy resume sent to an SDE team looks unfocused. You don't need five versions, but you do need to reorder and reframe for each role family. Your top two bullets should be the two most relevant to this job description, not your two most impressive things in the abstract. Before each application, spend ten minutes putting your most relevant bullet first.
Mistake 5: Fabricating or inflating numbers
"Improved performance by 300%" sounds impressive until the interviewer asks how you measured the baseline. Recruiters probe numbers that sound suspiciously round or dramatic. If you cannot explain the denominator, do not put the percentage. Use honest estimates you can defend — "roughly 2× improvement", "~500 active users", "cut errors by about half" — and be prepared to walk through how you estimated.
What to do this week
Day 1. Open your resume and mark every bullet that:
- Starts with "Responsible for", "Assisted with", or "Helped"
- Has no number, metric, or scale anywhere in it
- Leads with a technology name rather than what you built
That's your rewrite list.
Days 2–3. Pick the three bullets that would come up in your interviews — the ones you'd point to if an interviewer asked "walk me through your strongest project." Rewrite each one using XYZ. You will need to dig for numbers: check commit logs, ask your project partner what the user count was, look up the competition results, estimate the time saved. The research is part of the exercise.
Day 4. Read each rewritten bullet aloud and ask: could an interviewer ask me a hard, specific follow-up question about this? If yes, the bullet is working. If the answer to "tell me more" is still vague, it needs another pass.
Three bullets rewritten properly is a more useful hour than a full resume refresh done shallowly.
CareerClutch's resume tool flags vague bullets, missing metrics, and technology-first framing automatically — so you can see at a glance which lines are doing work and which are noise. But the rewrite itself is yours. Open your resume today, find the first bullet that starts with "Responsible for," and rewrite it before you close the tab. One bullet at a time is how a shortlist-worthy resume gets built.