How to Verify an Indian Developer's Real Experience: A 2026 Buyer's Checklist

A resume from an Indian developer rarely outright lies, but it almost always smooths the truth. Tenure dates get rounded. Job titles get inflated. Tech stacks listed include things the candidate touched once. None of this is unique to India, but the screening processes most foreign buyers run are not built to catch it. This post is the verification checklist that is.

It covers documents to ask for and what they actually prove, how to verify employment history without trusting the resume, how to read a GitHub profile for honest signal, how to interpret a take-home or trial code sample, and how to run reference calls with India-based references that yield real information instead of polite nothing. Each step includes what good looks like and what should make you walk away.

Why does verification matter more for India hiring?

Two structural reasons that are not about trust, just about pattern.

Higher resume inflation in the Indian tech labour market. The supply of engineers is large and the competition for foreign-paying roles is fierce. The marginal candidate has a real incentive to round a 2.5-year tenure to "3 years" and to claim familiarity with frameworks they have only read about. This is true across every market with the same supply dynamics; it is just particularly visible in India because the pool is the world's largest.

Distance makes informal verification harder. A US buyer hiring a US engineer can usually rely on shared networks, alumni signal, and a same-city reference. None of those work across continents. The only signal you have is what the candidate sends you, plus what you can independently verify. So the verification process has to do more work.

Buyers who skip this end up with the body-shop pattern we have written a whole landing page about: the senior architect on the pitch deck quietly becomes a junior on day one. Verification is the cheapest insurance against that.

What documents should you ask for and what do they actually prove?

Five document types. None of them are invasive when handled correctly. All five together build a high-confidence picture.

1. Resume in PDF, plus a LinkedIn URL. Mismatches between the two are the cheapest signal you can buy. Tenure dates that differ, job titles that are different, employers that appear on one and not the other are all flags worth probing.
2. Form 16 from the last two financial years. Form 16 is an annual TDS certificate issued by every Indian employer to every salaried employee. It proves the employer existed, the candidate worked there, and roughly what they were paid. A candidate who cannot produce Form 16 for a recent claimed employer is either not asking nicely (Form 16 is the candidate's right to receive) or is misrepresenting the employment.
3. Last three payslips from the most recent employer. Confirms current employment and rough compensation. Less load-bearing than Form 16 but useful for the most recent role where Form 16 has not yet been issued.
4. Education certificate (degree + transcript). Verify the degree is from an institution recognised by the University Grants Commission (UGC). India has a long tail of unaccredited institutions whose degrees are not equivalent to a real engineering degree.
5. Government photo ID (PAN or Aadhaar). For background verification only, never as a public document. Confirms the person is who they say they are. Reputable vendors handle this with care under the DPDP Act.

A candidate who refuses to provide any of these is making a statement about their seriousness. Reputable engineers who want long-term roles understand the request and provide it. The cost of asking is low; the cost of skipping is high.

How do you verify the engineer's actual employment history?

This is the verification step that catches most resume inflation. Three independent methods, ranked by reliability.

1. EPFO UAN history (most reliable). Every salaried Indian employee has a Universal Account Number (UAN) issued by the Employees' Provident Fund Organisation. The UAN tracks every employer the candidate has worked for and the dates of contribution. Asking for the UAN passbook (which the candidate can download themselves from the EPFO portal) gives you a tamper-proof employment history. Cross-check this against the resume.

What good looks like: resume employers and dates match the UAN passbook within a month or two. Tenure rounding of a few weeks is normal.

Red flags: employers on the resume that do not appear in the UAN passbook (most likely fabricated), tenure differences over six months, gaps in the UAN history that the candidate cannot explain.

2. MCA entity verification. Indian companies are registered with the Ministry of Corporate Affairs. You can search for any claimed past employer to verify the company actually exists, its registration status, and roughly when it was incorporated. A "company" that does not appear in MCA records is either too small to be a real employer (a freelance arrangement marketed as a job) or a fabrication.

What good looks like: every employer on the resume is a registered entity in MCA records, with incorporation dates that pre-date the candidate's claimed tenure.

Red flags: employers that do not appear in MCA records, companies incorporated after the candidate's claimed start date, status of "Strike Off" for an employer the candidate claims they currently work at.

3. Direct reference calls (most context, lowest reliability). Call the candidate's named manager from a recent employer. The conversation should be 15 minutes, structured around three questions: what did the candidate actually own, how did they push back when something was wrong, and would you hire them again. India-based references can be polite to a fault; the third question is the one that breaks the politeness wall.

How do you read an Indian developer's GitHub for honest signal?

GitHub is the highest-signal artefact most candidates have. Most foreign buyers look at the wrong things.

Look at:

1. Contribution graph density and consistency over the last 24 months. Real engineers contribute regularly, in clumps that align with work and life rhythms. A pattern of one large burst of contributions in the month before the job hunt started is a known signal of profile-padding.
2. The actual repos they own (not forked). Open one or two and read the code. Not for production-ready quality, just for whether the structure, naming, commit messages, and pull request descriptions look like work the candidate could actually have done. A candidate's owned repos should match the level they claim.
3. Commit messages and pull request descriptions. A senior engineer writes clear commit messages and reviews their own PRs in writing. A profile full of one-word commits ("update", "fix", "wip") is a signal of inexperience or carelessness.
4. Issue and discussion participation. Engineers who genuinely use open source tend to file issues, ask questions, and participate in discussions. A profile with only commits and no conversation is either very early-career or very curated.

Do not over-weight:

1. Total commit count (easily padded with daily one-line commits to a personal repo).
2. Star count on owned repos (correlates more with marketing than engineering ability).
3. Number of languages listed in the profile sidebar (GitHub auto-detects this from any file in any repo, regardless of skill).
4. Recent fork-then-rename activity (a known pattern for inflating "owned" repo count).

Red flags: bursts of contribution activity timed to the job hunt, repos that are obviously forked then renamed without substantive changes, commit history that all happens at the same time of day every day for weeks (often a sign of automation, not real work).

How do you interpret the code sample they submit?

The code sample is where most verification processes either work or fail. Do it well and you catch most things; do it badly and you catch nothing.

Use a real ticket from your backlog, not a contrived problem. Contrived problems test test-taking skill. Real tickets test engineering ability. If you cannot share a real ticket for IP reasons, share an anonymised version.

Watch how they ask clarifying questions. A good senior engineer reads your spec, finds three things that are ambiguous, and asks. A weak senior engineer either asks nothing (and ships the wrong thing) or asks 30 questions before writing a line. Both are signals.

Read the code, then read the postmortem. If your trial scope includes a postmortem (it should), read both. The code shows whether they can write Python or React. The postmortem shows whether they understood the problem, the trade-offs they made, and the things they would do differently.

What good looks like: code that passes review at your normal bar, written in your house style, with clear PR description, sensible test coverage, and a postmortem that names the trade-offs honestly.

Red flags: code that does not pass your normal review bar, comments and naming patterns that look like they were generated by a copilot tool with no editing, a postmortem that reads like marketing copy ("I delivered a robust scalable solution") instead of engineering writing ("I traded latency for memory because the dataset is small enough that memory is not the bottleneck").

This is also the screen where AI-tooling fluency shows. An AI-native engineer in 2026 will absolutely use Cursor or Claude Code on the trial; pretending otherwise would be naive. The signal is not "did they use AI" but "did they review what AI produced." The ones who shipped AI-output without editing it produce the same code as anyone else. The ones who edited and improved it produce noticeably better code.

How should you run reference calls with India-based references?

Reference calls are the most underused verification step because most buyers do them badly.

Ask for managers, not peers. A peer reference is a polite reference. A manager reference is a useful reference. The manager has compared this engineer to other engineers and can give you signal that a peer cannot.

Schedule the call. Do not just call. Indian work culture treats unscheduled calls as rude. A scheduled 15-minute call gets thoughtful answers; an unscheduled call gets defensive ones.

Three questions to ask:

1. What did this engineer actually own end to end? (Tests whether the resume's "led" claims hold.)
2. Tell me about a time they pushed back on you or on a product decision. What happened? (Tests for the "yes-person" risk.)
3. If they reapplied to you tomorrow, would you hire them, and at what level? (The polite-wall-breaker. Most reference-checkers ask "would you hire them again" without the "and at what level" follow-on. The follow-on is what gets the honest answer.)

What good looks like: the manager has specific stories ready, names trade-offs the candidate handled well, and is direct about whether they would rehire.

Red flags: generic praise without specifics ("they were great", "everyone loved them"), inability to recall any pushback or disagreement (means they did not have any context on the candidate, OR the candidate was a yes-person), unwillingness to commit to "would you rehire."

What red flags should make you walk away?

Some signals are bad enough that no amount of charisma in the interview should override them. The fast-no list.

1. Cannot or will not produce Form 16 for a claimed past employer.
2. UAN history does not show a claimed employer (and the candidate cannot explain why).
3. Past employer does not appear in MCA records as a registered entity.
4. GitHub contribution graph shows a clear burst of profile-padding right before the job search started.
5. Code sample fails your normal review bar AND the postmortem cannot explain why.
6. Manager reference call refuses to commit to "would you rehire."
7. The candidate's described responsibility level does not match the seniority of the team they were on (a "tech lead" at a 5-person team is not the same as a "tech lead" at a 200-person team).
8. Resume and LinkedIn diverge on tenure or role title for the same employer, and the candidate cannot explain it cleanly.

Any one of these on its own is a yellow flag. Two or more together is a no.

What is a realistic verification checklist that will not slow your pipeline?

Most buyers either do too much (slowing the pipeline so the best candidates get scooped by faster vendors) or too little (signing the wrong person). The right balance, in the order to run it.

End to end, this fits inside a 10-day pipeline. Vendors who run a 1-week paid trial (we do, so do most well-run firms) collapse most of the verification into the trial week itself. The trial replaces a take-home, a code sample, and a partial reference signal in one shot.

What questions should you ask the vendor about their verification process?

If you are going through a managed vendor (us, Andela, Turing, Toptal), the verification work above gets folded into the vendor's process. Five questions to ask the vendor.

1. Do you verify UAN history before placing an engineer with a client?
2. Do you run MCA verification on the engineer's claimed past employers?
3. Do you run formal background verification (criminal, address, credential), and which vendor do you use?
4. Can I see the engineer's GitHub, last three employers, and references before the first interview?
5. If the engineer turns out to have misrepresented something post-placement, what is your replacement and refund policy?

A vendor who answers all five cleanly has thought about this. A vendor who hedges on any of them is hoping you will not look closely. We answer all five in writing on the first call, and the engineer's full verification report is part of the shortlist package, not an extra you have to ask for.

What to do next

If you are about to interview an Indian developer (through any vendor or independently), this checklist is the one to print. If you want us to apply it to a role you are about to open, book a 15-minute call and we will run the checklist on three of our pre-screened engineers for the role you have in mind. You see the verification reports before you decide whether to interview anyone.

Related reading: how we structurally avoid the body-shop staffing pattern covers why the verification matters in the first place. Staff augmentation vs EOR vs your own India entity covers the legal model decision. What to pay a senior Indian developer in 2026 covers the pricing decision. Together those three plus this verification post cover most of what a procurement-savvy CTO needs before signing.