Skip to main content
Guides Resume writing Projects Section on a New-Grad Resume — What to Include and How to Describe Impact
Resume writing

Projects Section on a New-Grad Resume — What to Include and How to Describe Impact

9 min read · April 25, 2026

For new grads, projects can carry the weight that work experience has not yet earned. Learn which projects to include, how to write impact-focused bullets, and how to avoid the common project-section traps.

Projects Section on a New-Grad Resume — What to Include and How to Describe Impact

The projects section on a new-grad resume can be the difference between looking inexperienced and looking ready for the job. When internships are limited, projects show how you think, build, analyze, test, write, design, or solve problems. The key is not listing every class assignment. The key is choosing projects that match the target role and describing them with enough context, technical detail, and impact that a recruiter can see transferable ability.

Projects section on a new-grad resume: what it is for

A project section gives evidence when professional experience is thin. It can show:

  • Technical skills used in a realistic setting.
  • Initiative beyond required coursework.
  • Ability to finish and explain work.
  • Collaboration, scope, and problem-solving.
  • Domain interest in the roles you are targeting.
  • Portfolio or GitHub proof.

For software roles, projects show code quality, architecture choices, testing, deployment, and product thinking. For data roles, they show analysis, modeling, SQL, visualization, and interpretation. For business, finance, marketing, or operations roles, they show research, structured thinking, metrics, and communication.

A project section is not filler. If a project does not help a hiring team trust your ability, remove it.

Which projects to include

Choose 2 to 4 strong projects. More than that usually creates noise. Prioritize projects that are recent, relevant, complete, and explainable.

Use this decision table:

| Include the project if... | Skip or shorten it if... | |---|---| | It uses tools from the target job. | It is a generic class assignment everyone did. | | You can explain your decisions. | You copied most of it from a tutorial. | | It has users, data, deployment, or measurable output. | It is unfinished and hard to demo. | | It shows role-relevant thinking. | It points away from your target field. | | You can link to code, demo, report, or deck. | You would be nervous discussing it deeply. |

A small finished project beats a huge vague project. "Built and deployed a job-tracking web app with authentication, PostgreSQL, and automated tests" is stronger than "AI platform for improving hiring" if the second is mostly a slide deck.

Where the projects section belongs

For new grads targeting technical roles, projects often belong on the first page after education and skills, especially if they are stronger than work experience. For candidates with strong internships, projects can come after experience. For nontechnical roles, place projects after education or experience depending on relevance.

A common order:

  1. Header.
  2. Education.
  3. Skills.
  4. Projects.
  5. Experience.
  6. Leadership or activities.

If you have a highly relevant internship, move experience above projects. The resume should lead with the strongest evidence for the target job, not follow a rigid template.

The project bullet formula

Use this formula:

Built/analyzed/designed [thing] for [user/problem] using [tools/methods], resulting in [outcome, learning, metric, or capability].

Then add bullets that show implementation decisions, not just features.

Weak:

  • Created a weather app using React.

Better:

  • Built a React weather dashboard using OpenWeather API, debounced city search, and local storage for saved locations; deployed on Vercel for live demo.
  • Added loading, error, and empty states to improve usability and wrote component tests for search and saved-location flows.

Weak:

  • Did machine learning project to predict house prices.

Better:

  • Built regression model to predict housing prices from 20+ property features, compared linear regression, random forest, and gradient boosting, and improved validation RMSE 18% through feature engineering.
  • Presented model limitations around neighborhood bias, missing data, and overfitting in a final technical report.

The better bullets show choices, tradeoffs, and evidence.

What to include for software engineering projects

For software roles, include projects that show you can build beyond a tutorial. Strong signals include deployment, tests, authentication, data persistence, APIs, performance, accessibility, and clear architecture.

Good software project bullets:

  • Built full-stack task-management app with React, Node.js, PostgreSQL, and JWT authentication; deployed frontend and API with CI checks for linting and tests.
  • Designed REST API for inventory tracking, added pagination and role-based access controls, and documented endpoints with OpenAPI.
  • Implemented unit and integration tests for checkout logic, increasing confidence in price, tax, and discount calculations.
  • Refactored state management from prop drilling to Redux Toolkit after component complexity increased across dashboard views.

Do not list only features. "Login, search, profile page, settings" reads like a product checklist. Explain the engineering underneath.

What to include for data and analytics projects

For data roles, the project should show the full analytical path: question, data, cleaning, method, finding, and business implication.

Good data project bullets:

  • Analyzed 1.2M public bike-share trips using SQL and Python to identify commute-hour station shortages, then built Tableau dashboard showing high-risk docks by hour and neighborhood.
  • Cleaned messy survey data, handled missing responses, and used logistic regression to identify factors associated with customer churn.
  • Created cohort analysis for mock SaaS subscription dataset, calculating retention, expansion, and churn trends by acquisition month.
  • Built dbt models and documentation for e-commerce orders dataset, separating raw, staging, and mart layers for repeatable reporting.

Avoid projects that only say "visualized data." Hiring teams want to know whether you formed a useful question and interpreted the result.

What to include for finance, business, and operations projects

Nontechnical projects can be excellent if they show structured thinking and measurable recommendations.

Examples:

  • Built three-statement financial model for subscription software company, including revenue build, headcount plan, cash runway, and sensitivity analysis for growth and churn assumptions.
  • Analyzed public company filings to compare gross margin, CAC payback, and revenue growth across five SaaS peers; summarized investment implications in a 10-slide deck.
  • Redesigned mock campus club budget process using zero-based categories and monthly variance tracking, reducing unallocated spend in the following semester plan.
  • Conducted market entry analysis for food delivery concept, combining competitor pricing, neighborhood demographics, and unit economics to recommend launch constraints.

For business roles, impact can be a recommendation, decision model, or measurable improvement. It does not have to be production software.

How to write the project entry

Use a compact format:

Project Name — Tools or methods Link if available | Date

  • Bullet 1: what you built/analyzed and for whom.
  • Bullet 2: technical or analytical decisions.
  • Bullet 3: result, metric, deployment, demo, or insight.

Example:

Campus Pantry Demand Forecast — Python, pandas, scikit-learn, Tableau GitHub: github.com/yourname/pantry-forecast | Mar 2026

  • Built demand forecast for campus food pantry using 18 months of anonymized visit data, weather, and academic calendar features.
  • Compared baseline moving average, random forest, and gradient boosting models; selected simpler model after validation showed similar accuracy with easier explanation.
  • Created Tableau dashboard for expected weekly demand by category, helping volunteers plan inventory and reduce stockout risk during exam weeks.

This format is specific, credible, and easy to scan.

Impact when you do not have real users

Many student projects do not have real customers. That is fine. Do not fake impact. Use other forms of evidence:

  • Deployed live demo.
  • Number of records analyzed.
  • Runtime improvement.
  • Test coverage.
  • Accuracy improvement against a baseline.
  • Reduced manual steps.
  • Clear recommendation from analysis.
  • Team size and your role.
  • Grade or award only if meaningful.

Instead of saying "helped users manage tasks" when no users existed, say "built a deployed task-management app with authentication, due-date filtering, and persistent PostgreSQL storage." Honest specificity is stronger than fake user impact.

Before-and-after project bullets

Before:

  • Made a chatbot using Python.

After:

  • Built Python chatbot for university FAQ retrieval using sentence embeddings and a curated 300-question dataset; added fallback behavior for low-confidence matches and evaluated responses against manually labeled test prompts.

Before:

  • Created e-commerce website.

After:

  • Built full-stack e-commerce prototype with React, Express, PostgreSQL, product search, cart persistence, and Stripe test-mode checkout; added integration tests for pricing and order creation logic.

Before:

  • Worked on group project for marketing class.

After:

  • Led customer research for campus meal-plan project, analyzed 112 survey responses, and translated findings into three pricing recommendations presented to a panel of faculty and local operators.

Before:

  • Did SQL project.

After:

  • Wrote SQL queries across orders, customers, and refunds tables to identify repeat-purchase trends, refund drivers, and monthly revenue cohorts for a mock retail dataset.

Common mistakes

The first mistake is listing too many class projects. If every candidate from your course has the same compiler, weather app, or Titanic dataset, you need either a stronger description or a different project.

The second mistake is using tutorial language. "Followed tutorial to build Netflix clone" is weak. If you extended the project with authentication, testing, deployment, or your own data model, say that. If you did not, replace it.

The third mistake is forgetting your role in group projects. Write what you owned: backend API, data cleaning, dashboard design, financial model, user research, presentation, testing, or deployment.

The fourth mistake is overclaiming impact. Do not say "increased revenue" for a student simulation. Say what the model projected, recommended, or demonstrated.

The fifth mistake is not linking proof. If you have a clean GitHub repo, live demo, dashboard, paper, or slide deck, include it. Make sure the link works and the README explains setup.

How to talk about projects in interviews

The resume gets the project into the conversation; the interview tests whether you actually understand it. Prepare a 60-second explanation for each listed project: the problem, your role, the tools, the hardest decision, the tradeoff you made, and what you would improve next. That last part matters. New grads often think admitting limitations weakens the project. It usually does the opposite because it shows engineering judgment and maturity.

For a software project, be ready to explain data models, API design, deployment, testing, and failure handling. For a data project, be ready to explain data quality, assumptions, model choice, and why the result matters. For a business project, be ready to explain assumptions, alternatives considered, and how a decision-maker would use the recommendation.

Project-section checklist

Before submitting your new-grad resume, check:

  • Are there 2 to 4 projects, not a long archive?
  • Does each project match the target role?
  • Does each entry include tools or methods?
  • Do bullets show decisions, scope, and outcome?
  • Are group-project responsibilities clear?
  • Are links working and professional?
  • Did you remove tutorial-only or unfinished work?
  • Can you explain every technical or analytical choice in an interview?

A good projects section makes a new grad look employable because it turns potential into evidence. It shows that you can learn a tool, apply it to a problem, make decisions, and communicate what happened. That is exactly what early-career hiring teams are trying to predict.