How to write a resume with no work experience (step-by-step guide)

Every resume answers one question: what evidence is there that you can do this job? A job title is a shortcut to that evidence. It means somebody else already assessed you, hired you, and kept paying you. When you don't have one, you have to supply the evidence directly, which is harder to write but not dishonest and not hopeless.

The common failure is treating the empty Experience section as a wall. People either submit a half-page document with a gaping hole in the middle, or they fill it with a paragraph about being a motivated team player who works well independently. Both read as nothing. The fix is to stop thinking of the page as a record of employment and start thinking of it as a record of work — which you almost certainly have.

What actually counts as experience

If you have done any of these things, you have material for the page:

• Coursework projects. The capstone, the semester-long group build, the dissertation. Anything with a real brief, a real deadline, or a real user counts double.
• Club and society roles. Treasurer, events lead, committee member, team captain. These come with budgets, rotas, people who didn't show up, and events that either happened or didn't.
• Volunteering. Tutoring, running a charity's social accounts, a food bank shift, a hackathon you helped organise. Unpaid work is still work, and it is dated, which matters.
• Freelance and side projects. A friend's website, an Etsy shop, a mod, a newsletter, a Discord bot, a game jam entry. Paid or unpaid, finished or abandoned at a usable point.
• Part-time work outside your field. Retail, hospitality, warehouse, call centre, delivery, exam invigilation.

That last one is the category people most want to hide, and hiding it is a mistake. Nobody reading a graduate application is comparing your café job to a professional's five years in the industry. They are reading it as evidence that you turn up on time, handle a queue of irritated people, and can be left alone with a till. Those are real signals about whether you'll be a pain to manage.

It also fills a date range. A resume with two years of no dated activity invites the reader to guess what happened, and readers guess unfavourably. Two years of Sat & Sun shifts at a supermarket while you studied full time answers the question before it's asked.

The section order that works when experience is thin

The default resume order — summary, experience, education, skills — is designed for someone whose last job is the most convincing thing about them. That isn't you yet. Reorder it so the strongest evidence sits highest:

1. Summary (2–3 lines). Not an objective. Nobody is hiring you to satisfy your desire for a challenging role in a dynamic organisation. Say what you are, what you can do, and what role you're applying for, in that order.
2. Education. Degree, institution, dates, and then the parts that are actually relevant — a dissertation title, four or five modules that map to the job, a grade if it's strong. This is the credential that put you in the pile, so it goes near the top while it's still the newest thing about you.
3. Projects. The load-bearing section. On a resume with no jobs, this should be the longest block on the page.
4. Skills. Specific and checkable. "Python, pandas, SQL, Git" is a skills section. "Problem solving, teamwork, communication" is a horoscope.
5. Experience. Whatever paid or volunteer roles you have, reverse chronological, one or two bullets each. Unrelated is fine. Empty is worse.
6. Extras. Certifications, languages with honest levels, awards. One line each, no padding.

The point of the order is that it argues for you silently. You never have to write the sentence "although I lack direct experience." Do not write that sentence, or any version of it. It hands the reader a reason to stop reading, and it draws attention to exactly the thing you'd rather they skimmed past.

How to write a project entry that reads like a job entry

A job entry reads as credible because of its structure, not because of the employer's logo. It has a title, a scope, a timeframe, and bullets that describe outcomes. Give your project the same four things and it will carry similar weight.

• A title line that names a role, not a course code. Bike-Share Data Analysis — Team Lead (4 students) tells the reader what you were. CS4102 Group Assignment 2 tells them what your university called it.
• A date range in the same format as everything else on the page. Sep 2025 – Dec 2025. Consistency matters more than the specific format.
• One line of context. What the project was, who it was for, what problem it addressed. A reader who doesn't know your course needs this to understand the bullets.
• Two or three bullets about what you personally did, with the tools named and the outcome stated.

Three things changed. The word "we" is gone. Group projects are fine to list, but bullets describe you — the reader is deciding whether to interview you, not your project team. Name your slice honestly and let the title line say it was a group of four.

The tools are named specifically. "HTML, CSS and JavaScript" is what every student on the course could write. "React, Node, Stripe test mode" is a claim someone can ask you about, which is precisely what makes it worth something.

The ending is an outcome, not a grade. "Received a high grade" tells the reader what your marker thought. It is the weakest possible way to finish a bullet, because the reader has no idea how hard your marker was. An outcome tells them what happened in the world.

If the project never left the classroom, you can still end on something concrete: how much data it handled, how many people used it, what it replaced, how long it took to run before and after. Cut the model's training time from 40 minutes to 6 is an outcome. So is presented to a panel of three lecturers and the department's industry partner.

"I have nothing to put in the bullets"

This objection is nearly universal, and it's usually one of three different problems wearing the same coat. Each has a different fix.

1. You did the work but can't remember the specifics

This is the most common case and the easiest to solve. Go and look. Open the repository and read your own commit history. Open the shared drive, the group chat, the slide deck you presented, the marking rubric, the email thread with the client. You will find dates, decisions, numbers and awkward moments you have completely forgotten.

Write everything down first without judging it, then cut. Recall and editing are different jobs, and trying to do both at once is why people stare at a blank Projects section for an hour.

2. The work genuinely was small

Then write a small, true bullet. One honest line beats three inflated ones. Wrote the SQL queries behind the team's weekly dashboard is a perfectly good bullet for a junior application. Spearheaded data infrastructure initiatives describing the same work is worse, because the interviewer will ask a follow-up question that the sentence has promised you can answer, and you can't.

Small and specific also beats large and vague on its own terms. A reader who sees three narrow, concrete bullets concludes you know what you did. A reader who sees three broad ones concludes you're covering for something.

3. You genuinely haven't done enough yet

This is the only version that isn't a writing problem, and no amount of rewording will fix it. The fix is off the page. Give yourself two to four weeks and build one thing end to end — end to end being the important part, because a finished small thing is worth more than three abandoned ambitious ones.

• Take the unglamorous job nobody in the society wants. Rebuild the membership spreadsheet, run the ticketing for one event, take over the accounts. It's a real system with real users and a real deadline.
• Reproduce a published analysis with different data and write up where your numbers differed and why. This demonstrates method, which is what junior analytical roles are actually screening for.
• Do one piece of paid freelance work, even at an embarrassing rate. Being paid changes how you scope the work, how you talk about it, and how it reads on the page.
• Ship something small to real users — a tool for your course cohort, a script your team at work actually runs. Ten real users beats a portfolio piece nobody opened.

What to leave off

Space is your scarcest resource on a one-page resume, and every line that says nothing is a line that could have said something.

• High school. Once you have a degree or are close to finishing one, drop it. The exception is if you're in your first year of university with nothing else, or the school is genuinely specialist and relevant.
• "References available on request." Everyone assumes this. It costs a line and signals that you needed a line to fill.
• Hobbies that describe half the population. "Reading, music, travelling" differentiates nobody. Keep a hobby only if it's specific enough to do work: competitive chess, restoring motorcycles, moderating a 400-person Discord.
• Photo, date of birth, marital status, full street address. Outside the countries where a photo is standard, these add legal awkwardness and zero information. City and country is enough.
• Objective statements about what you want. The reader is deciding whether to give you something, not what you'd enjoy receiving.
• Skill bars and percentage ratings. "Python 80%" is meaningless — 80% of what? Name your level in words, or better, show it in a project entry.
• A second page. With no jobs, one page is enough, and a second page announces that the first one was padded.

A skeleton you can copy today

Roughly what a strong no-experience resume looks like when it's laid out on one page:

1. Header — name, city and country, email, phone, one link (portfolio, GitHub or LinkedIn). Two lines. Not in the document header region, where some parsers won't read it.
2. Summary — 2–3 lines naming the role you want and the two strongest things you bring to it.
3. Education — degree, institution, dates, plus a dissertation line and four or five relevant modules.
4. Projects — two or three entries, two or three bullets each, formatted exactly like job entries. The biggest section.
5. Experience — part-time and volunteer roles in reverse chronological order, one or two bullets each.
6. Skills — grouped by kind: languages, tools, methods. Only things you'd defend in an interview.
7. Extras — certifications, languages with levels, awards. One line each.

That fills a page honestly. It doesn't pretend you have five years behind you, and it doesn't need to. The person reading it is answering two questions: can this person do useful work, and will they be straightforward to work with? Evidence of finished projects answers the first. Clear, unpadded, un-inflated writing answers the second — and at this stage, the second one is doing more for you than you'd think.