The Software Engineer Resume, for Indian Hiring

A developer resume is read by two different audiences in sequence, and they want opposite things. A recruiter screens for keywords and level. An engineer, usually the hiring manager, screens for whether you have solved problems like theirs. A resume that only satisfies one of them stalls.

Lead with the stack, but not as a wall

Recruiters do match on technology names, so the stack has to be visible and unambiguous. Group it — languages, frameworks, datastores, infrastructure — rather than emitting one forty-item comma list. Grouping is scannable, and it stops a reader from concluding that you have listed everything you have ever heard of.

Write names the way the industry writes them: PostgreSQL not Postgre, Kubernetes not K8s on a first mention, JavaScript not Java Script. Exact-match keyword filters are literal, and Java versus JavaScript is a real and common misfire.

The bullet format that works

Action, mechanism, outcome. What you did, how you did it, and what changed as a result. The mechanism is where engineering credibility lives — it is the part that distinguishes someone who did the work from someone who was nearby when it happened.

The second version invites a conversation. An interviewer can ask why a composite index, what the cache invalidation looked like, why p99 rather than mean. That is exactly what you want a resume to do — supply the hooks for the interview you are prepared to have.

On scale and numbers

Scale matters in this field more than most, because the same job title means very different work at different volumes. Where you legitimately have the numbers, use them: requests per second, dataset size, table row counts, team size, deployment frequency, uptime.

Where you do not have them, do not invent them. Inflated figures fail the moment an interviewer asks a follow-up, and they always ask. If you genuinely do not know the traffic your service handled, describe the scope you can defend instead — the number of services, the size of the codebase, how many engineers depended on it.

Projects and open source

For anyone under about three years of experience, projects carry as much weight as employment. Link them, and make sure the link goes somewhere a reviewer can evaluate in thirty seconds — a README that says what it does and why, not a bare repository of unexplained files.

• Link the repository, and the deployed version if there is one.
• Say what problem it solves in one sentence before naming any technology.
• Mention scale or usage if it is real. "Used by about 200 people" beats silence; a fabricated number does not.
• Skip tutorial rebuilds unless you extended them meaningfully — reviewers recognise the standard ones.

What reviewers skip

• Skill proficiency bars. Nobody agrees what four out of five stars in Python means, and graphics often do not survive parsing.
• Every course completed on a learning platform. One or two that are genuinely relevant, at most.
• Long descriptions of the employer. The reviewer is evaluating you, not your last company.
• Objective statements that say you want a challenging role in a reputed organisation.

Formatting that survives parsing

Single column is safest. Multi-column layouts read left-to-right across both columns when converted to text, which interleaves your job titles with your skills list. If you want a sidebar, keep it to contact details and skills — never dates or employers.

Export as PDF with the text layer intact rather than as an image, and avoid heavy letter-spacing or small-caps styling on section headings, which can break extraction so that the heading arrives as separated characters.

ThunderCV’s ATS checker reports exactly what a parser recovers from your file, so you can see whether your headings and dates survived rather than assuming they did.