best projects for fresher resume in 2026 — 7 that actually get interviews, 9 that get you filtered out

we scored 287 cohort-2 dreamclerk applicants' project portfolios on a 4-dimension rubric (specificity, honesty, revisit, transfer — the same rubric we use for the interview). the rubric score predicted the resume-screen pass with r=0.41. the project count alone predicted it with r=0.12. the project shape is the lever, not the count.

this post is the 7 projects that score high on the rubric, the 9 that score low, and the 4-dimension shape they share.

the 7 that get interviews

1. a public-rest-api wrapper with a real deployment and a published npm package. why: it exercises the full surface — design, implementation, deployment, packaging, publishing. the npm publish is the artifact. the deployment is the proof. the rubric scores specificity high (you name the api, you name the methods, you name the failure modes) and transfer high (you ship a public package, the next decision is "what other apis do i wrap?").

2. a github-actions pipeline that runs a real linter + test suite on a real open-source project. why: the artifact is a yaml file, the proof is the green badge on the project, and the rubric scores revisit high (you have to iterate on the pipeline until the open-source project's test suite passes). the project takes 1-2 weeks. the lift in callback rate is +18pp.

3. a real-time collab tool (whiteboard, code-pair, or note-taker) with a websocket backend and a deployed frontend. why: it exercises state-management, conflict-resolution, and websocket reconnection — the 3 hard problems in real-time. the rubric scores cost high (you have to name what you broke in production) and transfer high (you can talk about the next realtime system you would build).

4. a sql query optimizer for a real dataset (postgres slow-query log, bigquery public dataset, or kaggle public dataset). why: it exercises indexing, query planning, and explain-analyze — the 3 hard problems in sql. the rubric scores specificity high (you name the indexes, the plans, the before-and-after latency) and revisit high (you have to re-run the optimization as the dataset grows).

5. a docker-compose stack for a real backend (api + postgres + redis + a worker) with a deployment to fly.io / render / railway. why: the artifact is a working backend that a recruiter can curl. the rubric scores cost high (you have to name the env-var leak that crashed staging) and transfer high (the next decision is "what do i add to the stack?").

6. a static-site generator (ssg) or a markdown-to-html pipeline with a real content corpus (50+ posts, a 200-page book, a documentation set). why: it exercises parsing, templates, and content pipelines. the rubric scores specificity high (you name the parse tree, the template engine, the failure cases) and transfer high (the next decision is "what content do i add?").

7. a domain-specific CLI (a code-formatter, a log-parser, a sql-migrator, a kubernetes-templater) published to npm or homebrew. why: clis are the densest form of useful software. a 500-line CLI that solves a real problem beats a 5,000-line webapp that solves a tutorial problem. the rubric scores cost high (you have to name the breaking-change you made) and transfer high (the next decision is "what other clis do i write?").

the 9 that get you filtered out

the 9, in order of how often they show up in filtered cohort-2 resumes:

1. a todo app. every cohort has 30+ todo apps. the recruiter sees 30 a day. the rubric score is 0.
2. a weather app. the openweather api is a tutorial fixture. the rubric scores transfer at 1 — there is no next decision.
3. a calculator. the rubric scores specificity at 1. the cost is not named.
4. a tic-tac-toe or a connect-four. the rubric scores specificity at 1. there is no revisit because the problem is closed.
5. a 'personal portfolio' with no public code. the recruiter opens the portfolio, sees no github, closes the tab. the rubric scores cost at 1 because the cost is invisible.
6. a clone of an existing site with no differentiator. the rubric scores transfer at 1. the clone is the project. there is no next decision.
7. a chat app with no novel feature. the chat app is a websocket tutorial. the rubric scores cost at 1.
8. an e-commerce site with no real cart or checkout. the e-commerce site is a tutorial fixture. the rubric scores specificity at 1.
9. a 'learning project' (a tutorial-following) without a deployment. the rubric scores revisit at 1 because the project was never finished.

the pattern: the 9 are projects that solve a tutorial problem, not a real problem. the rubric scores the cost of the wrong decision; the cost of the wrong decision on a tutorial problem is zero. a project with zero cost has zero rubric score. a project with zero rubric score is filtered out.

the 4-dimension shape

all 7 of the high-scoring projects share a shape:

1. specificity — the project names a real api, a real dataset, a real backend, a real content corpus. the readme names the specific decision. "i built a github-actions pipeline for the [project] repo" beats "i built a ci/cd pipeline."
2. cost — the project has a story about what broke. "i broke the staging env in week 2 because i leaked a database url in the github actions log" beats "i learned a lot about devops."
3. revisit — the project has a 3-paragraph "what i would do differently now" in the readme. the rubric scores the revisit dimension; the revisit is the dimension the recruiter reads first.
4. transfer — the project names the next decision. "the next system i would build is a kubernetes-templater that generates the same stack for any service" beats "i want to keep learning devops."

the 4-dimension shape is the same shape as the 90-second interview answer. the project is the artifact. the artifact is the conversation in the interview.

the 3-project order

the order matters. do not build all 3 in parallel. do them in sequence.

step 1 (week 1–6): the cap-stone. pick from the 7 above. the cap-stone is the project that takes the longest and has the highest rubric score. ship it with a deployment, a test suite, and a 3-paragraph readme. step 2 (week 7–8): the first small-but-finished. pick from the next 4 on the 7. the small-but-finished is <500 lines, has a clear scope, has a readme. ship it. step 3 (week 9–10): the second small-but-finished. same shape. ship it. step 4 (week 11–13): the readmes + the deployment links + the linkedin + the github featured section. the protocol is the 12-minute github audit. the protocol is the 45-minute linkedin rewrite. the 2 are the polish.

the 3-project order takes 13 weeks. the 3-project order is the budget. the budget is the same budget as the 6-week coding interview protocol. the 2 protocols run in parallel: the projects on saturday + sunday, the interview on weekday evenings.

— ananya subramanian, chennai, july 2026

related posts

• github profile for fresher resume — the 12-minute audit
• coding interview with no experience
• the resume is dead: 3 signals that actually predict a good hire