Sourav Dey

/resources/resume

Resume notes for engineers that get past the six second scan. 📄

I have reviewed a lot of resumes in mentorship sessions, and the same six or seven problems come up nearly every time. This page is the version of that feedback I wish I could hand over before the call: what the first pass actually looks at, how to write a bullet that proves something, how to find numbers when you think you have none, and what to do when your experience still feels too thin to fill a page.

How the first pass actually works

The famous six second figure comes from a small eye tracking study, and it gets misread constantly. Six seconds is not how long someone reads your resume. It is how long they take to decide whether to read it at all. Everything in this section is about winning that decision.

The four things the first look checks

In that first pass, a recruiter is answering one question: does this person plausibly do the job we are hiring for? They resolve it from a very small number of fields, and most of your page is invisible at this stage.

  • Your most recent title, and the company you did it at.
  • Dates, specifically how long you have been in the current role and the one before it.
  • One confirming signal: a language, framework, domain, or scale that matches the requirement they care most about.
  • Whether the layout lets them find those three things without hunting for them.

Load the top third of page one

Almost all of that triage happens in the top third of the first page. If your strongest evidence sits on page two, or below a long skills dump, it may as well not exist. Treat that space as the most expensive real estate you own.

  • Contact block on one or two lines: name, city and country, email, phone, LinkedIn, GitHub or portfolio. Plain text, inside the document body, never in the page header.
  • Two or three lines of summary stating what you are, your years of experience, your primary stack, and one concrete result. Skip it only if you are a new grad with nothing yet to summarize.
  • Then your most recent role. For a new grad, a compact skills line followed by projects.
  • Nothing decorative above the fold: no photo, no quote, no objective statement about your career aspirations.

Six seconds is a gate, not the whole review

Resumes that pass the first look get read properly, often for several minutes, then again by the hiring manager. So you are writing for two very different readers, and they want opposite things.

  • The skim wants structure: consistent headings, bold titles, dates in the same place on every entry, one column.
  • The real read wants substance: every bullet carrying a result, a number, or a technical decision.
  • If a line serves neither reader, cut it.

Your resume has one job in the first six seconds: make it obvious, without any effort from the reader, that you already do the work described in the posting.

Formatting that survives every screen

Two things read your resume: parsing software and a tired human. The same plain structural choices satisfy both. First, drop one myth. Applicant tracking systems are not silently binning three quarters of applications, and when recruiters are surveyed directly, the large majority say their system ranks and organizes candidates while humans do the rejecting. What bad formatting genuinely costs you is a garbled profile in their database, which makes you unfindable later and unconvincing now.

One column, top to bottom

Parsers read a page as a single linear stream of text. A two column layout gets read straight across, so your skills sidebar interleaves with your job history and arrives as nonsense. This is the most common self inflicted wound I see, and it almost always comes from an attractive template.

  • No columns, no sidebars, no tables, no text boxes, no shapes.
  • Keep your name and contact details in the document body. A meaningful share of systems skip page headers and footers entirely.
  • No icons next to your email or phone. They either vanish or arrive as junk characters.
  • Page numbers in the footer are fine. Anything you need parsed is not.

Use the boring section headings

Parsers recognize conventional headings and map what follows into the right field. Creative labels break that mapping, and the human skimming your page does not enjoy them either.

  • Safe: Summary, Experience or Work Experience, Projects, Skills or Technical Skills, Education, Certifications, Publications.
  • Avoid: My Journey, Where I Made a Dent, Tech Arsenal, What I Bring to the Table.
  • One heading level only. Do not nest subheadings inside Experience.

The section order I actually recommend

Order sections by what earns you the interview, not by the chronology of your life. Two orders cover almost everyone.

  • Under two years of experience, or still studying: Contact, Skills, Projects, Experience or Internships, Education.
  • Two years or more: Contact, Summary, Experience, Skills, Projects (only if they still add something), Education.
  • Education drops to the bottom the moment you have real work to show, and it stays there for the rest of your career.
  • Inside Experience, reverse chronological always. Grouping by technology hides your dates, and hidden dates read as something being hidden.

Typography and spacing that buy you room

Most one page problems are spacing problems, not content problems. You can usually recover a third of a page without deleting anything worth keeping.

  • A common system font: Calibri, Helvetica, Arial, Georgia, or Charter. Body text at 10 to 11.5 points, your name at 18 to 24.
  • Margins between 0.5 and 0.75 inches on every side. Below 0.5 it feels cramped and prints badly.
  • Tighten line spacing to roughly 1.0 or 1.15 and add space between entries instead. White space between blocks reads as organized. White space inside a paragraph reads as padding.
  • Never shrink body text below 10 points to fit. That is a signal you have avoided deciding what matters.

Export it and name it properly

Send a text based PDF unless the portal asks for something else. Exported from Google Docs, Word, Pages, or LaTeX, it contains selectable text and parses cleanly. A PDF that is really an image, exported from a design tool or scanned from paper, contains nothing a parser can read.

  • Open your PDF, select all, and paste it into a plain text editor. If the order is scrambled or text is missing, so is the version that lands in their database.
  • Keep a Word copy of the same content for portals that only accept .docx, and for recruiters who want to annotate it.
  • Name the file so it is findable in a folder of five hundred: Firstname_Lastname_Frontend_Engineer_Resume.pdf, not resume_final_v3.pdf.
  • Never use white text or hidden keyword blocks. They show up plainly in the parsed output, and they end the conversation.

Boring, single column, text based, conventionally labeled. Save your design instincts for your portfolio site.

Bullets that prove impact

This is where nearly every resume I review is losing. The work is genuinely good and the bullets describe duties instead of outcomes. A duty tells me what you were assigned. An outcome tells me what changed because you were there.

The shape I want every bullet to have

The most reliable pattern is the one Google's former head of people operations popularized: accomplished X, as measured by Y, by doing Z. Result first, evidence second, method third. Most engineers write it backwards, leading with the technology and burying the outcome at the end.

  • Before: Responsible for improving the performance of the customer dashboard using React and memoization.
  • After: Cut customer dashboard load time from 4.2s to 1.3s by memoizing the chart pipeline and moving filtering to the server, clearing the most reported complaint in support tickets.
  • The test: read only the first six words of a bullet. Do they contain something that changed?

Three more rewrites to steal the pattern from

Same job, same facts, different framing. None of the after versions add anything untrue. They just refuse to stop at the activity.

  • Before: Worked on migrating the legacy payment service to microservices. After: Led the payment service migration onto three services, cutting deploy time from 40 minutes to 6 and removing the weekly release freeze for a team of nine.
  • Before: Wrote unit tests to improve code coverage. After: Raised billing module coverage from 34 to 81 percent and reduced regression bugs reported in billing from roughly six a month to under one.
  • Before: Participated in code reviews and mentored junior developers. After: Reviewed around 20 pull requests a week and onboarded three new hires, two of whom were shipping independently inside their first month.

Lead with the verb and delete the padding

Every bullet starts with a past tense verb that claims ownership. Anything sitting before that verb is wasted words in the only column the reader is scanning.

  • Delete on sight: responsible for, worked on, helped with, involved in, tasked with, various, successfully, utilized, leveraged, in order to.
  • Use verbs that carry a claim: built, shipped, led, designed, migrated, cut, raised, automated, instrumented, rewrote, unblocked, negotiated.
  • Do not repeat a verb inside one role, and use none more than twice on the whole page.
  • Present tense for your current role only. Past tense everywhere else, applied consistently.

Keep STAR for the conversation, not the page

STAR, meaning situation, task, action, result, is an interview structure. On paper it becomes four sentences of setup for one sentence of payoff, and nobody reads it. Compress it: keep the action and the result, imply the situation, drop the task entirely.

  • On the page: one line, action plus result, with just enough context to make the result mean something.
  • In the interview: the full arc, including what was hard, what you tried that failed, and what you would do differently.
  • Rule of thumb: every bullet should be a question you would be glad to spend ten minutes on.

How many bullets, and how long

Density beats completeness. A role with four sharp bullets outperforms the same role with eight, because eight makes the reader find the good ones themselves and they will not bother.

  • Current or most recent role: four to six bullets.
  • The role before that: three to four.
  • Anything older than roughly five years: one or two, or a single line naming the role with no bullets at all.
  • One line per bullet, two at the absolute most. A bullet that wraps to a third line is either two bullets or too vague.
  • Roles older than about ten years, or irrelevant to where you are heading, collapse into one Earlier Experience line listing titles, companies, and years.

If a bullet would still be true had you done nothing all quarter, it is not a bullet. It is a job description.

Numbers when you think you have none

Almost every mentee tells me their work cannot be quantified, and almost every one of them is wrong. You are not looking for a revenue figure. You are looking for a fact about size, speed, frequency, or change that a reader can picture.

Five places a number is usually hiding

Walk through your last two years of work and answer these five questions for each significant thing you did. Most items will yield at least one usable figure.

  • Scale: how many users, requests per second, records, services, repositories, endpoints, or devices did it touch?
  • Speed: what was the before and after on latency, build time, page load, deploy duration, or time to resolve?
  • Frequency: how often did you do it? Pull requests a week, releases a month, on call rotations, interviews conducted.
  • Size of what you owned: team size, number of stakeholders, the module or service you were named owner of, infrastructure spend.
  • Reduction: bugs, support tickets, manual steps, flaky tests, alerts, or duplicate code you removed.

Reconstruct, never invent

You can rebuild a number you never recorded. Go back through your pull requests, dashboards, sprint boards, release notes, and old chat threads. What you cannot do is guess, because the interview is exactly where a guess gets tested.

  • The only test that matters: if someone asks how you arrived at that figure, can you answer in one sentence?
  • A reconstructed number is honest. Signal the estimate with about, roughly, or a range: roughly 15 thousand daily users, about a third of the test suite.
  • An invented number is unrecoverable. One vague answer about your own bullet and the reader stops trusting the entire page.
  • If you genuinely cannot establish a figure, describe the change qualitatively and precisely instead. A specific true sentence beats a fabricated percentage every time.

You do not need a metric on every line

Forcing a number into every bullet produces writing that is obviously padded. Aim for three to five genuinely quantified anchors across the whole resume, ideally one in the first bullet under each recent role. The rest just need to be specific.

  • Put the quantified ones first. The opening bullet of each role is the one people actually read.
  • Do not stack two unrelated numbers in one bullet. A before and after pair is the exception.
  • Percentages need a base to mean anything. Improved throughput by 200 percent, from a base of two requests a second, is not a claim.

What this looks like for engineering work specifically

Engineering has far more measurable surface than most jobs. These are the metrics I most often find hiding in a mentee's work once we go looking for them.

  • Performance: p95 latency, bundle size in kilobytes, Core Web Vitals scores, cold start time, query time, memory footprint.
  • Reliability: incident count, error rate, uptime, mean time to recovery, pages per on call week, rollbacks avoided.
  • Developer productivity: CI duration, local build time, flaky test count, engineers unblocked, files or lines deleted.
  • Product: activation or conversion on a flow you built, feature adoption, retention on a surface you owned, support tickets tied to your area.
  • Cost: cloud spend, license spend, hours of manual work removed per week, engineering time freed.

Every quantified line is a claim you are inviting someone to interrogate. Write only the ones you would enjoy defending.

Tailoring without rewriting

Tailoring gets recommended constantly and explained almost never, so people either skip it or lose an evening per application. Here is the version that takes fifteen minutes and does most of the work.

The fifteen minute pass

Keep one master resume containing everything you have ever done, far longer than you would ever send. Every application is a copy of the master, cut down and reordered. You are selecting and resequencing, not writing.

  • Read the posting twice and mark the five requirements it repeats or puts first. Those five are the actual job.
  • For each one, find the bullet on your master that proves it. If the proof exists but sits below the fold, move it up.
  • Rewrite your summary lines so the role title and their top two requirements appear there, in their words.
  • Reorder your skills lines so their stack comes first, and delete whatever this posting makes irrelevant.
  • Cut whatever the reordering pushed onto a second page and cannot justify being there.

Mirror their vocabulary where it is genuinely true

Recruiters search their database by keyword, and screeners match against the posting. If they write one term and you write a synonym, you lose the match for no reason at all. This is not gaming anything. It is using the same word for the same thing.

  • Match the exact string: if they write PostgreSQL, do not write only Postgres. If they write TypeScript, do not write only TS.
  • Where a term has two common forms, use both once across the page: Continuous Integration (CI), Kubernetes (K8s), Amazon Web Services (AWS).
  • Put the keyword inside a real bullet as well as in your skills line. Context is what convinces the human reading it.
  • Titles too. If your internal title is Product Engineer II and the market calls the role Frontend Engineer, write Frontend Engineer (Product Engineer II).

Version it and track it

Once you are applying to twenty places, the admin becomes the failure mode. A dull system beats memory every time.

  • One master file, then per application copies named Company_Role_Resume.pdf.
  • Keep a sheet with company, role, date applied, resume version, and the five requirements you targeted. It doubles as your interview prep sheet.
  • Reuse aggressively. After ten applications you will have three or four variants that cover most postings with minor edits.

What tailoring is not

Two failure modes, both common, both obvious from the other side of the table.

  • It is not keyword stuffing. A skills section listing forty technologies signals that none of them are real.
  • It is not claiming experience you do not have. Every line on the page is a question you have agreed to answer.
  • It is not starting over each time. If tailoring takes you two hours, your master file is not doing its job.

Tailoring means a reader recognizes their own posting in your top third within seconds. There is nothing more mystical to it than that.

The skills section, done honestly

The skills section is the easiest part of a resume to get wrong, because it feels like free space to look impressive. It is actually where you are most likely to lose credibility.

Group it, and put their stack first

A flat alphabetical wall of technologies tells the reader nothing about what you are. Group into three or four labeled lines so someone can place you in two seconds.

  • Languages: TypeScript, JavaScript, Python, Go
  • Frontend: React, Next.js, Redux Toolkit, Tailwind CSS, Vite
  • Backend and data: Node.js, PostgreSQL, Redis, GraphQL, REST
  • Tooling and infrastructure: Docker, GitHub Actions, AWS (Lambda, S3, CloudFront), Playwright, Jest
  • Separate items with commas or vertical bars. Do not build this as a table, a grid, or anything with columns.

Only list what you would defend in an interview

Assume every item is fair game for a follow up question. If you used Kafka once in a tutorial, it does not go on the page, because the cost of one bad answer is much higher than the benefit of one extra keyword.

  • The bar: you can explain a real decision you made with it, and one thing about it that surprised you.
  • If a posting requires something you are shaky on and you want to include it, be explicit: Familiar with, or Learning.
  • Anything genuinely core to you should also appear inside an Experience or Projects bullet, not only in this list.

What to cut

Most skills sections are a third longer than they should be. These are the lines I delete on almost every resume I review.

  • Proficiency bars, star ratings, and percentages. They are unverifiable, they were invented on the spot, and they do not parse.
  • Git, VS Code, npm, and Postman. Nobody is hiring for those, and listing them makes your real items look inflated.
  • HTML and CSS once you are past a couple of years, unless you are applying for frontend work where they are still genuinely the craft.
  • Microsoft Office, Windows, and typing speed. Also soft skills as a list: team player, hard working, quick learner. Your bullets either prove those or they do not.
  • Spoken languages, unless the role or the country actually needs them.

Your skills section should read like an honest index of your bullets, not a wishlist of what you would like to be asked about.

When you do not have much experience yet

New grads, career switchers, and people whose current job does not resemble where they are going all share one problem: the Experience section is thin or misleading. The answer is never to inflate it. It is to change what the page leads with.

Promote projects and treat them like jobs

Under roughly two years of experience, a strong Projects section carries more weight than your degree and often more than an internship. The usual mistake is formatting projects as a list of technologies. Format them exactly like a role: a name, one line on what and why, then bullets with outcomes.

  • Header line: project name, your role if it was a team effort, the stack in brackets, and the month range.
  • First bullet: what it does and who it is for, in one sentence someone outside engineering would understand.
  • Then two or three bullets on decisions and results rather than features. What did you choose, what did it cost, what did it achieve?
  • One link per project: a live deployment if there is one, otherwise a repository with a real README. A dead link is worse than no link.

What makes a project worth putting on the page

Three projects maximum, and the selection matters far more than the count. I would take one small tool with forty real users over three polished tutorial clones every time.

  • Someone other than you used it, even if that is five people. Say so, with the number.
  • You can describe the problem it solves in one sentence, without the phrase to learn React.
  • It is deployed and still works today, or the repository has tests, a README, and a commit history that shows real iteration.
  • Cut anything that exists in ten thousand near identical copies. Todo apps, weather dashboards, and calculator clones read as coursework, not evidence.
  • If two projects prove the same thing, keep the one where you owned more of the decisions.

A project entry, before and after

The pattern is the same as for a job. Say what changed, for whom, and how you decided.

  • Before: Built a full stack expense tracker using React, Node.js, and MongoDB with authentication and charts.
  • After, first bullet: Built and deployed an expense splitting tool used by roughly 60 people across two hostels, replacing a shared spreadsheet that took an hour to reconcile each month.
  • After, second bullet: Chose optimiztic updates over polling to keep it usable on slow mobile connections, and covered the split logic with 40 unit tests after an early rounding bug.
  • The gain is not the word count. It is that the reader now knows who used it, what it replaced, one decision you made, and one thing that went wrong.

Internships, freelance, and unpaid work all count

If it involved shipping something for someone who was not you, it belongs in Experience, not buried in an Other section. Be accurate about the arrangement and stop apologizing for it.

  • Title it honestly: Software Engineering Intern, Freelance Frontend Developer, Open Source Contributor, Volunteer Developer. Include the organization and the month range.
  • Freelance and contract work: name clients if you are allowed to, otherwise write Freelance Frontend Developer (four clients) and describe the work.
  • Open source: name the project, point to the merged pull requests, and say what the change did. One merged fix in a project people use beats twenty personal repositories.
  • Teaching assistant, hackathon, and campus club work counts when you built or led something real. It does not count as a list of memberships.

Education, GPA, and coursework

Education is a fact, not an argument. Keep it small and let it slide down the page as your work grows.

  • Degree, institution, graduation year. Location optional. That is the whole entry once you have a job.
  • Include GPA only within roughly two years of graduating, and only if it is genuinely strong. Use your local convention and never round upward.
  • Relevant Coursework earns space only when you have no projects and no internships, and then only four or five courses that map to the posting.
  • Drop high school entirely once you hold a degree. Drop the school activities list the moment you have shipped anything.

Thin experience is a sequencing problem, not a credibility problem. Lead with the strongest evidence you have, whatever section it happens to live in.

Gaps, short stints, and the parts you are dreading

Every mentee has one thing on their timeline they want to hide, and hiding it always costs more than naming it. An unexplained hole invites the worst available interpretation. One plain line closes it.

Name a long gap in one line and move on

For anything over about six months, add an entry in Experience using the same format as a job. No apology, no account of how you felt, no essay. State the period, the reason in a few words, and anything relevant you did.

  • Career Break, 2024 to 2025. Full time caregiving. Completed a backend fundamentals course and shipped two small internal tools during this period.
  • Career Break, March 2025 to September 2025. Planned break after a role ended. Contributed to two open source projects and prepared for backend interviews.
  • Say the true thing in neutral words: caregiving, health, relocation, redundancy, study, parental leave, visa transition, national service.
  • Never manufacture a consultancy to cover the period. It is the easiest thing in the world to unravel in a reference check.

Short gaps usually need nothing at all

Under about six months, most readers do not register a gap, and explaining it creates a question that did not previously exist. There is one formatting choice that quietly helps here.

  • Use month and year on recent roles, and year only on roles older than about five years.
  • If you use year only consistently across the whole page, a four month gap simply disappears. Be consistent, because a mix of date formats reads as concealment.
  • Do not stretch dates to close a gap. Dates are the one thing a background check verifies precisely.

Short stints, layoffs, and multiple roles

One short role is nothing. Three in a row is a pattern the reader will price in, so put the reason on the page instead of making them guess at it.

  • Add a short parenthetical where a role ended structurally: (role eliminated in company wide layoff), (fixed term contract, six months), (startup ceased operations).
  • If a stint was genuinely a mistake, keep it, keep it to one line, and prepare a calm twenty second answer. Deleting it creates a gap, which is worse.
  • Consecutive roles at one company go under a single company heading with titles and dates listed beneath it. That shows progression instead of looking like churn.
  • Contract and agency work: label it as such, because six month tenures are expected there and unlabeled they read as job hopping.

Switching in from another field

The switcher's real problem is that a screener cannot tell in six seconds what you are now. Fix that before you worry about anything else on the page.

  • Your summary states the target role in the first four words, then the transferable evidence: Frontend engineer with two years of production React, previously five years in mechanical design.
  • Translate the old work into the vocabulary of the new one, but only where it is honestly the same skill: requirements gathering, stakeholder management, debugging under pressure, working to a specification.
  • Compress the previous career into one or two lines and keep only the parts that transfer. It is context, not the case for hiring you.
  • Put the strongest new signal on page one: production code you have shipped, a certification the field genuinely respects, or a project with real users.

You are not hiding anything. You are making sure a reader reaches the right conclusion without having to speculate.

The pass before you send it

A resume is not finished when the writing is good. Most of the rejections mentees tell me about afterwards trace back to something mechanical that ten minutes would have caught.

Proofread in a way that actually works

You cannot proofread your own resume by reading it, because you already know what it says. A large share of hiring managers say they discard resumes over typos, which makes it the cheapest possible way to lose.

  • Read it aloud, slowly. Your mouth catches what your eye skips over.
  • Read the bullets bottom to top so familiarity stops helping you.
  • Check what spellcheck cannot: company names, product names, framework capitalization (JavaScript, TypeScript, Node.js, PostgreSQL, GitHub), and your own phone number.
  • Have one other person read it, ideally an engineer who does not know your work. They will spot the bullets that only make sense from inside your team.

The consistency sweep

Inconsistency reads as carelessness even when the reader cannot articulate why. Pick one convention per item and apply it everywhere.

  • Dates: one format across the page. Mar 2024 or 03/2024, never both.
  • Punctuation: full stops on every bullet, or on none. Do not mix.
  • Tense: present for the current role only, past for everything else.
  • Numbers: one style for figures and units. 40% or 40 percent, 1.3s or 1.3 seconds, 15k or 15,000.
  • Bold: exactly one thing bolded consistently, usually job titles or company names. Bolding half a bullet for emphasis is noise.

Test it like you would test a system

Four checks, ten minutes, and they catch the failures that are invisible on your own screen.

  • Copy the whole PDF into a plain text editor and read what comes out. That is much closer to what lands in their database than what you see.
  • Open it on a phone. A meaningful share of first reviews now happen on mobile, and 10 point text in a dense block is unreadable there.
  • Print it, or preview it, in grayscale. If color was carrying your visual hierarchy, it has just gone.
  • Click every link, from the exported PDF, in a private window. Broken portfolio links and dead repositories are extremely common and completely fatal to the point you were making.

The questions I ask at the end of every review

This is genuinely what I check when I finish reading a mentee's resume. If the answers are not obvious from the page alone, no amount of polish will fix it.

  • Can I say what you are and what you are good at after reading only the top third? If not, the summary and your first role need work.
  • For each of the top five requirements in the posting, can I point at the line that proves it? If not, you are not tailored, you are just submitted.
  • Is there a single line here you would not want to spend ten minutes discussing? Cut it now, not in the interview.

Send it when a stranger could describe your last two years accurately after twenty seconds with the page. That is the entire bar.