"Build something impressive" sounds helpful, but it is too vague to act on.

A good project depends on the role you want. For a beginner, a small project that works, is easy to try, and solves a clear problem can be strong. For a more experienced engineer, that same project may look too basic unless it shows deeper judgment.

The goal is not to build the biggest app you can imagine. The goal is to choose a project that gives a hiring manager the right evidence for your level and role.

Good project ideas usually come from real problems: something you needed, something a friend or team struggled with, or something missing from a tool you already use. A real problem gives the project a reason to exist. It also gives you a better story than, "I built this to learn a framework."

Choose a project by combining three things: the level you are targeting, the role you want, and a real problem you can actually finish solving.

Your target level matters because hiring managers read projects in context. A new grad benefits from showing that they can finish and explain a working application. A mid-level engineer benefits from showing ownership, good judgment, and the ability to work with real constraints. A senior engineer usually needs to show deeper technical decision-making, such as performance work, reliability, architecture trade-offs, migration work, or a meaningful open-source contribution.

Your target role matters because different roles look for different evidence. A frontend project should feel usable and polished. A backend project should show sound data handling, APIs, deployment, and reliability. A machine learning project should use a real dataset, a clear metric, and an honest explanation of where the model works and where it does not.

The real problem matters because it keeps the project grounded. If the idea comes only from a generic project list, you may end up with features but no clear purpose. If the idea comes from a real need, you can explain who it helps, what it solves, and how you knew the first version was good enough.

One rule applies at every level: finished beats oversized. A small project that works, is documented, and has one thoughtful technical decision is more useful than an ambitious project with several half-built features.

The three inputs lead to one project choice, and that project should give one clear signal for the role you want.

When all three inputs line up, the project is easier for a reviewer to understand. When one is missing, the project often feels too basic, aimed at the wrong role, or too large to finish well.

Start with the roles you are actually applying for

Write down the level and role type you are targeting: new grad frontend, junior full-stack, mid-level backend, senior platform engineer, or whatever fits your search.

Do not design a project for a job you are not applying to yet. The project should support the next role you want, not a role that is several steps away.

Pick a scope that matches that level

Use the table below as a guide. If you are early in your career, the strongest signal is often a complete project that someone can use or review without much effort. If you are more experienced, the strongest signal is usually judgment under constraints.

That does not mean beginners should avoid hard problems or seniors should never build simple tools. It means the project should give evidence that matches the expectations of the role.

Find the idea from a real problem

Look for problems in places you understand:

You do not need a dramatic idea. You need a specific problem you can explain clearly and solve well.

Match the project to the role's signal

Ask what the hiring manager needs to believe after seeing the project.

For frontend, they need to believe you can build a usable interface. For backend, they need to believe you can model data, expose clear APIs, and run the service reliably. For full-stack, they need to believe you can connect the database, backend, and user interface into one working flow. For machine learning, they need to believe you can evaluate results honestly, not just run a notebook.

Each role wants the project to prove a different thing.

Pick the project so it puts the right evidence in front. A frontend project should look and feel usable, while a backend project should show data handling and reliability over visual polish.

Cut the scope until you can finish it

Write down the smallest complete version. If it will take more than a few weeks of evenings, reduce it. Remove nice-to-have features before you remove the core problem.

For example, an expense splitter does not need social feeds, avatars, notifications, and mobile apps. It needs users, groups, expenses, settlement logic, and a clean way to try it.

Choose one project and finish it properly

Brainstorm several ideas, then commit to one. Starting three projects can feel productive at first, but one finished project creates stronger portfolio evidence than several unfinished repositories.

These ranges are only a guide. Titles vary across companies, and years of experience do not always map cleanly to skill level. Use the table to decide what kind of evidence your project should provide.

For a beginner, a deployed project with a simple idea can be excellent if it works well and is easy to understand. For a senior engineer, a personal app can still be useful, but it usually needs a stronger technical angle, such as scale, reliability, security, maintainability, or a difficult trade-off.

Different roles reward different details. Aim the project at the evidence your target role cares about.

Your project does not need to cover every item in the list. It should include enough of the right details that the connection to the role is easy to see.

The same broad idea can be shaped differently depending on experience level.

Beginner / new grad:

Why it works: It is complete, solves a real problem, and gives the candidate something specific to discuss. A hiring manager can see follow-through, not just coursework.

Junior to mid-level:

Why it works: It solves a real workflow problem, integrates with a tool engineering teams already use, and shows initiative. It is also small enough to finish and maintain.

Senior:

Why it works: The work was reviewed publicly, the problem is specific, and the fix includes evidence that it works. For senior roles, that depth is often more persuasive than a brand-new personal app.

Picking the wrong project usually means missing the level the role expects, either by aiming too low or reaching past what you can finish.

Write down three possible project ideas. For each one, name the target role, the level it supports, the real problem it solves, and the main technical decision you would be able to discuss in an interview.

Then choose the idea you can finish cleanly. A finished, honest project is usually more valuable than a large idea that never becomes usable.