What Separates a 6 to 10 LPA Candidate From the Rest

6 LPA Candidate:
"I built the login page with React and Node."

What the interviewer hears:
"They can implement a defined task."

What it signals:
- You can follow a spec
- You know the basics
- You need clear instructions

It gets the job — but at 6 LPA.

10 LPA Candidate:
"I owned the authentication flow for the
product. I chose JWT over sessions because
we needed stateless auth for mobile clients,
and I handled token refresh with a sliding
window. The trade-off was revocation — JWT
can't be invalidated server-side, so I added
a short-lived token + refresh token model."

What the interviewer hears:
"They can make decisions and defend them."

What it signals:
- You own outcomes, not tasks
- You think in trade-offs
- You can lead a feature

It gets the offer — at 10 LPA.

Ownership Gap Example:
6 LPA: "I worked on the payment page."
10 LPA: "I owned the payment flow. I integrated
Razorpay, handled webhooks, built retry logic
for failed payments, and wrote the on-call
runbook."

The difference:
- 6 LPA did a task
- 10 LPA owned an outcome

Ownership invites questions about edge cases,
failures, and decisions — which is exactly what
the interviewer wants to hear.

Trade-off Gap Example:
6 LPA: "I used Redis for caching."
10 LPA: "I used Redis for caching because the
read latency for our product listing page was
120ms. Redis brought it to 15ms. The trade-off
was cache invalidation — I used a TTL of 60s
for listings and event-based invalidation for
prices. I chose not to use write-through caching
because our writes are rare and correctness
matters more than speed."

The difference:
- 6 LPA names a tool
- 10 LPA explains a decision

Trade-off thinking is the strongest signal of
seniority — at any level.

6 LPA Answer:
"I built a to-do app with React and Node."

Interviewer: "Cool. What was interesting about it?"
You: "It had add, edit, and delete."

Interviewer: "Okay... anything else?"
You: "Not really."

The conversation ends here.

10 LPA Answer:
"I built a bill splitter for my flatmates. The
problem was that we kept arguing over who owed
what, so I built a small full stack app that
tracks shared expenses and calculates balances.

The interesting part was handling partial
payments — if someone paid half their share,
the balance had to update for everyone. I used
WebSockets so everyone's balance updated in
real time.

The trade-off was complexity — WebSockets are
harder to scale than polling, but for four users
it was the right call. The challenge was keeping
state consistent across clients. That taught me
a lot about real-time systems."

The conversation continues — at 10 LPA.