{"title":"The Projects Section","description":null,"content":"Projects can be very useful on an engineering resume, especially early in your career. When you do not have much work experience yet, projects show what you can build, how you think, and whether you can finish something usable.\n\nFor experienced engineers, projects should be more selective. Your work history usually carries the resume, so a project should add something your jobs do not show: a different technology, open source work, a serious side project, or hands-on work in an area you want to move into.\n\nThe goal is not to list every project you have ever made. The goal is to choose the few that make your case stronger.\n\n---\n\n# What a Project Should Prove\n\nA good projects section gives evidence. It does not just say \"built a chat app\" or \"created a dashboard.\" It explains what the project does, what you used to build it, what you personally built, and why the project is worth reading about.\n\nFor a new grad, intern, or career switcher, projects may be the strongest proof on the page. They can show practical skills before you have much professional experience. For an experienced engineer, projects should earn their space by showing something your work history does not.\n\nEach project entry should be easy to understand. A reader should be able to answer four questions quickly:\n\n- What is it?\n- What did you personally build?\n- What technologies did you use?\n- Why is it worth mentioning?\n\nYou do not need thousands of users. A strong class project, a useful internal tool, a well-finished personal project, or a real open source contribution can all work. What matters is that the project is real enough to discuss and specific enough to evaluate.\n\nA project does not have to be large. It does need to be clear. A hiring manager should be able to tell what problem you were solving, what choices you made, and what part of the work belongs to you.\n\nQuality matters more than quantity. Two strong projects with clear details are better than six vague entries. A long list of small apps can make it harder for the reader to see your best work.\n\n---\n\n# Choosing and Writing Project Entries\n\n### Decide whether the section helps your resume\n\nInclude projects if you are a new grad, intern, career switcher, bootcamp graduate, or self-taught engineer. In those cases, projects often provide the clearest evidence of ability.\n\nIf you are experienced, include projects only when they add something useful beyond your work history. If your professional experience already proves the skill, use the space for stronger experience bullets instead.\n\nWhen in doubt, ask: would this project help someone believe I can do the job I want? If the answer is no, leave it out.\n\n### Give each project a clear one-line description\n\nStart with a short explanation of what the project does and who it is for. Avoid describing it only by the technology.\n\nWeak:\n\n\n```javascript\nReact and Node.js chat application\n```\n\n\nStronger:\n\n\n```javascript\nTeam chat app with channels, threaded replies, and message search\n```\n\n\nThe reader now understands the product before seeing the stack.\n\n### Show what you personally built\n\nA project entry should not read like a feature list copied from the README. Use one or two bullets to show your work.\n\nGood project bullets can mention:\n\n- the main feature or system you built\n- a technical challenge you solved\n- usage, scale, or test data\n- performance, reliability, or usability improvements\n- feedback you used to improve the project\n- a design choice or tradeoff you can explain\n\nIf it was a team project, make your part clear. \"Built the backend API\" is more useful than \"worked on the project.\"\n\nIf it started as a tutorial, say what you changed or added. A copied tutorial does not tell a hiring manager much. An extended project with your own features, tests, deployment, or design choices is much stronger.\n\n### Include the stack briefly\n\nAdd the important technologies, but keep the list focused. Include the tools that matter for the role or explain the technical work.\n\nExample:\n\n\n```javascript\nStack: React, Node.js, PostgreSQL, Redis\n```\n\n\nDo not list every package or library you imported. The stack should help the reader understand the project, not overwhelm them.\n\n### Link to something useful\n\nA live demo is helpful if the project can be used safely and still works. A GitHub repo is useful if it has a clear README, setup instructions, screenshots, and enough code to understand the work. A short write-up can also help if it explains tradeoffs or design decisions.\n\nBefore adding a link, open it as if you were the recruiter. If the repo is empty, the demo is broken, or the README explains nothing, fix it or leave the link off. A missing link is better than a link that makes the project look unfinished.\n\n### Keep the section short\n\nMost resumes need two to four projects, not a catalog. Pick the projects that best support the role you want.\n\nFor a frontend role, a UI project with thoughtful interaction details may matter. For a backend role, a project with APIs, persistence, queues, caching, or deployment may be more useful. For data roles, show data cleaning, modeling, evaluation, or visualization.\n\n### Be honest about the project type\n\nIt is fine to say \"class project,\" \"personal project,\" \"open source contribution,\" or \"team project.\" Those labels do not weaken the work. They make it easier to trust.\n\nDo not make a class assignment sound like a production system. Do not claim users you did not have. A good interviewer will ask follow-up questions, and honest framing always holds up better.\n\nHere is a simple way to decide whether a project belongs on your resume.\n\n\n```mermaid\nflowchart TD\n A[A project you
could list]:::start --> B{Can you explain
what you built?}:::q\n B -->|No| X[Leave off
or improve first]:::no\n B -->|Yes| C{Does it support
your target role?}:::q\n C -->|No| X\n C -->|Yes| D{Has clear details,
stack, or link?}:::q\n D -->|No| E[Improve the entry
before listing it]:::fix\n D -->|Yes| F[Include it]:::yes\n\n classDef start fill:#00ceff,stroke:#000,color:#000\n classDef q fill:#ffd43b,stroke:#000,color:#000\n classDef no fill:#ff8787,stroke:#000,color:#000\n classDef fix fill:#ffa94d,stroke:#000,color:#000\n classDef yes fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe test is not whether the project sounds impressive in the abstract. The test is whether it helps the reader believe you can do the work in the role you want.\n\n---\n\n# Vague Entries Made Specific\n\nA weak project entry gives too little context. Here is a common version.\n\n**Bad:**\n\n\n```javascript\nChat Application\nBuilt a real-time chat app. Used React, Node.js, and Socket.io.\n```\n\n\n**Better:**\n\n\n```javascript\nDevChat - team chat app with channels and threaded replies\nGitHub: github.com/priya/devchat | Demo: priya.dev/devchat\n- Built real-time messaging with Socket.io, including channel rooms,\n typing indicators, and message persistence.\n- Added search and threaded replies after testing the app with two college\n project teams.\nStack: React, Node.js, Socket.io, PostgreSQL\n```\n\n\n**Why the better version works:** The rewrite explains what the app does, links to the work, names the important features, and shows that Priya tested it with real users. It does not need exaggerated numbers to be useful.\n\nNow here is an experienced engineer choosing what to include.\n\n**Bad:**\n\n\n```javascript\nProjects\n- Todo List App (React) - add, edit, and delete tasks\n- Weather App - shows weather for a city\n- Personal Portfolio Website\n```\n\n\n**Better:**\n\n\n```javascript\nProjects\n- pglite-cache - open source PostgreSQL query-result cache\n GitHub: github.com/wei/pglite-cache\n Built the eviction policy, benchmark suite, and README examples for a Go\n library used in two internal tools.\n```\n\n\n**Why the better version works:** The smaller tutorial-style apps do not add much for someone with professional engineering experience. The open source project is more useful because it shows technical depth and work that is different from the day job.\n\n---\n\n# Where Projects Fall Flat\n\nProjects compete with your work experience for limited space, so a weak entry costs you twice by adding clutter and pushing stronger material down the page.\n\n- **Listing every small project.** A long list makes the section harder to read. Choose the few that best support the role.\n- **Including projects with no detail.** \"Built an app\" is too vague. Explain the features, stack, and your contribution.\n- **Relying on broken or empty links.** A repo with no README or a broken demo weakens the entry.\n- **Listing tutorial projects without improving them.** A basic follow-along project rarely helps unless you extended it with your own work.\n- **Adding projects that do not support your target role.** Space is limited. Use it for evidence that matters.\n- **Overstating usage or scope.** Be specific, but do not inflate. You should be able to explain every claim in an interview.\n- **Hiding your own contribution in team projects.** Say what you personally built, tested, designed, or maintained.","pageType":"job-search"}

Get Premium