Choose and Build a Project That Mirrors Your Target Companies

Ask ten freshers what project to build and most will say an e-commerce site, a chat app or a clone of something famous. Those projects are not useless. Building one teaches a lot. But on a resume they all look the same, and they give an interviewer nothing new to ask about.

Now imagine a fresher applying to payments companies whose project is a small payment-retry service that never charges a customer twice, even when the network fails halfway through. An engineer at a payments company reads that line and recognises a problem their team deals with. The interview starts with a question the student is well prepared for, about a design they chose themselves. That is the difference this article is about.

• The mirror technique: choosing a project from your target companies' problem space.
• Where to find that problem space in public material.
• How to choose one hard part and scope a project to three or four weeks.
• Example projects by domain, including for services companies and non-development roles.
• How to build with AI help while keeping the decisions yours.

Pick three companies from the target group of your list (article 4). For each one, find out what technical problems they talk about publicly, then build a small project that lives in that problem space. Not a clone of their product, but something that shows you understand what makes their work hard.

Why it works:

• Recruiters and engineers recognise it. A project in their domain reads as relevant without explanation.
• It gives you better interview conversations. You can connect your design to theirs ("I handled retries with idempotency keys; I'd be curious how your team handles it at scale").
• It feeds your "why this company" answer (article 29) with something real.
• One project can serve a whole domain. A payments project is relevant to many fintech companies, not just one.

You need public sources only:

Collect five to ten bullet points per company. You will notice overlaps across companies in the same domain, and the overlaps are where your project should live.

Paste your notes, not the company name alone. An assistant asked about a company from memory may invent its architecture or describe it as it was years ago.

I am a fresher building one portfolio project for job applications.Here are notes I collected from job descriptions and engineering blog postsof three companies I am targeting:[paste your bullet points, with the source of each]My stack: [languages and frameworks I can already use].Time available: about [n] hours a week for 4 weeks.Suggest 3 project ideas that:1. Sit in the problem space my notes describe (quote the note each idea comes from).2. Have exactly one technically hard part that a tutorial would not solve for me.3. Can be built and deployed by one student in 4 weeks with my stack.4. Produce something a stranger can try through a link or a single command.For each: a one-line pitch, the hard part, what to measure, and what to cutif time runs short. Do not claim anything about how these companies buildtheir systems beyond my notes.

How to check the ideas: for each, ask whether you could explain the hard part to an engineer at one of those companies, and whether it fits four weeks honestly. If an idea needs three technologies you have never used, it is a reach; pick another or cut it down.

These are illustrations of the pattern, not a menu to copy. Your version should come from your own notes.

For services companies and many capability centres, the "hard part" can simply be quality: a complete, tested, documented application shows the discipline those employers value. For product companies and startups, the hard part should be a real technical problem.

• Data analyst: pick a public dataset from a domain your target companies work in (transport, retail, health), ask one concrete question, clean the data, answer the question with a dashboard and a one-page written finding.
• QA or SDET: choose an open-source web application, write a test plan, automate the most important user journeys, and file one well-written bug report if you find a real bug.
• Support: set up a small application on a Linux server, break it in realistic ways (a full disk, a wrong permission, a database connection failure), and write runbooks for diagnosing each.
• DevOps: take your own or an open-source project and build a pipeline that tests, builds a container, and deploys on every push, with the configuration in the repository.

If a project can be built by following a video step by step, it shows that you can follow steps. Every project on your resume should contain at least one decision you had to make yourself, with a trade-off you can explain:

• Why a relational database instead of a document store, for this data.
• Why retries use exponential back-off with a limit.
• Why the cache expires after five minutes and not one hour.
• Why you validate input at the API boundary instead of deep in the code.

Write each decision in a short DECISIONS.md file in the repository: the decision, the alternatives, and why. It takes ten minutes per decision and becomes your best interview preparation, because interviewers love "why" questions.

Students rarely fail by choosing too small a project. They fail by choosing one so large that it never ships. Scope in layers:

Have a "cut list" ready from the start: features you will drop if a week runs over. A deployed project with three features beats an undeployed one with ten.

AI assistants speed up a project a lot. Keep them in the roles where they help without replacing your thinking:

When you are stuck, a good request includes what you have already tried. It saves the assistant from suggesting things you ruled out, and it forces you to think first.

Context: I am building [one-line description] in [stack].Relevant code (only the parts involved):[paste code]The exact error and stack trace:[paste]What I expected to happen: [one line]What I have already tried and what happened: [list]What is the most likely root cause? Explain why before suggesting a fix.If my overall approach to this part is flawed, say so.

Read the explanation, then make the fix yourself. If the assistant's first answer does not work, tell it exactly what happened. Do not just paste the new error without context.

Many developer tools have free tiers or free student plans, and GitHub Education gives verified students access to a bundle of developer tools, which has included GitHub Copilot. Terms, limits and what is included change often, so check each tool's current page before you build around it (as of October 2026).

Lakshmi is targeting payments and fintech startups with a Java and Spring Boot background.

1. Notes. Across three companies' job posts and blogs she finds "payment failures", "retries", "webhooks", "reconciliation" and "idempotency".
2. Idea. A payment service that accepts payment requests, simulates a flaky payment provider, retries safely and sends webhooks to a merchant.
3. Hard part. Ensuring a payment is never processed twice, even when the client retries after a timeout. She uses an idempotency key stored with a unique constraint and a state machine (created, processing, succeeded, failed).
4. Scope. Week 1: create and fetch a payment, deployed. Week 2: idempotency and retries. Week 3: failure-case tests (duplicate requests, provider timeouts). Week 4: README, decisions file, measured behaviour under simulated failures.
5. Cut list. A dashboard, refunds, multiple currencies.
6. AI use. Project set-up and test scaffolding with an assistant; idempotency design and state transitions written herself and then reviewed by the assistant, which pointed out a race condition between two simultaneous requests with the same key. She fixed it with the database constraint and wrote that up as a decision.

That race condition became her best interview story: a real bug, found by review, fixed with a principled solution.

• Choosing a clone because it is familiar. Familiar to you also means familiar to every interviewer.
• Choosing a project with three hard parts. One hard part, done well, is plenty.
• No cut list. Without one, week four turns into week eight.
• Letting AI design the hard part. Then the best interview topic belongs to the assistant, not to you.
• Copying an example from this article without your own notes. The mirror technique works because the project connects to your targets.

## Short codes: counter + base 62 instead of random stringsDecision: generate each short code by taking the next value of a databasesequence and encoding it in base 62 (0-9, a-z, A-Z).Alternatives considered:- Random 7-character strings: simple, but collisions are possible, so every  insert needs a uniqueness check and a retry on collision.- Hash of the long URL: the same URL always gets the same code (sometimes  useful), but truncated hashes can collide and need handling.Why this choice: a sequence never collides, so inserts need no retry loop,and codes stay short (7 characters cover over 3.5 trillion values).Trade-off: codes are predictable, so someone can enumerate links. That isacceptable for this project because links are not secret; if they were,I would use random codes and handle collisions.

• Next: Ship It: Deploy, Document and Make Your GitHub Easy to Read turns the project into evidence a stranger can open.
• For a complete Java backend project walkthrough, see Project 3: The Job Application Tracker API, Assembled and Reviewed.
• For the idempotency idea used in the example, see Idempotency, Retries and Message Delivery Guarantees.