Sections hiring managers expect
Summary with level and stack (e.g., backend, frontend, full-stack). Experience reverse-chronological. Education. Skills grouped by language / framework / infra. Optional: Open source, Publications if relevant.
Skip photos and skill bars. List proficiency in prose through bullets, not self-rated stars.
Verum Tech Blue and Minimal templates keep a skills-forward layout without columns.
Bullet formula
Action verb + what you built + stack + outcome you can prove. “Shipped React checkout flow reducing client-side errors” only if you measured or can describe the fix in an interview.
Avoid listing every daily tool in every bullet. Put primary stack in Skills; bullets show impact.
Internships: treat like full roles with company name, team if known, and merged PR or feature outcomes.
Keywords for engineering postings
Languages, frameworks, cloud, databases, testing, CI/CD, observability tools. Match posting literals: Kubernetes vs k8s, PostgreSQL vs Postgres.
System design terms belong when you used them — “Designed REST API” not “microservices expert” without shipped services.
Use keyword match against each listing before apply.
Senior vs junior signals
Senior: scope (team size, cross-team), reliability, mentoring, tradeoffs. Junior: learning speed, shipped features, tests written, code review participation.
Do not claim staff-level scope from intern work. Title inflation fails background checks.
Portfolio and links
One line in header: GitHub, portfolio, LinkedIn. Ensure links work. README on pinned repos should explain what the project does.
Remove dead links before batch applications.
Open source and side projects
List repos you actively maintain or where you merged meaningful PRs. “Contributor, project name, N merged PRs fixing X” beats starring popular repos you never touched.
Capstone apps should name auth, database, deployment, and users if any. “Deployed on Vercel with Postgres” signals production thinking.
Do not claim team size you did not have. Solo projects labeled honestly still pass screens for junior roles.
Interviews vs resume depth
Resume gets you the screen; interviews probe depth. Every major stack on the resume should have one story ready: tradeoff, bug, performance fix, or design decision you owned.
Remove tools you used once in a tutorial unless the posting is explicitly junior and lists them as nice-to-have.
Staff-level buzzwords (org-wide platform, multi-region) require matching scope in experience — trim if your role was feature team only.
Contract and freelance engineering
List client or agency name when allowed by contract. NDA clients can be “Confidential fintech client via Agency X” with truthful stack and outcomes.
Short contracts merge visually if you had six two-month gigs — group under consulting header only if legally accurate.
1099 vs W2 does not change bullet honesty; dates and deliverables still must verify.
Stack ordering on the page
Put languages first if the posting leads with language requirements; otherwise lead with frameworks you used in production last year.
Infra and observability tools belong in Skills even when bullets focus on product features — parsers often match Skills first.
Remove deprecated stack unless the posting still requires maintenance work on legacy systems you truly supported.
Mention code review and testing practices in bullets when the posting emphasizes quality — only with examples you can explain live.
Remote and timezone signaling
Remote postings may filter on location — put city and country in the header if you match their allowed regions; do not spoof location.
List collaboration tools you used across time zones (Slack, Jira, async design docs) when the posting mentions distributed teams.
Open-source contributions with public timestamps show sustained activity between jobs — link the repo once in the header.
Preparing for technical screens
The resume lists topics you may be questioned on — be ready to whiteboard or explain any language claimed in Skills.
System design interviews for senior roles go beyond resume bullets; the resume should not claim architecture you cannot diagram.
Keep a private interview prep doc linked from Verum interview prep tool — separate from the PDF sent to ATS.
Update Skills when you finish a course or ship a feature — stale stacks invite questions you cannot answer.
For on-call experience, name the systems you supported and incident types you handled — not generic availability claims.
List testing frameworks you actually wrote tests in — unit, integration, or end-to-end — with one bullet example each where possible.