Sample OneNo degree · Two shipped projects
No computer science degree and no employer yet. The page is carried by two things that are real and checkable: projects with users, and freelance work that was paid for.
Zeeshan Haider
Frontend Developer
[email protected] · +92 340 2218 774 · Faisalabad, Pakistan · github.com/zhaider · zhaider.dev
Profile
Self-taught frontend developer with two shipped products and eleven months of paid freelance work. Built and maintain a bus-timetable app with 4,200 monthly users, and delivered six client sites on React with zero post-launch rework.
Experience
Freelance Frontend Developer, Self-employed
Oct 2025 — Present
- Delivered six client websites in React and Next.js, all accepted without post-launch rework
- Cut one client’s page load from 4.8s to 1.3s by removing render-blocking assets
- Handle the full cycle: scope, build, deploy on Vercel, and hand over documentation
Education & Training
BS — Commerce (incomplete, 2 years)
GC University Faisalabad
The Odin Project — Full Stack JS
Completed 2025
Shipped Projects
RouteSaathi — bus timetable app
4,200 monthly users · React, Firebase
InvoiceLite — open source
310 GitHub stars · React, IndexedDB
Skills
JavaScriptReactNext.jsTypeScriptTailwind CSSFirebaseREST APIsGitVercelResponsive Design
Why this one works
- Projects have a section, not a mention. With no employment history, shipped work is the experience. Giving it a proper heading with users and stars makes it evidence rather than a hobby.
- User numbers, not descriptions. "4,200 monthly users" is checkable and means someone other than the author found it useful. "A bus app I built" means nothing.
- The incomplete degree is stated. Two years, marked incomplete. Hiding it creates a gap a reader will notice; stating it costs nothing, since nobody is hiring a frontend developer for a commerce degree anyway.
- GitHub and a live site sit in the header. For a candidate with no employer name to lean on, the reader must be one click from proof.
Sample TwoFive years · Full stack
Five years, three employers, and every bullet answers the same question: what changed in production because this person was on the team?
Hamza Ali
Software Engineer
[email protected] · +92 333 9014 662 · Karachi, Pakistan · github.com/hamzaali · linkedin.com/in/hamzaali
Profile
Full-stack engineer with five years building React and Node services. Rebuilt an API layer that cut median response from 800ms to 320ms, shipped a payments integration now handling 15,000 transactions a month, and raised test coverage from 34% to 81%.
Experience
Software Engineer, Systems Limited
Feb 2023 — Present
- Rebuilt the core API layer, cutting median response time from 800ms to 320ms
- Shipped a Stripe payments integration processing 15,000 transactions monthly
- Raised automated test coverage from 34% to 81%, halving production hotfixes
- Mentor two junior engineers through onboarding and first production release
Junior Software Engineer, Netsol Technologies
Jul 2020 — Jan 2023
- Built twelve React dashboards used daily by 2,000+ internal users
- Migrated a legacy jQuery module to React with no interruption to live users
- Introduced pull-request review, reducing defects reaching QA by roughly a third
Education
BS — Computer Science
FAST NUCES · 2020 · 3.6 CGPA
Certification
AWS Certified Developer — Associate
Amazon Web Services · 2024
Skills
JavaScript / TypeScriptReactNode.jsPostgreSQLREST & GraphQLDockerAWS (Lambda, S3, RDS)JestCI/CDGit
Why this one works
- Latency is stated in milliseconds. 800 to 320 is a number an engineering manager feels immediately. "Improved performance" could mean anything at all.
- The payments work leads with volume, not vendor. Fifteen thousand transactions a month is a reliability claim. Naming Stripe alone is just a logo.
- Test coverage carries its consequence. 34% to 81% is a statistic; "halving production hotfixes" is why anyone should care. Pair the metric with the outcome.
- The stack list sits at the bottom. It is there for the keyword search, which is the only job it does. It is not the argument.
Sample ThreeNine years · Backend & platform
At senior level the page stops describing features and starts describing systems, cost and the people who work inside them.
Adnan Rasheed
Senior Backend Engineer
[email protected] · +92 300 5541 208 · Lahore, Pakistan · github.com/adnanr · linkedin.com/in/adnanrasheed
Profile
Backend engineer with nine years on high-traffic platforms. Led the migration of a monolith serving 2.1M monthly users onto services, cutting p95 latency 62% and infrastructure spend by $14,000 a month, while leading a team of five.
Experience
Senior Backend Engineer, Careem
Mar 2022 — Present
- Led the decomposition of a monolith serving 2.1M monthly users into eight services
- Cut p95 API latency 62% and monthly infrastructure spend by $14,000
- Lead a team of five engineers; own the on-call rota and incident review
- Reduced mean time to recovery from 74 minutes to 21 through better alerting and runbooks
Backend Engineer, Bazaar Technologies
Aug 2019 — Feb 2022
- Built the order pipeline handling 40,000 daily transactions at 99.95% uptime
- Introduced database read replicas, removing the primary as a bottleneck at peak
Earlier, Backend developer roles, 2016 — 2019
2016 — 2019
Education
BS — Software Engineering
NUST · 2016
Certification
AWS Solutions Architect — Professional
AWS · 2023
Certified Kubernetes Administrator
CNCF · 2022
Skills
GoPythonNode.jsPostgreSQLRedisKafkaKubernetesAWSTerraformSystem DesignObservabilityOn-Call Leadership
Why this one works
- Money appears. $14,000 a month is $168,000 a year. Senior engineers who can express work in cost terms are read differently by everyone above the engineering manager.
- p95, not average. Averages hide the users having a bad time. Using p95 signals you already think the way a platform team needs you to.
- Mean time to recovery is included. Uptime is table stakes; how fast you recover when it breaks is what distinguishes senior operational judgement.
- Team size and on-call ownership are stated. "Senior" is a title anyone can be given. Five reports and the on-call rota is what it actually means.
Why the stack list does not work
Open twenty developer resumes for the same role and the technology lists will be close to identical. React, Node, Python, SQL, Docker, AWS, Git. The list cannot separate you because it does not vary — and a section that does not vary cannot be a reason to choose anyone.
It is still worth including, because keyword search is real and a recruiter filtering for "Kubernetes" needs the word present. But that is a clerical function, and clerical functions belong at the bottom of the page.
What actually varies between candidates is what they built, how many people used it, what broke, and what happened to the numbers afterwards. That is the top of the page.
How to quantify engineering work
The usual objection is that engineering is not measurable. It is the most measurable work in any office — the measurements are simply in dashboards nobody opens while writing a resume.
- Latency. Before and after, in milliseconds, and use p95 or p99 rather than average.
- Throughput. Requests per second, transactions per month, daily active users touched.
- Reliability. Uptime, error rate, incidents per quarter, mean time to recovery.
- Cost. Monthly infrastructure spend removed. This one travels furthest up the org chart.
- Quality. Test coverage, defects reaching QA, hotfixes per release.
- Delivery. Build time, deploy frequency, lead time from merge to production.
- People. Engineers mentored, reviews given, runbooks written.
If you truly have no numbers, use scale instead: team size, user count, codebase age, service count. "A four-year-old monolith serving 2.1M users" tells a reader plenty before a single metric appears.
Applying without a degree
A computer science degree is a filter at some companies and irrelevant at many others. The mistake self-taught developers make is not the missing degree — it is trying to disguise it, which produces a resume full of soft language and short on evidence.
The replacement for a degree is shipped work that other people use. Not tutorials completed, not courses watched — deployed things with users. One project with 4,000 real users outweighs fifteen exercises from a curriculum.
Give projects a proper section with a heading, and give each one a number: users, stars, downloads, clients, or revenue. Put your GitHub and a live URL in the header so proof is one click away. And state an incomplete degree plainly — an unexplained gap costs more trust than the incomplete degree ever will.
Four rewrites for engineers
Weak
Worked on improving the performance of the backend API.
Strong
Rebuilt the core API layer, cutting median response time from 800ms to 320ms.
"Worked on" hides whether you led it or watched it. Say what you did and by how much.
Weak
Technologies: React, Node, MongoDB, Express, Docker, AWS, Git, Jira, Agile.
Strong
Shipped a payments integration processing 15,000 transactions monthly.
The first line appears on ten thousand other resumes. The second appears on yours.
Weak
Wrote unit tests to improve code quality.
Strong
Raised automated test coverage from 34% to 81%, halving production hotfixes.
Everyone writes tests. The coverage change and its consequence are what a hiring manager needs.
Weak
Senior developer with strong problem-solving skills and team experience.
Strong
Lead a team of five engineers; own the on-call rota and incident review.
Strong problem-solving is an adjective about yourself. Owning the on-call rota is a fact anyone can verify in a single reference call.
Lead with what shipped, or let Hexa find it.
All three samples are free to read and copy. Want them as editable Word files, or your own history rewritten to lead with shipped work and real numbers? Both take a minute.
Build mine with Hexa →
Download all three · Free
The people above are illustrative examples written for teaching purposes.
Names, employers, registration numbers and figures are invented and should not be copied
into a real application — use them as a shape to pour your own verified numbers into.