How to write project experience on a resume (the 1:3:2 structure)

1. What a wasted project entry looks like

This is the shape I see most often. It looks dense with information and gives a reader nothing to judge:

The problem with the first version is not length. It is that you are not the subject of any sentence. "This project is…", "It uses…" — all about the project, and then "I participated in the development," which says nothing about what or how much.

A reader has exactly three questions: which part did this person own, how did they do it, and what came out of it. Write to those three and you cannot go far wrong.

2. Three parts, in a 1:3:2 ratio

Split each project entry into three blocks and give them roughly 1 : 3 : 2 of the space. Which is to say: one sentence about the project itself is enough.

① Context (1 sentence)

Who it was for and what problem it solved. Not the stack — the stack belongs in the skills section, or woven into the second block.

• ✅ A second-hand marketplace for students on campus, aimed at the pile of unwanted things nobody can shift at the end of term
• ❌ This project uses a decoupled architecture with Vue, Spring Boot and MySQL

② What you did (2–3 sentences, the bulk of it)

This block decides how much weight you carried. Make three things explicit: scope (which part was yours), action (what you actually did), method (how). Use verbs that carry ownership — built, led, rewrote, designed, optimized — and avoid *participated in*, *assisted with*, *supported*. Those three tell a reader you were not the one doing it.

• ✅ Wrote all 12 endpoints on the order and payment path solo; cached the hot-items list in Redis
• ❌ Participated in backend development and assisted the team with integration

③ Outcome (1–2 sentences, with numbers)

An outcome without a figure is not an outcome. "Worked well" and "was well received by the professor" cannot be verified, so they cannot count in your favour.

• ✅ 3,200+ registered users and ~200 orders/day within three months; failure rate under 0.3%
• ❌ The project ran stably and was well received by classmates

3. No numbers? Three that you actually have

"It was a course project — where would user counts come from?" is the most common objection. Numbers do not have to mean users. All three of these count:

1. Size. Lines of code, no. But "12 endpoints," "8 tables," "3 permission roles," "5 product categories" — yes. They convey how much work it was.
2. Deltas. A before/after gap persuades most: response time 1.8s → 1.1s, build 4min → 90s, a two-hour manual reconciliation down to ten minutes. All measurable inside your own project.
3. Process. How many iterations, how many defects fixed, how many test cases written, how many people on the team and how many you led. You know all of these; it just never occurred to you they were writable.

If genuinely no figure exists, fall back to a verifiable fact: "source on GitHub (link)," "reused as the reference implementation for the following year's course." A fact is weaker than a number and much stronger than an adjective.

4. How many entries, and in what order

How many. Two or three if you are a new graduate; one or two if you already have employment history carrying the argument. Two written properly beat four written as one line each.

Order. Not reverse-chronological — by relevance to the role you are applying for. Backend job, backend project first; the award-winning contest project that has nothing to do with the role goes to the bottom, or goes.

Cutting. A project unrelated to the role is better deleted than kept. Every line on the page spends the reader's attention, and irrelevant lines dilute the relevant ones.

5. Patterns you can fill in

Replace what is in brackets with your own. If there is a bracket you cannot fill, that is a signal the entry needs more thought — not a signal to invent a number.

6. Two formatting details that change the impression

A three-part header line. "Project | your role | dates," aligned. It is the first thing scanned and it decides whether the rest gets read. Always include the role — "backend lead" and "team member" describe two different people.

Short lines, one point each, never more than two lines long. A dense paragraph is a grey block on a page and nobody reads to the end of it.

Both are painful to do by hand in a word processor — tab stops drift, and one font-size change re-flows the page. In the ResuHive editor an entry header is already three aligned parts (dates / organisation / role), and the description is a single rich-text area: enter starts the next point, and selecting several lines bolds them together. Export to PDF and Word and the layout matches.

It saves some work on the content too: paste the description in, run the AI polish, and sentences like "participated in development" come back verb-first with an outcome attached. Then read it yourself — AI cannot produce a number you did not give it, and anything it produces is invented, which is the sort of line that falls apart in the first interview round.

7. The five most common mistakes

1. Describing the project instead of yourself — the most common and the most costly. The fix: make "I" the subject of every sentence; whichever sentence resists is the one that was empty.
2. Stacking technologies — "Vue + Spring Boot + MySQL + Redis + Docker + K8s." The longer the list, the more it reads as padding. Pick the two or three you genuinely worked in and put them inside the action.
3. Every verb being "participated" or "assisted" — it halves your apparent contribution. If you really only assisted, say precisely which part you assisted with.
4. Outcomes written as adjectives — "worked well," "positive feedback," "well received." Unverifiable, so effectively blank.
5. Treating every project as equal — half the page spent on something unrelated to the role. Sort by relevance and be willing to delete.

8. Summary

• Three parts: 1 sentence of context, 2–3 on what you did, 1–2 on outcome — roughly 1 : 3 : 2
• Verbs that carry ownership (built, led, rewrote, optimized), never *participated* / *assisted* / *supported*
• No user count? Use size, delta and process figures — real ones you can explain
• Two or three entries for a new grad, ordered by relevance to the role, and cut what does not fit
• Aligned three-part headers and short one-point lines; let a tool handle the layout rather than fighting tab stops

This section answers one question: hand this to you, and what comes back? Say what you did, how you did it and what came of it — the rest is for the interview.