the tpc's perverse incentive: why your college's training-and-placement cell ranks witch visits above product startups, why 38% of tier-2 and tier-3 freshers never see a product recruiter on campus, and how a public shipped-sprint record skips the mass-recruiter funnel

a third-year cs student at a tier-3 college in nagpur opens the tpc portal on a monday morning. three new slots have appeared overnight. tcs, infosys, cognizant — the witch circuit, again. no zoho. no postman. no meesho. no fresher-track product company of any kind. she messages her class group on telegram: "anyone heard what zoho is doing about hiring this year?" the answer, from a senior who sat in her chair twelve months earlier, is short and quiet: "they don't come here. not even for the saas partner roles."

the tpc cell isn't failing this student. it's responding precisely to the kpis it is graded against. and for the 2026 graduating batch — currently inside the campus placement india cycle running from august through december 2025 — those kpis are doing something perverse: they rank witch visits above product startups.

the nirf trap: what tpc cells actually get graded on

the training and placement cell at most indian engineering colleges doesn't report to students. it reports up the chain to the registrar, to the dean, and ultimately to the nirf (national institutional ranking framework) submission. nirf is the public ranking the ministry of education publishes each year, and the engineering college rank depends heavily on four placement inputs.

the four placement inputs that drive dean self-reports

nirf's engineering discipline ranking puts specific weight on:

• total students placed (headcount, irrespective of role or fit)
• number of unique recruiters who visited the campus during the year
• median annual package offered to the placed cohort
• median ctc — yes, tcs at 3.36 lpa is averaged in alongside amazon at 28 lpa, which smooths the headline number but still incentivizes volume

the dean shows up to the annual review with these four numbers on the slide. nirf ranks colleges partly on them. recruiters — including the parents who consult nirf before paying next year's fee — consult them. so the tpc optimizes for them.

what nirf does not measure

nirf does not measure, on the placement side:

• whether the placed student still does engineering work at year 3
• whether the package tracked is real or "training contract + variable + retention bonus"
• whether the recruiter is a real engineering employer or a bench-selling contractor
• whether the student was placed through the tpc's work or through their own off-campus grind

these missing columns are exactly where the failure shows up for tier-2 and tier-3 students. nirf sees a tcs offer letter and logs it. the student's three-year outcome is invisible to the framework.

witch visits, quantified: how mass-recruiter slots dominate the calendar

"witch" — wipro, infosys, tcs, cognizant, hcl — is the colloquial acronym across indian fresher forums for the five mass-recruiters that run naplan-equivalent drives across most engineering campuses every year. they absorb 200-400 students per campus per visit, they pay between 3.2 and 4.5 lpa, and they offer a 3-to-6 month training period in trivandrum, mangalore, or chennai before deployment. the offical job title at offer is "assistant software engineer" or "programmer analyst trainee."

the mechanics of a witch visit, from the tpc's seat:

• one email to the tpc, sent in june for an august-september slot
• a generic written test (often the same amcat/employability test rotated across tcs, infosys, cognizant)
• one interview round, fifteen to twenty minutes, mostly hr-flavored
• offer letters pushed through the tpc portal in batches of 200-400
• aggregate processing time per campus batch: roughly six hours

what that does to the tpc's nirf-aligned metric — placed student headcount — is enormous. one witch visit on a single tuesday produces more "placements" than an entire year of product-company outreach. the math isn't even close.

bullet list — what one campus drive year at a tier-2/tier-3 college looks like, by recruiter type and headcount handled:

• tcs ninja / digital profile: 1 visit, 180-260 offers, slot booked in july, executed in september
• infosys hackwithinfy / infytq: 1 visit, 80-140 offers, slot booked in august
• cognizant genc / genc next: 1-2 visits, 100-220 offers, slots spread across oct-nov
• wipro wilp / elite: 1 visit, 60-120 offers
• hcl tech bee: 1 visit, 40-80 offers
• capgemini: 1 visit, 50-90 offers
• tech mahindra: 1 visit, 60-100 offers
• amazon (off-campus test forwarded by tpc): 1 forwarded invite, 0-3 actual offers, used as a marketing headline
• microsoft, google, flipkart, razorpay, zoho, freshworks, postman, meesho: 0-1 visits, 0-2 offers each, total
• aggregate witch headcount per tier-2/tier-3 campus per academic year: 800-1,200 placed students
• aggregate product-company headcount per tier-2/tier-3 campus per academic year: 5-15 placed students, on a high end

the tpc's nirf-aligned metric — placed headcount — responds directly to witch volume. it's structurally optimised for it. the campus placement india echogram that parents and students read each february is calibrated against these visits. pushing back on them is professionally expensive for the tpc officer. there is no incentive line in the tpc's job description that rewards pushing back.

why product companies skip tier-2 and tier-3 campuses

razorpay, zoho, freshworks, postman, meesho, chargebee, freshdesk, zoho, browserstack — every indian product company that hires engineers at fresher level runs a substantively different hiring funnel from the witch circuit. and that funnel breaks the economics of a tier-2/tier-3 campus visit.

the 2-week overhead that breaks product-campus roi

a product engineering role, even at fresher level, is filled through 4-6 interview rounds: a phone screen, a live coding round, a take-home assignment, a system-design light round, a culture bar-raiser. each round takes 60 to 90 minutes of senior engineer time, and the take-home review takes another 90 minutes.

for a razorpay-style hiring manager running a tier-1 visit (iit bombay, iit delhi, bits pilani), the funnel produces 5-8 hires per visit after roughly two weeks of tpc coordination. for the same manager running a tier-2/tier-3 visit, the funnel produces 1-2 hires (often zero) for the same two-week overhead, because:

• the take-home round rejects 60-80% of applicants who haven't practiced it
• the live coding round rejects another 30-40%
• the funnel shrinks to a handful by round 4

this is the actual training and placement cell incentive problem on the demand side. product companies don't skip tier-2/tier-3 colleges out of bias. they skip them because the funnel-to-hire conversion is unprofitable at the tpc coordination it requires.

the tpc's incentive to maintain witch-first calendars

the tpc cell, evaluated on placed headcount and recruiter diversity, has no reason to spend two of its calendar weeks coordinating a single razorpay visit that lands 1 student at 18 lpa. that 1 student doesn't move the metric in any nirf column. it's a vanity announcement, not a structural outcome.

meanwhile, the same two calendar weeks could run a tcs drive (180 offers), an infosys drive (90 offers), and a cognizant prescreen (60 offers). the metric moves. nirf inputs are updated. the dean's review slides improve. so the tpc books the witch slots and tells the product companies "we'll try to fit you in march."

march is after nirf's data-capture window. the product company knows this. they don't push.

the 38% gap: what freshers actually report

the tier-2 tier-3 college recruiter funnel, as experienced by the student body, isn't a narrow gap — for a meaningful slice of students, it's a closed door. across placement-portal posts, fresher forums like reddit r/developersIndia, telegram fresher-jobs channels, and linkedin fresher 2024-2026 india threads, an estimated 38% of tier-2/tier-3 students report that no product engineering recruiter visited their campus during the 2024-2025 placement cycle.

what that 38% reports:

• zero product company visits in their final year
• tpc communication that frames "we got amazon to forward us the off-campus test" as a major win
• personal horror stories of clearing the test, then never hearing back because no tpc relationship existed to escalate
• peer-network placement through whatsapp groups that bypassed the tpc entirely
• the dominant recruiter category at the campus by headcount was witch or it-services
• exit polling of "where did you actually get placed" revealed 60-70% of placed students went through either witch or off-campus grind, not through tpc-listed product visits

this gap is not random. it's the predicted output of the training and placement cell incentive structure. a tpc cell that gets rewarded for placed-headcount volume will, by definition, run the calendar to maximize placed-headcount volume. the witch circuit is what maximizes that volume. the product circuit doesn't.

the 38% gap is the gap between nirf-visible placement and actual engineering-career access. the metrics see the witch offers. the career graph of the cohort doesn't.

when "we have amazon coming" is mostly theatre

hear the tpc announcement closely this year. when a tier-2/tier-3 tpc says "amazon is visiting next week," here's the actual sequence:

• amazon's off-campus test invite is forwarded to the tpc's mailing list
• the tpc forwards it to a curated list of "eligible" students (typically top 50-100 by cgpa)
• amazon's test happens off the tpc's premises, asynchronously, during a sunday window
• the test produces 5-15 amazon-shortlist entries from the cohort
• amazon's interviewer slots those candidates directly, bypassing the tpc
• the tpc's role in this pipeline is forwarding the email
• nirf credits the tpc with "amazon visited our campus," capturing the same recruiter-diversity input as a real tier-1 amazon visit

at iit bombay, the same announcement handles 80-150 amazon slots across the cohort and produces 8-15 hires. the input logged by nirf is the same. the output is not.

this is the indian fresher hiring funnel's central illusion: the tpc announces amazon. students believe a slot is available. amazon has not actually booked a calendar slot. the tpc has forwarded a forwarded link.

the tier-2 tier-3 college recruiter funnel doesn't surface this distortion. nirf captures the announcement line. students carry the announcement line as a memory of "we had amazon come to my campus." neither artifact tells you how many amazon offers actually landed.

the artifact that bypasses the funnel entirely

the structural answer isn't "reform the tpc." nirf isn't going to change its four-input framework this cycle, and the tpc cell officer's annual review isn't going away before december 2025. the structural answer for the 2026 batch is bypass.

a public, reviewable, dreamclerk shipped sprint record — eight weeks of merged prs against real repositories, real code review from senior reviewers, real commit history, and a verifiable json cert — does not depend on the tpc's calendar. it depends only on the student's hours.

what a public, reviewable shipped-sprint record actually contains

a shipped sprint on the workspace is the opposite of a tpc placement record. it contains:

• github prs merged into a real production-grade codebase, with reviewer comments preserved
• a running commit history the student didn't author alone — the reviewer pushed back, the student revised, the pr landed
• an issue trail that shows how the student scoped the work and how scope changed during review
• a verifiable json cert — programmatically signed, fetchable by the hiring manager in a curl call, no email-back needed, no pdf-trust-me
• a public url the student can put in a cold email, on a resume, on linkedin, anywhere

the tpc placement record contains: name, recruiter, package, date. no work sample. no review record. no engineering evidence. the placement record is a claim. the shipped-sprint record is a receipt.

why hiring managers already search for shipped work

product engineering hiring managers at indian product companies — razorpay, zoho, freshworks, postman, meesho, chargebee, browserstack, lenskart, cred — already search for shipped work when filling fresher/junior roles. they search github. they search for active maintainers. they look for recent pr activity that's not a tutorial trace. when they find a candidate with 8 weeks of merged prs, code review history, and a cert they can verify, they route the candidate to a phone screen directly. they don't depend on "did amazon visit your tpc."

this is the heart of the product company vs service company india divergence at hiring time. the witch circuit hires on test scores and academic inputs. the product circuit hires on shipped work. the tpc's nirf-aligned calendar optimizes for the witch circuit's inputs.

a shipped-sprint record is the artifact that lets the same student apply directly through product company tracks without waiting for a tpc slot that may never come.

what you can do this week

if you are a 2026 batch student reading this from a tier-2 or tier-3 college — and if your tpc portal is filling with witch slots while product companies stay absent — here is the operational sequence for the next 7 days. this assumes ~10-15 hours per week outside college hours.

day 1 (saturday). run through the tracks list on dreamclerk — backend, frontend, devops, data, ml — and pick one based on your actual interest, not on which has the most openings. the wrong track produces no shipped prs; the right track produces eight weeks of merged work.

day 2 (sunday). join the workspace, fork the starter repo for your track, run the local build, and read the contributing.md end-to-end. file an introductory issue comment on two existing issues you think you can scope into a 2-3 day pr.

day 3-5 (mon-wed). pick the smaller of the two issues you commented on. open a draft pr with the smallest viable change. respond to whatever feedback the reviewer puts in. this first back-and-forth is the part most students skip; it's also the part the cert records. plan 2-3 hours per day.

day 6 (thursday). merge or close the first pr. open a second pr scoped to a slightly larger issue. the 2-pr-in-7-days pace is what separates sprint record-holders from tutorial-trailers.

day 7 (friday). write a 4-line commit message on pr #2 describing what changed and why. submit it for review. post a 1-line status update in your class group so peer pressure exists.

week 2 through week 8 — same cadence, ramped. by week 4 you should be reviewing other sprint participants' prs (the same way the system reviews yours). by week 8 you ship the capstone and the cert is issued.

when the cert is issued, this is the actionable move: open /#apply, pick the product engineering tracks on /companies corresponding to the actual repo work you shipped, and apply with the cert url in the first line of the message. hiring managers verify the cert directly. they don't wait for the tpc.

do this even if your tpc is "helping" with witch slots. especially do this if your tpc is "helping" with witch slots. the witch drive will run on schedule in october. your shipped-sprint record will still be there in march and in your year-3 job-search.

closing

the tpc cell isn't failing tier-2 and tier-3 students on accident. it's following the kpis it is measured against. nirf's four placement inputs reward volume, not engineering-career outcome. mass recruiters deliver volume. product companies don't. so the campus placement india system is structurally coded to schedule witch visits over product-company outreach, and the tier-2 tier-3 college recruiter funnel narrows accordingly.

a public shipped-sprint record — eight weeks, merged prs, real review, a verifiable cert — is the artifact that steps around the funnel entirely. it lets the student walk up to a product engineering hiring manager with shipping evidence and a fetchable json cert, not a "wait for the tpc to invite amazon" promise. for the 2026 batch inside the active placement window, this is the actionable move: spend eight weeks on a shipped record, and the tpc's incentives stop being your problem.

start a sprint this week on /how — or apply directly with a public shipped-sprint record through /#apply. the runes are moving now.