Photo by Anete Lusina on Pexels
You've written a solid projects section. Then you spend twenty minutes dragging it up and down your resume, trying to decide where the projects section should go — above your work experience, below your education, or somewhere you haven't thought of yet. There's no single universal answer, but there is a clear one once you know your career stage — and getting this placement wrong is a quieter mistake than a typo, because it doesn't look wrong, it just quietly buries your best evidence on page two.
The Short Answer: It Depends on What Your Projects Are Replacing
Projects placement isn't really a formatting question. It's a question of what your projects are standing in for. If they're standing in for missing work experience, they go near the top. If they're supporting work experience you already have, they go after it. Everything else in this article is a variation on that one rule.
Decision Table by Career Stage
| Career stage | Where projects go | Why | |---|---|---| | Student / new grad, no internships | Education → Projects → Skills → Experience | Projects are your strongest evidence, so they sit right after the credential that frames them | | Student / new grad, with an internship | Summary → Experience (internship) → Projects → Education | The internship already proves workplace competence; projects add depth, not a foundation | | Career changer | Summary → Projects → Experience (old field) → Skills | You want the reader to see new-field proof before they see your old job titles | | Developer / engineer with a strong GitHub | Summary → Experience → Projects → Education | Projects support your work history here, not replace it — unless your side projects genuinely outshine your day job, in which case move them above Experience | | Senior professional (8+ years) | Summary → Experience → Skills → Education (Projects only if it fills a real gap) | At this stage, drop projects entirely unless one specific project does something your job history doesn't already show |
Why Students Should Lead With Projects
If you're a student with no internship, your work-experience section is either thin or empty, and a recruiter scanning your resume for seven seconds needs something to land on. For the actual bullet-writing mechanics — title, dates, the four-part formula for outcomes — see how to put personal projects on a resume. A capstone project with a real deliverable — "Built a full-stack inventory tracker for a 12-person nonprofit, cutting their manual stock counts from weekly to monthly" — tells a hiring manager more than three bullet points about your coursework ever will. Put it right after Education, before Skills, so it's one of the first things they read.
Once you land your first full-time job, that calculus flips fast. A classmate of mine kept her senior capstone project on her resume through two job changes, and by the third one it was actively working against her — a hiring manager asked about it in an interview, expecting recent work, and she had to explain it was from four years earlier. Drop academic projects the moment you have a full-time role to replace them with.
Career Changers: Projects Are Your Bridge, Not a Footnote
If you're pivoting from teaching into UX design, your last five years of work experience don't demonstrate the skill the new role needs — but a redesigned onboarding flow you built for a local nonprofit's app does. Career changers should place projects immediately after the summary and before the old-field work history, so the reader sees relevant proof before they see a job title that might make them pause.
Be specific about the project's constraints, not just the output. "Redesigned the sign-up flow for a 200-user community app, reducing drop-off at step 2 from an estimated 30% to under 10% based on post-launch user interviews" reads as real work. A vague "Worked on UX projects" reads as filler, and a skeptical hiring manager will notice the difference immediately.
Developers: When Projects Beat Your Job Titles
For engineers, the projects-vs-experience order usually comes down to one honest question: is your GitHub more impressive than your last job? If you spent two years maintaining a legacy internal tool but also built a moderately popular open-source library on the side, lead with the library. Most developers, though, have projects that complement rather than eclipse their job history — in that case, keep Experience first and Projects right after it, before Education.
One formatting habit worth stealing from stronger developer resumes: name the stack and the constraint, not just the feature. "Built a rate-limiting middleware for a Node API handling 40K requests/day, reducing 429 errors by [NEEDS SOURCE: claim — specific error-reduction percentage]" is the shape to aim for, even without a hard number yet — a project entry that names real scale and a real technical decision beats a feature list every time.
Senior Professionals: Consider Dropping It Entirely
Here's the position most articles won't take clearly: if you have eight or more years of experience, a generic "Projects" section is often dead weight. Your work experience should already be carrying the weight of proof, and a separate section of side projects can read like padding on a resume that shouldn't need it. Keep a projects section at this stage only if it does something your job history genuinely can't — open-source maintainership, a specific technical talk, an advisory role. If you're not sure it clears that bar, cut it and give the space back to a tighter Experience section instead.
What If You're Between Categories?
Not every candidate fits neatly into one row of that table — a career changer who's also technical, or a mid-level professional with one standout side project, might reasonably borrow rules from two rows. When you're not sure, default to the rule from the top of this article: does the project replace missing evidence, or support evidence you already have? Replace, and it moves up. Support, and it moves down.
How to Actually Test Your Placement
The fastest way to know if you've got this right isn't a rule of thumb — it's testing both orders and seeing which one reads better cold. If you're building your resume in Simple CV, the section list supports drag-to-reorder, so you can drag Projects above or below Experience and see the full layout update instantly, instead of retyping the whole document to test an ordering change. Try both, read each version as if you were the recruiter seeing it for the first time, and keep whichever one leads with your strongest proof first.
If you've been staring at this decision for longer than it deserves, that's a normal reaction to a document that feels like it should have one right answer — it doesn't, but it does have a right answer for you, and that's usually enough to move on and hit send.
Ready to put this into practice?
Build your CV free