Every fresher is told to build a portfolio. Almost nobody is told what to build, which is why the same three tutorial projects appear on thousands of resumes: a to-do app, a movie recommender, and a Titanic survival model.

Those are worse than having nothing. Not because they are badly built, but because an interviewer has seen them four hundred times and knows exactly which tutorial produced them. A project everyone has done cannot distinguish you, and it quietly signals that you followed instructions rather than made decisions.

The useful way to choose portfolio projects for freshers is to work backwards from the interview. A project’s real job is to earn you a question you can answer better than anyone else in the queue. Here are six that do, each buildable in a weekend or two, and none of which has a tutorial.

What interviewers are actually testing

Junior interviews are not really checking whether you can write code. That gets tested in the online round. The conversation is checking three things that are much harder to fake: whether you can make a decision when the answer is not given, whether you notice when something is wrong, and whether you can explain either of those to someone who was not there.

A tutorial project cannot demonstrate any of them, because every decision was made for you. That is the whole problem, and it is why the fix is not “build something more impressive” but “build something where you had to choose”.

1. Clean somebody’s genuinely messy data

Build: find a real, ugly public dataset — India’s Open Government Data platform is full of them — and turn it into something usable. The deliverable is the clean file plus a documented list of every judgement call you made and why.

What it proves: that you can act under ambiguity. Real data has duplicate rows that are not quite duplicates, dates in four formats, and categories that overlap. Every one of those is a decision with no correct answer.

The question it earns: “Tell me about a time the data was wrong.” You will have twenty examples and a written record. Most candidates have nothing.

2. Try to reproduce a number from the news

Build: take a statistic from a recent article — ideally one about your own city or state — find the underlying public data, and try to reproduce the figure. Write up what you got and where the gap came from.

What it proves: analytical scepticism, which is rare and highly valued. You will usually not reproduce it exactly, and the explanation of why is the entire deliverable. Different date range, different denominator, a definition that shifted.

The question it earns: “How do you know your analysis is right?” Almost nobody has a real answer to this. You will.

This one is also the most interesting to talk about, which matters more in an interview than people admit.

3. A small tool that fixes your own annoyance

Build: something you personally use every week. A script that renames your files sensibly, a tracker for something you keep in your head, a bot that tells you when a form opens. Small and finished, not ambitious and abandoned.

What it proves: that you ship. Also that the project is genuinely yours — you can talk about it indefinitely because you use it, and interviewers can tell the difference between that and a rehearsed summary within about two questions.

The question it earns: “What would you do differently?” You will have a real answer, because you have lived with your own design mistakes.

4. Automate something for an actual person

Build: find someone who is not technical — a shopkeeper, a college society treasurer, a relative running a small business — and automate one thing they currently do by hand.

What it proves: requirements gathering, which is the skill nobody practises and every employer needs. Your stakeholder will describe the problem wrongly the first time. Working out what they actually need is the job.

The question it earns: “Tell me about working with a non-technical stakeholder.” For most freshers this question is fatal. For you it is the best story you have.

This is the project I would build first if I could only build one. It is also the one with a real user, which means a real outcome you can state.

5. Break something on purpose and diagnose it

Build: take a working open-source project, break it in three different ways, then document the symptom, how you tracked it down, and the fix. A wrong config, a bad dependency version, an off-by-one in a loop.

What it proves: debugging, which is what junior engineers spend most of their time doing and which no course teaches.

The question it earns: “Walk me through how you’d debug this.” You will describe a method rather than guessing, and the difference is immediately obvious to whoever is listening.

6. A one-page decision memo

Build: not a dashboard. Pick a question with a real answer — should this shop stock more of X, which of these two routes is actually faster — and answer it in one page. A recommendation, the evidence, and one line on what would change your mind.

What it proves: communication and judgement together, which is the scarcest pair in the market and the one AI is furthest from replacing. Dashboards show data. A memo takes a position.

The question it earns: “How do you present findings to someone senior?” The honest answer for most freshers is that they have never had to. Yours is a document you can attach.

The rules that make any project work

The specific six matter less than these four, which apply to whatever you build.

Finished beats impressive. A small complete thing outperforms an ambitious half-thing every time. Interviewers read an unfinished project as an unfinished person, fairly or not.

Write down the decision, not just the result. Three sentences in a README about what you chose and what you gave up is worth more than another feature. That paragraph is what you will actually talk about.

Make it checkable in thirty seconds. A link that works, a screenshot, a file someone can open. If verifying your claim takes effort, it will not be verified, and an unverifiable claim is worth roughly nothing in a market where employers say they hire for skills but struggle to see them.

Have a number, even a small one. “Cut a weekly task from two hours to ten minutes” is more persuasive than any adjective. Do not invent one — but if a real one exists, use it.

What to skip

Anything that is the first result on YouTube for “beginner project”. Anything where the dataset comes pre-cleaned. Anything where you cannot name a single decision you made. Clone projects that recreate a famous app without adding anything, which show you can follow a pattern but not that you can choose one.

And do not build ten. Two projects you can discuss in depth beat six you can summarise, because the interview goes deep on one and shallow on the rest, and depth is where the differentiation lives.

Where this fits

A portfolio does not replace applying, and it does not replace the skills underneath it. What it does is convert “I can do this” into something a stranger can check, which is the specific gap that stops good candidates from getting past a screen.

If you are applying without a campus placement behind you, this matters more, because a project is the closest thing you have to the credibility a brand-name college would have lent you. The rest of that process is in the off campus placement guide.

Frequently asked questions

Sources

• Harvard Business School and the Burning Glass Institute, Skills-Based Hiring: The Long Road from Pronouncements to Practice (2024) — on the gap between skills-first policy and practice. Accessed September 2026.
• Project selection and the interview questions each earns are Abekus analysis, based on the structure of entry-level hiring processes rather than on survey data.