How I Spot a Copy-Pasted Java Developer Project in Minutes

TEXTBOOK STRUCTURE — READ AS AN
INTERVIEWER:

Candidate: "I built a Spring Boot
e-commerce app. The structure is
controller, service, repository, entity,
dto."

What I notice:
- The package structure is exactly the
  tutorial's structure.
- There's no "custom" package, no helper,
  no exception hierarchy that doesn't fit.
- The README is the same as the tutorial's
  README, down to the screenshots.

What it signals:
❌ The project is a tutorial
❌ No custom decisions
❌ No extra layers or complexity
❌ The candidate followed, not built

What I do next:
- I ask: "What did you change from the
  tutorial?"
- If they can name a real change, they
  recover.
- If they can't, the project is a
  copy-paste.

The tell:
"controller/service/repository/entity/dto"
is a textbook. A real project has
"controller/service/repository/entity/dto"
plus "custom/", "exceptions/", "config/",
and a "README" that explains the
compromises.

Why it matters:
- A real project has a fingerprint
- The fingerprint is the compromises
- The compromises are the evidence

NO FAILURES — READ AS AN INTERVIEWER:

Candidate: "The project has a user service,
an order service, and a payment service. It
uses PostgreSQL, Redis, and Kafka. It's a
microservices architecture."

Interviewer: "What broke, and how did you
fix it?"

Candidate: [pause] "Nothing really broke.
The project ran fine."

What I notice:
- The candidate can describe the
  architecture.
- They can't describe a failure.
- "Nothing really broke" is the tell: the
  project was never run under real
  conditions.

What it signals:
❌ No production experience
❌ No debugging story
❌ No failure handling
❌ The project is a tutorial

What I do next:
- I ask: "What's the hardest bug you
  debugged in the project?"
- If they can tell a story, they recover.
- If they can't, the project is a
  copy-paste.

The tell:
Every real project has a failure story:
- A migration that broke a table
- A connection pool that ran out
- A Kafka consumer that OOM'd
- A race condition in the payment flow

"No failures" means the project was never
tested beyond the happy path.

Why it matters:
- Failures are where the job lives
- A project with no failures has no
  evidence
- A candidate with no failures is a
  tutorial graduate

"WHAT DID YOU CHANGE FROM THE TUTORIAL?"
— READ AS AN INTERVIEWER:

Candidate: "I followed the tutorial. I
didn't change much."

Interviewer: "So the project is the
tutorial?"

Candidate: [pause] "I added a few things.
I changed the database password."

What I notice:
- "I didn't change much" is the tell.
- "I changed the database password" is not
  a change — it's a config.
- The candidate has no ownership of the
  project.

What it signals:
❌ The project is a tutorial
❌ No custom decisions
❌ No ownership
❌ The candidate is a tutorial graduate

What I do next:
- I ask: "What would you change if you
  rewrote it?"
- If they can reason about improvements,
  they recover.
- If they can't, the project is a
  copy-paste.

The strong answer:
"I changed three things. First, I added a
custom exception handler — the tutorial
returned stack traces to the client, which
is a security issue. Second, I added a
retry policy for the payment service, with
an idempotency key. Third, I added a
Prometheus metric for the order rate,
because the tutorial had no monitoring."

Why it works:
✅ Three real changes
✅ The reasons are clear
✅ The changes are security and
  reliability improvements

"WHAT BROKE, AND HOW DID YOU FIX IT?" —
READ AS AN INTERVIEWER:

Candidate: "Nothing broke. The project ran
fine."

Interviewer: "Did you deploy it?"

Candidate: [pause] "I ran it locally. I
didn't deploy it."

What I notice:
- "Nothing broke" is the tell.
- "I ran it locally" is the confirmation:
  the project was never under real
  conditions.

What it signals:
❌ No production experience
❌ No debugging story
❌ The project is a tutorial
❌ The candidate can't handle failure

What I do next:
- I ask: "What would you do if the
  service crashed in production?"
- If they can reason about debugging, they
  recover.
- If they can't, the interview is over.

The strong answer:
"The Kafka consumer OOM'd twice. The first
time was a memory leak in the offset
tracking — we were holding references to
processed records. I took a heap dump,
found the leak, and moved the offset
tracking to a separate class. The second
time was a batch size that was too large
for the heap, and I fixed it by reducing
the batch size and adding a dead-letter
queue."

Why it works:
✅ Two real failures
✅ The debugging method: heap dump
✅ The fixes: offset tracking, batch size
✅ The prevention: dead-letter queue

FULL EXTENSION — THREE ADDITIONS:

Interviewer: "Tell me about your Spring
Boot project."

WHAT YOU SAY:
"Sure. I want to be honest: I started with
a tutorial project, then extended it with
three changes. Let me walk through each.

The first change was the database. The
tutorial used MySQL; I moved to PostgreSQL
because the reporting queries needed window
functions. The trade-off was the learning
curve — I hadn't used PostgreSQL before —
but the reporting queries went from 30 lines
of application code to one SQL query.

The second change was the exception handler.
The tutorial returned stack traces to the
client, which is a security issue. I added a
custom handler that returns a clean error
response with an error code, and I logged
the stack trace server-side.

The third change was monitoring. The
tutorial had no metrics. I added Prometheus
and a Grafana dashboard for the order rate,
the error rate, and the p99 latency.

The result: the project handles 200 req/sec
with p99 under 120ms on a $40/month
instance. I also broke it twice and fixed
it both times. The worst was a Kafka consumer
OOM — I took a heap dump and found a memory
leak in the offset tracking."

What the interviewer thinks:
- "They were honest about the tutorial." ✅
- "Three real changes with reasons." ✅
- "Real numbers: 200 req/sec, p99 120ms,
  $40/month." ✅
- "A real failure: Kafka consumer OOM." ✅
- "This is a tutorial plus evidence." ✅
Signal: strong hire.

Why it works:
✅ Honest: it started as a tutorial
✅ Three real changes with trade-offs
✅ Real numbers
✅ A real failure and fix

THE FAILURE STORY — FIVE PARTS:

Interviewer: "What broke, and how did you
fix it?"

WHAT YOU SAY:
"Sure. I'll walk through it in five parts:
the symptom, the debugging, the root cause,
the fix, and the prevention.

The symptom: the Kafka consumer was OOMing
every 3–4 days. The heap would grow, the
process would crash, and the consumer group
would rebalance.

The debugging: I took a heap dump with jmap
and compared retained sizes over time. The
biggest retained object was a static map
with about 200MB of processed records.

The root cause: we were holding references
to every processed record in a static map,
which was meant to be a deduplication cache.
But the map never evicted entries, so it
grew without bound.

The fix: I removed the static map and used
Kafka's built-in offset management for
deduplication. The consumer has run for 90
days without an OOM since.

The prevention: I added a heap-dump check to
the post-deploy checklist, and I added a
Prometheus alert on heap usage at 80%.

The lesson: static state in a long-running
consumer is a leak waiting to happen. I've
since avoided static state in any consumer."

What the interviewer thinks:
- "Symptom: OOM every 3–4 days." ✅
- "Debugging: jmap, retained sizes." ✅
- "Root cause: static map, no eviction." ✅
- "Fix: offset management, 90 days no OOM." ✅
- "Prevention: heap-dump check, alert." ✅
Signal: strong hire.

Why it works:
✅ The symptom is specific
✅ The debugging method is named
✅ The root cause is a real bug
✅ The fix is concrete
✅ The prevention is measurable

Project Audit Checklist:

FOR EACH PROJECT:
☐ One change from the tutorial, with the
  reason
☐ One failure, with the root cause and fix
☐ One number: latency, throughput, cost,
  or coverage
☐ One trade-off you accepted
☐ One thing you'd do differently

BEFORE THE INTERVIEW:
☐ Write the change story: what and why
☐ Write the failure story: five parts
☐ Write the number: the metric and how
  you measured it
☐ Practice all three in under 2 minutes
☐ Record and listen for "I followed the
  tutorial"

RED FLAGS IN YOUR OWN ANSWERS:
❌ "I followed the tutorial" with no
  changes
❌ "Nothing broke" with no failure story
❌ "The tutorial used MySQL" with no
  reason
❌ No number anywhere
❌ No trade-off, no lesson
❌ The project sounds like a tutorial

THE AUTHENTICITY TEST:
For each project, ask yourself:
1. "Can I name one change I made, and
  why?"
2. "Can I name one failure and the fix?"
3. "Can I name one number?"

If any answer is no, that's the addition to
make before the interview.

Why this works:
- A tutorial plus one change is evidence
- A tutorial plus one failure is experience
- A tutorial plus one number is measurement
- The three additions are the fingerprint
  of a real project

30-DAY AUTHENTICITY PLAN:

Week 1 — The change
☐ Pick one tutorial project
☐ Change one thing: the database, the
  monitoring, the error handling
☐ Document the reason and the trade-off
☐ Deploy it and measure the result

Week 2 — The failure
☐ Break the project on purpose
☐ Debug it: take a heap dump, check the
  logs, trace the request
☐ Document the symptom, the root cause,
  and the fix
☐ Write a postmortem

Week 3 — The number
☐ Measure the project: latency, throughput,
  cost, or coverage
☐ Add monitoring if it's missing
☐ Write the number and how you measured it
☐ Practice the three additions together

Week 4 — Mock interview
☐ Have a peer ask: "Tell me about your
  project"
☐ Give the extended story: change,
  failure, number
☐ Have them ask: "What did you change
  from the tutorial?" and "What broke?"
☐ If you pause, that's the addition to
  practice

Signs it's working:
✅ You can name a real change, with the
  reason
✅ You can name a real failure, with the
  fix
✅ You can name a real number
✅ You can tell the story in under 2
  minutes
✅ The interviewer asks "tell me more"
  instead of "so it's a tutorial"