Interview Insights · React Developer
How I Spot a Copy-Pasted React Developer Project in Minutes
Quick summary — Copied React projects
A copied React project is easy to spot because the candidate cannot explain the decisions that someone else made. I am not hunting for copied code to embarrass anyone. Most developers learn from tutorials, and reusing patterns is normal. What I need to know is which parts you understand and can change. The quickest signals come from the commit history, leftover boilerplate, inconsistent code styles and, most of all, a simple 'why is this here?' question. This page shows what I look at, what each sign means, and how to turn a tutorial project into honest work you can defend.
In this guide you will learn:
- The repo signals I check in the first minute
- Code smells that suggest pasted sections
- The why questions that reveal real understanding
- A live-change test and how to pass it calmly
- How to make a tutorial project your own honestly
SECTION 01What the repository tells me before you speak
Before the interview, or during it, I often open the GitHub link on the resume. The repository tells a story without any words. A project built over time has many small commits with messages that describe real changes. A copied project often arrives in one huge commit called 'initial commit' or 'first', sometimes with the original author's README still in place.
None of these signals proves anything alone. A developer might have built a project locally and pushed it once. But together they shape the questions I ask next.
| Repo signal | What I see | What it may suggest | What I ask next |
|---|---|---|---|
| Commit history | One commit with all files | Code pasted or built elsewhere | How did the project evolve? |
| README | Original tutorial title or author credit | Unchanged clone | What did you add beyond the tutorial? |
| Leftover boilerplate | Default logo, unused test files, sample CSS | Little real ownership | Why is this file still here? |
| Dependencies | Libraries in package.json never imported | Copied setup | What is this package used for? |
# Commits in order, with files changed
git log --reverse --stat --oneline | head -40
# How many commits, over how many days
git log --format=%ad --date=short | sort -u | wc -l
# Which packages are listed but never imported?
npx depcheck
# Find leftover starter files
git ls-files | grep -Ei "logo|serviceWorker|reportWebVitals"a1c3e2f Set up Vite + React, add ESLint
4b7d901 Add product list with mock data
9e2a114 Fetch products from API, add loading state
c81f0aa Add cart reducer: add, remove, quantity
2d4e7b3 Fix: quantity could go below 1
7f90c12 Persist cart to localStorage
0aa3b6d Add tests for cart reducer
5c2e8d1 Make cart drawer keyboard accessible
Small steps, real fixes, a test commit.
This history tells me someone actually built it.
Notice the commit 'Fix: quantity could go below 1'. Commits like this are gold in an interview, because they point to a real bug you found and fixed. Copied projects almost never have them.
SECTION 02Code smells that suggest pasted sections
When I scan the code, I look for consistency. A developer who wrote the whole project usually has habits: they name handlers the same way, fetch data the same way and style components the same way. A project assembled from several tutorials has visible seams. One file uses class components, another uses hooks; one uses Axios, another uses fetch; one has CSS modules, another has inline styles.
Mixed styles are not wrong in themselves, since real codebases evolve. But in a small fresher project, sharp seams often mean pasted sections the candidate has not fully read.
| Smell | Example in a React project | Why it raises doubt | Honest explanation that helps |
|---|---|---|---|
| Mixed component styles | Class component next to hooks | Sections may come from different sources | I started with a class tutorial, then moved to hooks |
| Two data-fetching patterns | Axios in one file, fetch in another | No single decision was made | I switched to fetch and did not refactor the old file |
| Unused props and state | isOpen state set but never read | Code was pasted, not understood | That is dead code, I should remove it |
| Comments in another voice | Explanations addressed to 'you, the viewer' | Lines copied from a video or blog | Those comments came from the tutorial |
export const initialCart = { items: [] };
export function cartReducer(state, action) {
switch (action.type) {
case "add": {
const found = state.items.find((i) => i.id === action.item.id);
if (found) {
return {
items: state.items.map((i) =>
i.id === action.item.id ? { ...i, qty: i.qty + 1 } : i
),
};
}
return { items: [...state.items, { ...action.item, qty: 1 }] };
}
case "setQty":
return {
items: state.items.map((i) =>
i.id === action.id ? { ...i, qty: Math.max(1, action.qty) } : i
),
};
case "remove":
return { items: state.items.filter((i) => i.id !== action.id) };
default:
throw new Error(`Unknown action: ${action.type}`);
}
}Questions I ask about this reducer:
1. Why return a new object instead of pushing
into state.items?
(React compares references; mutation can skip
re-renders and breaks predictable updates.)
2. Why Math.max(1, action.qty)?
(Quantity should never be zero or negative;
removing is a separate action.)
3. Why throw in the default case?
(A typo in an action type fails loudly instead
of silently doing nothing.)
An author answers these in seconds. A copier
usually knows what the code does but not why.
The Math.max line usually exists because of a real bug, the same one in the healthy commit history above. That is why I ask about it. People who wrote it remember the bug.
SECTION 03The live-change test and how to pass it
When I am still unsure, I ask for a small live change. Add a 'clear cart' button. Show the total price. Make the search ignore case. These changes take a few minutes for someone who knows the code. For someone who copied it, they often take much longer, because the person must first discover where things live.
This test is not about speed. A candidate who says 'the total belongs in a derived value from the cart items, so I will add it here' and then edits the right file is showing ownership, even if they make a typo along the way.
| Change requested | Where it should go | Sign of ownership | Sign of confusion |
|---|---|---|---|
| Add a clear cart action | New reducer case plus a button | Adds case and dispatch quickly | Edits the wrong component first |
| Show cart total | Derived from items during render | Uses reduce, no new state | Adds a total state and forgets to update it |
| Case-insensitive search | The filter function | Lowercases both sides | Searches for where filtering happens |
| Disable add when out of stock | Product card props | Passes a prop, adds disabled | Changes global styles |
// 1. New reducer case
case "clear":
return initialCart;
// 2. Derived total, no extra state
const total = cart.items.reduce(
(sum, i) => sum + i.price * i.qty,
0
);
// 3. Formatting for Indian rupees
const label = new Intl.NumberFormat("en-IN", {
style: "currency",
currency: "INR",
}).format(total);
// 4. Wiring in the component
const onClear = () => dispatch({ type: "clear" });'The cart lives in a useReducer in CartProvider,
so clearing it is a new action. I will add a
"clear" case that returns initialCart.
For the total, I will not add state, because it
can be calculated from items. Storing it would mean
keeping two things in sync.
I will format it with Intl.NumberFormat for INR.'
Even before typing, this narration tells me the
candidate knows where everything lives.
If you get the live-change request, narrate where the change belongs before you open any file. That one sentence answers the ownership question before the code is even written.
SECTION 04How to make a tutorial project honestly your own
You do not need to hide that a project started from a tutorial. You need to go beyond it and understand every part. Use this three-step plan before you list a tutorial-based project on your resume.
STEP 1: REBUILD FROM MEMORY
Close the tutorial. Rebuild the core feature
in a fresh Vite project without looking.
Note every place you got stuck.
STEP 2: ADD THREE FEATURES THE TUTORIAL DID NOT
e.g. cart persistence, keyboard support,
a filter that survives page refresh in the URL.
STEP 3: WRITE TESTS FOR YOUR LOGIC
At least the reducer or data helpers.
Commit each step separately with clear messages.## About this project
This started from a shopping cart tutorial.
I rebuilt it from scratch and added:
- Cart saved to localStorage and restored on load
- Quantity rules (minimum 1, max from stock)
- Keyboard-accessible cart drawer
- Unit tests for cartReducer (Vitest)
## Decisions
- useReducer over useState: cart has 4 actions
- Context only for cart; product data fetched per page
## Known limits
- No real checkout or paymentBEFORE THE INTERVIEW, CAN I...
[ ] Explain why every file exists?
[ ] Explain every dependency in package.json?
[ ] Name one bug I fixed and how?
[ ] Add a small feature live in under 10 minutes?
[ ] Explain one thing I would do differently?
[ ] Say honestly which parts came from a tutorial?
Any 'no' means more work before listing it.
SECTION 05Habits that prove a React project is yours
These habits make ownership obvious to any interviewer who looks at your work.
- Commit small and often — Each feature or fix in its own commit with a clear message builds a history that speaks for you.
- Keep one consistent pattern — Pick one way to fetch data and one way to style components, and refactor older files to match.
- Remove dead code — Unused state, props and files raise doubts. Delete them or explain them.
- Credit your sources — Mention the tutorial in your README. Honest credit plus clear additions looks far better than hidden copying.
- Keep a decisions list — Write down why you chose each library or pattern. Reading it before interviews keeps answers fresh.
SECTION 06Interview Q&A — Copied React projects
Q1Did you build this project yourself?
Answer honestly and specifically. For example: 'The base came from a tutorial, but I rebuilt it from scratch and added persistence, quantity rules and tests.' Then offer to show the commits. Honesty with detail is the strongest answer.
Q2Why does your reducer return a new object instead of changing the state?
React compares state by reference. If I mutate the existing object, the reference stays the same and React may skip the re-render. Returning a new object keeps updates predictable and works with tools like React DevTools.
Q3Can you add a total price to the cart now?
Explain where it belongs before coding: the total can be derived from cart items with reduce during render, so it does not need its own state. Then add it and format it with Intl.NumberFormat if currency display is needed.
Q4Why do some files use Axios and others use fetch?
Be honest: 'I started with Axios from a tutorial, then switched to fetch for new code and did not refactor the old file.' Then say which you would choose now and why. Admitting an inconsistency calmly is better than inventing a reason.
Q5What did you add that the tutorial did not have?
Name specific additions and the reason for each, such as localStorage persistence because users lost their cart on refresh, or keyboard support for the cart drawer. Point to the commits that added them.
SECTION 07Test yourself — Copied React projects quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Is it okay to put a tutorial React project on my resume?
It is acceptable if you clearly extend it and understand every part. Mention the source in the README, add your own features and be ready to explain and change the code live.
Can interviewers tell if I copied my React project?
Often, yes. Commit history, inconsistent code styles, leftover boilerplate and difficulty explaining decisions usually show it within a few minutes, especially when they ask for a small live change.
How do I make my React project unique?
Solve a small real problem, add features beyond any tutorial, such as persistence, accessibility or URL-based filters, write tests for your logic and keep a clear commit history.
What React projects are considered too common?
Basic to-do apps, weather apps and streaming-site UI clones are very common. They are fine for learning, but they stand out only when you add real features and can explain your decisions.
Should I show my GitHub in a React interview?
Yes, if the repositories are clean and you understand them fully. Pin your best projects, add READMEs with decisions and limits, and remove forks or half-finished copies you cannot explain.
Does Uncodemy help with React Developer interview answers?
Yes. Uncodemy's React JS Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise React Developer interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Build React projects you can truly defend
Our React JS Training Course is project-based, with code reviews and live-change practice, so every project on your resume is one you understand line by line.
Talk to a counsellor for current fees- Guided React projects
- Git and code reviews
- Live-change practice
- Weekday & weekend batches