Technical hiring in India: from structured job descriptions to confirmed joining

Most technical job descriptions are a list of every technology the team has ever touched. That makes screening almost impossible, because nearly every candidate matches some of it and nobody matches all of it. The fix is to split requirements explicitly into must-have and good-to-have, and to keep the must-have list short — usually four to six items that a person genuinely cannot do the job without on day one.

Each requirement should be written so that a reviewer can recognise evidence of it. "Strong Java" is not testable; "has built and maintained Spring Boot services in production, including handling of transactions and error paths" is. The same applies to seniority: instead of "5+ years", describe the responsibility you expect, such as owning the design of a service, mentoring two or three engineers, or running on-call for a production system.

A resume that repeats "microservices, Kubernetes, Kafka" twenty times tells you what the candidate wants you to see, not what they have done. The more reliable signal is project evidence: a description of a specific piece of work detailed enough that you could ask follow-up questions about it. Good project evidence answers five questions — what problem was being solved, what the candidate was personally responsible for, which technologies they used, at what scale, and what the outcome was.

When a resume is thin on these details, that is not automatically a negative. Many strong engineers in services companies write short resumes because their project work is under client confidentiality. The right response is to mark the requirement as "partial evidence" and ask about it in the first conversation, rather than rejecting on the basis of what the document happens to omit.

No single assessment format is best for every role. Take-home assignments let candidates work in a realistic environment and suit roles where design quality matters more than speed, but they cost candidates evenings and weekends — a real barrier for people already working long hours with a notice period ahead of them. Keep them short, time-boxed and clearly scoped, and review them against a written rubric.

Live coding sessions are fast and let you see how someone thinks, but they reward interview practice as much as engineering ability, and they can disadvantage people who are anxious under observation. If you use them, make them collaborative: allow documentation lookups, talk through the approach, and focus on reasoning rather than whether the candidate recalls an algorithm from memory.

Role-specific assessments often give the clearest signal. For a backend engineer that might be debugging a failing service or reviewing a pull request; for a data engineer, reasoning about a broken pipeline; for a DevOps engineer, walking through an incident. These exercises resemble the actual job, which makes them both more predictive and more respectful of the candidate's time.

Bias in technical hiring usually enters through shortcuts: preferring certain college names, penalising career gaps without asking about them, treating accent or fluency as a proxy for competence, or favouring candidates whose background resembles the interviewer's. None of these predict job performance well, and several of them systematically exclude capable people, including those returning after caregiving breaks.

The most effective counter-measures are structural. Use the same requirements, the same questions and the same scoring rubric for every candidate in a role. Have interviewers record evidence and scores independently before any debrief, so that the most senior or most confident voice does not set the outcome. And never let any tool — AI or otherwise — infer or filter on protected attributes such as gender, religion, caste, age or disability.

A typical loop for a mid-level engineer might include a recruiter screen, one technical screen, one deeper technical or design round, and a hiring-manager conversation. Each round should have a distinct purpose tied to specific requirements, so that two interviewers are not both testing the same thing while nobody tests another. Write that mapping down before the first candidate is scheduled.

Speed matters. Strong candidates in India often have multiple processes running in parallel, and a loop that stretches over three weeks invites them to accept elsewhere. Aim to complete the loop within a week or two, give feedback promptly after each round, and tell candidates what the next step is and when to expect it.

Notice periods in Indian tech commonly range from 30 to 90 days, with 60 and 90 days frequent in larger services companies. That gap between offer acceptance and joining is where many hires are lost. Build it into your planning from the start: ask about notice period, whether it is negotiable and whether a buyout is possible in the very first conversation, and factor it into the role's start date.

Be realistic about buyouts. Some employers will release a candidate early if a new employer pays the remaining notice, some will not, and policies vary by company. Do not promise a start date that depends on a buyout the candidate has not yet confirmed with their current employer.

Offer drop-off — candidates accepting and then not joining — is a familiar risk, often driven by counter-offers from the current employer or a later competing offer. You cannot eliminate it, but you can reduce it by staying in touch. Schedule regular check-ins during the notice period, introduce the candidate to their future manager and team, share onboarding information early, and ask directly whether anything has changed.

Treat joining as the real end of the pipeline. Track expected joining dates, confirmation of resignation, and the actual joining day as distinct stages, so that a drop-off is visible early enough to reopen the pipeline or move to a backup candidate.

RecruitGPT is built around the evidence-first approach described above. It structures a job description into must-have and good-to-have requirements, structures resumes into projects, skills and responsibilities, and shows for each requirement whether there is evidence found, partial evidence or no evidence yet. Every data point carries a provenance label — Candidate Provided, AI Extracted, Candidate Confirmed, Verified or Not Verified — and "Verified" is only used when a human reviewer has actually checked the item.

The AI does not reject candidates, does not hire candidates, and does not produce an opaque fit or hireability score. It does not infer protected attributes. Recruiters review the evidence, decide who moves forward through stages such as reviewed, shortlisted, interview, offer and hired, and remain accountable for every decision.