How to write a resume when you have no experience

You're staring at a blank page thinking you have nothing to put on it. You haven't had a real job, your last summer was a retail shift, and the only projects you can name got a grade instead of a customer. So you either pad the page with adjectives or you don't send the resume at all.

This article covers what actually counts as experience, and how to lay out the page when you have no work history. It also covers writing project bullets that end in a result, why your part-time job matters more than you think, and what a resume genuinely can't fix. Read the sections about evidence first, because most people's problem is presentation rather than a real shortage of material.

The advice comes from Ethan Evans, a retired Amazon VP who spent 15 years there and reviewed real student and entry-level resumes live on his Level Up show, and from Nikhyl Singhal, former CPO of Credit Karma and VP of Product at Meta, who runs The Skip. Every quote plays the exact moment it was said.

"No experience" usually means "no job title"

When people say they have no experience, they almost always mean they've never held a full-time job with a title on a business card. That's a much smaller gap than it feels like. Hiring managers for entry-level roles already know you don't have five years of work behind you. What they're looking for is evidence that you've done something hard, finished it, and can say what came of it.

You have more of that evidence than you think. Singhal spent a whole episode of The Skip on how people actually land a first tech job, and the thing he keeps coming back to is what you did outside of class.

Before you write anything, spend 20 minutes making a list. Don't filter it yet, just get every candidate on the page.

Most people finish that list with 10 or 15 items and realize they had plenty of material all along. None of it had a job title attached, so you never wrote any of it down.

How to lay out the page with no work history

The standard resume order puts work experience first, which is exactly wrong for you. Evans's first note on a student resume was almost always about telling the reader who they're looking at before they start judging the content.

That one move changes how everything below it gets read. Someone who already knows you're a junior in chemical engineering will forgive a thin work history, because they were never expecting a long one. Someone who hasn't figured that out yet spends the first ten seconds wondering why your jobs look so small.

Here's the order that works when you have no full-time roles:

Two format warnings, because he raised them on almost every student resume. Give it white space. Reviewing a Waterloo student's page, he said the density itself was the problem: "It's about it being readable, and this is so dense the readability suffers." His reaction as the person holding a thousand resumes was blunt: "basically what that does for me as a reviewer is it irritates me, because now I have to do the work to sort of parse through your bad design." And spell out your acronyms. He hit "DECA" on that same resume and said "this is kind of meaningless to me," then suggested writing it as "DECA (high school marketing)" so a reader outside your world can follow.

Write project bullets the way you'd write a job

This is where most entry-level resumes lose. When you describe a course project the way your syllabus describes it, a reader sees homework. When you describe the same project the way you'd describe a job, a reader sees work, and almost all of that difference comes down to whether the bullet ends in a result.

Evans reviewed a Brown computer science student's resume that described building machine learning models with TensorFlow and annotating 200,000 video frames. Strong work. Every bullet stopped one step short.

"You're going to get a pass on this" is worth reading twice. He's saying a student who skips results still gets looked at, and a student who includes them jumps the queue. It's the cheapest edge available to you.

The structure he teaches is STAR: situation, task, action, result. For a project, the situation is the class or the lab or the hackathon, the action is what you personally built, and the result is what changed because it existed. On a chemical engineering student's resume he pointed at exactly this pattern, praising a first bullet that trained 50 students on lab tools and saved senior process engineers 100 plus hours, then noting the next four bullets had no result at all: "You kind of started off well using STAR on your first thing and then you missed it on the next four."

Notice that none of the work versions invent anything. The facts were already there. They just never got written down, because the person writing them didn't think a class project was allowed to have a result. The resume bullets playbook goes deeper on the sentence-level mechanics if you want more practice on this one skill.

When you can't find a business result, use what you have: how many people used it, how much time it saved, how it compared to a baseline, how many people you presented to, whether it's still running. Evans praised a student bullet about founding a charity drive on exactly this basis, saying "you've got what you accomplished and how you did it," and the only thing he wanted more of was whether it was still going.

Put numbers on everything you can

Numbers are the fastest way for a stranger to believe you. Evans reviewed a resume from a finance major graduating in May with no job lined up, liked most of it, then his chat pointed out the obvious.

He graded that resume a B for missing results generally, then dropped it to a C minus because a finance major with no numbers on the page undercuts the whole application. The lesson generalizes past finance: whatever you claim to be good at, the page should show you doing it.

You don't need audited figures, just honest scale. How many customers a shift, how many hours a week, how many people on the team, how many dollars in the budget, how many rows in the dataset, what it was before and after. Use a rounded number you can defend in an interview, and use it in place of an adjective.

While you're adding numbers, take out the inflated vocabulary. Evans hit a resume stacked with "executed, strategized and designed" and "hypothesized, conducted and analyzed A/B tests" and called it out: "you've like decided there's extra points for syllables, and it just sounds a little overblown." A plain verb with a real number after it does more for you than an impressive verb with nothing after it.

What to do with GPA and coursework

GPA is simple. Put it on if it's roughly 3.4 or above, or if it's the highest number you have and you're applying somewhere that screens on it. Leave it off otherwise, and let your projects carry the page. Reviewing a Brown student with a 3.7, Evans read the top corner and said most recruiters would think "okay, I'm interested, there's someone at a smart exclusive school doing pretty well." That's the entire job GPA does: buy you a few more seconds of attention.

Coursework deserves one line. Don't give it a whole section. List four to six courses that map to the job you want, and skip the intro classes everyone takes. "Relevant coursework: Distributed Systems, Machine Learning, Database Design, Operating Systems" tells a reader what you can be handed. A full transcript tells them nothing and eats space your projects need.

One thing to be careful with: don't write your resume for a future you. Evans caught a student listing a degree two years out while calling himself a junior and said "that a little bit makes it seem like you're lying about being a junior." He gave the fix too, which is the word "rising," as in rising junior. He was equally direct about a student who listed an internship that hadn't started yet: "I wouldn't put a job that you haven't done yet." If you want to mention it, label it as pending rather than dressing it up as work you've done.

Your retail job matters more than you think

The most common mistake students make is cutting the unrelated job. You worked 20 hours a week at a coffee shop through three semesters and you leave it off because it has nothing to do with software. That's a real loss, and hiring managers read it differently than you do.

Reviewing a grad student's cloud computing resume, Evans got to a line about being a crew leader for a mowing company and reacted to it more warmly than to any of the technical work.

Keep the job. Then write it like work, with the same rules as everything else. A shift at a restaurant has volume, speed, money, training, and scheduling in it, and all of those are countable.

These jobs do two more things for you. They fill a gap that would otherwise look like nothing happened, and they hand you behavioral interview stories about conflict, pressure, and difficult customers that are usually better than anything from a group project. The behavioral interview questions playbook covers how to build those into answers.

What a resume can't fix

Be honest with yourself about the ceiling here. A great entry-level resume gets you into a pile with hundreds of similar ones. If you have no relevant projects at all, no amount of editing covers that, and the document can't introduce you to anyone inside the company. Evans is direct about how little it's supposed to do.

He gave that student a ten to thirty minute budget for the remaining edits and told him to go get the job. Take the same deal. Once the page is good, the extra hours belong somewhere else, and for an entry-level search that somewhere is building evidence and talking to people.

Singhal makes the same argument from the other side, about what separates people who land a first job from people who stay stuck.

Two things to do with that. First, keep building evidence while you apply, because every new project is a new line and a new thing to talk about. Second, stop relying on the portal. A referral or a short conversation with someone on the team does more for an entry-level application than any rewrite, and the foot in the door playbook covers how to build that path. Then tailor what you send using the tailoring playbook, so the version that arrives points at the job in front of it.

Entry-level mistakes worth avoiding

These came up over and over in Evans's student reviews.

Frequently asked questions

Should my resume be one page?

Yes. With no full-time roles, everything you have fits on one page, and a second page signals padding. If you're running long, cut your weakest project rather than shrinking the margins.

Do I include my GPA?

Include it if it's around 3.4 or higher, or if a specific employer asks for it. Below that, leave it off and let projects and internships do the work. Nobody assumes a missing GPA is a good one, but a mediocre number sitting at the top of the page does you more damage than leaving it out.

What if I've genuinely never had a job?

Then your experience section is projects, coursework, and volunteering, and you label it "Projects and Experience" rather than pretending otherwise. Three well-written projects with real outcomes beat one weak internship. Then go make a fourth: a small tool, a freelance client, a volunteer role with a measurable result. Two months of deliberate effort is enough to change what's on the page.

Should I list a job I quit after two weeks?

Skip it. It's not long enough to have produced anything you can write a bullet about, and it invites a question that costs you more than the line gains.

Can I use a resume template with columns and colors?

A little color and a photo are fine, and Evans has told students to consider both. What matters more is readability: clear sections, real gaps between them, and more space above a heading than between two bullets. If the template creates dense columns, it's working against you.

How do I write about a group project without overstating my role?

Name the team size and your specific piece. "One of four engineers; owned the authentication flow and the deployment pipeline" is honest and more credible than claiming the whole thing. Interviewers ask what you personally did, so write the bullet you'd want to answer questions about.

Does anyone actually check whether projects are real?

Interviewers ask about them in detail, which amounts to the same thing. Link the repo or the live site where you can, and only list projects you can walk through for five minutes.

The method on one page