Keeping One College From Dominating a Multi-College Drive

Five colleges, one open role, one Monday morning deadline. That’s the shape of a fairly ordinary multi-college campus drive for a mid-size Indian employer running a hiring season, and it creates a problem nobody designs for on purpose: a combined shortlist where one college’s cohort can crowd out the other four before a recruiter even opens the dashboard.

We watched this happen on a pilot campaign in early 2026. A TA lead had connected five college placement sheets to one job description through HireQwik’s trigger flow, expecting five roughly comparable streams of candidates. Instead, one engineering college’s resumes matched the JD’s required skills so consistently that its cohort filled most of the top score band on day one, while three equally real candidates from a smaller college sat lower simply because fewer of their peers cleared the bar. Nothing was broken. The rubric was doing exactly what it was built to do. The problem was that nobody had a way to look at each college’s slice separately before deciding who to call first.

One rubric, several sheets, one shortlist

HireQwik’s per-JD scoring rubric is built once, from the job description, and applied identically to every resume that lands against that JD, no matter which sheet it arrived through. In a multi-college drive, a recruiter typically sets up one trigger sheet per college, each pointed at the same JD. Candidates from Delhi, Pune, and Coimbatore all get scored by the same criteria: same skill weighting, same relevance checks, same knockout questions once they reach the voice screen. That consistency is the entire point of a per-JD rubric instead of a generic one. It also means the combined shortlist a recruiter opens is genuinely one ranked list, not five lists stapled together, which is exactly what creates the crowding problem when one college’s applicant pool happens to fit the role better on paper.

Why one college can dominate, and why that isn’t a bug

A tier-1 engineering college sending 400 resumes against a backend-heavy JD will often produce a higher average resume-match score than a smaller college sending 150 resumes for the same role, because more of those 400 have the specific stack experience the JD asks for, a gap that industry hiring commentary increasingly frames as a skills-fit question rather than a college-prestige one. That’s a real relevance signal, the same one behind relevance-aware resume scoring: a resume with the right skills and directly applicable coursework scores higher than one without them, regardless of which sheet it came from. Read the combined shortlist without separating by source, and it looks like the system is choosing one college over the others. Separate it by source, and what you’re actually looking at is four cohorts, each ranked internally on its own merits, that happen to sit at different average heights on the same scale.

The distinction matters because the fix isn’t to change the rubric per college. Doing that would defeat the purpose of a JD-aware scoring model and reintroduce the exact inconsistency it was built to remove. The fix is giving HR a way to look at each cohort on its own terms without losing the combined ranking underneath it.

Reading one college’s cohort without losing the others

This is where the Needs Review tab’s Role and Source filters do the actual work. A recruiter running a five-college drive can select one college as the source, layer the Score/Decision filter on top, and see exactly that cohort’s candidates inside a chosen score band, from Strong Go down to Reject. Clear the source filter and the same candidates reappear inside the full combined list, at whatever rank their score actually earns them. Nothing about the underlying data changes between those two views. What changes is which slice a recruiter is looking at, which turns “why does college C look empty at the top” into an answerable question instead of a nagging suspicion that something is unfair.

In practice, a TA lead running this kind of drive checks each source filter once a day during the review window, specifically to confirm every college has at least a few candidates moving, rather than only ever looking at the unfiltered combined list. It’s a five-minute habit, not a new workflow, and it catches the case where a smaller college’s best candidates are technically qualified and simply sitting lower on a combined scale that a recruiter working from the top down would never scroll far enough to reach.

A worked scenario

Say a drive spans four colleges against one JD for an associate engineer role, 150 to 300 resumes per college, 900 total. After resume matching, the combined Needs Review queue shows 60 candidates in the Strong Go band. Skim it top to bottom and 40 of those 60 trace back to one college, 12 to a second, and the remaining two colleges show 5 and 3 respectively. A recruiter working from the top of the list alone would likely fill most interview slots from the first two colleges before ever reaching the third and fourth.

Switch the Source filter to the third college alone, and its actual Strong Go count of 5 is unchanged, it was simply buried under 52 other rows above it in the combined view. Nothing about those 5 candidates got worse by being harder to find. What the filter fixes is visibility, not the underlying score, and that distinction is exactly why the fix belongs in the review workflow rather than in the rubric.

When a college genuinely has too few strong candidates

Sometimes the filter reveals a real gap, not a visibility problem. A college sends 40 resumes against a JD and only 1 clears Go. That’s not the filter failing, it’s the relevance-aware scorer correctly reporting that most of that cohort’s skills and coursework don’t match this specific role. Forcing a quota of interview slots for that college in that case does the candidates no favors: HireQwik’s two-evaluator layer still scores whoever gets invited on the actual call, so a candidate promoted past the resume stage on a quota rather than on fit still has to clear the same interview bar as everyone else.

The honest move in this situation is to tell that college’s placement cell the real reason early, rather than let a quiet shortlist speak for itself: this JD’s skill requirements didn’t match this cohort well this cycle, which is a curriculum-and-role mismatch, not a judgment on any individual student. That conversation is easier to have before a drive closes than after, which is one more reason to check the Source filter daily rather than only on the last day.

What this changes about how you set up the drive

Two setup choices make the source filter actually useful instead of cosmetic. First, name each trigger sheet by college, not by a generic “batch 1, batch 2” label, so the Source filter shows something a recruiter can act on at a glance. Second, decide before the drive starts whether you’re guaranteeing each college a minimum number of interview slots regardless of relative score, or genuinely letting one combined rubric decide the whole list. Both are legitimate choices. What’s not legitimate is deciding it informally, mid-drive, after someone notices college C looks thin at the top, because by then the drive is already partway run and changing the rule retroactively looks like moving the goalposts to everyone watching.

Most teams we’ve talked to during pilot campaigns land on a hybrid: run the full combined rubric for the bulk of the role, but set a floor of a handful of interview slots per college so no cohort is shut out entirely by an average-score gap that has more to do with which skills a college’s curriculum leans toward than with any individual candidate’s ability to do the job. That floor is a policy decision your team makes, not something the scoring system enforces on its own, and it’s worth writing down before the sheets start filling.

Interview capacity is the other constraint nobody schedules for

Even after the Source filter tells you a smaller college has five genuinely strong candidates, those five still need interview slots on the same evening as everyone else’s. HireQwik runs interviews in 15-minute slots at a default concurrency ceiling of 20 candidates per slot, which is plenty for a single-college drive but becomes a real scheduling constraint once four colleges are all trying to fill the same evening’s slot inventory. If a recruiter only ever books from the top of the combined list, the smaller college’s five strong candidates can lose out on slots not because they scored lower, but because the slot pool filled up before anyone checked their filtered view.

The fix is procedural, not technical: decide interview-slot allocation per college before opening the booking window, the same way you decide shortlist floors before the drive starts. A common pattern is reserving a fixed block of slots per college proportional to how many Strong Go and Go candidates that college’s Source-filtered view actually shows, rather than proportional to how many resumes it originally sent in. That keeps the slot math tied to who actually qualified, not to raw application volume, which is the same principle behind scoring candidates on relevance in the first place.

What the score bands actually look like across colleges

The Source filter’s real value shows up once you pair it with HireQwik’s resume-match bands: Strong Go sits at 90 to 100 percent, Go at 75 to 89, Maybe at 60 to 74, and anything at 59 or below lands in Reject. A recruiter checking one college’s Source-filtered view isn’t just seeing a raw candidate count, they’re seeing exactly how that cohort distributes across those four bands, which is a more honest read than “college C only has 8 candidates” on its own. Eight candidates concentrated in Strong Go is a very different signal than eight candidates spread thin across Maybe and Reject with nothing in the top two bands, and only the banded view surfaces that difference.

This also gives HR a cleaner way to explain a thin-looking college to its own placement cell later. “Your cohort had 8 candidates in Strong Go and Go combined, out of 40 submitted” is a specific, checkable number a TPO can sit with. “You only had a few make it through” invites exactly the kind of vague pushback described earlier, because it gives the placement cell nothing to verify against.

Booking works the same way regardless of which college a candidate came from, too. Every candidate who clears the resume stage gets the same self-schedule link and the same RFC 5545 calendar invite for their interview slot, readable in Outlook or Gmail with a 15-minute reminder attached, and the same reschedule allowance: up to three reschedule attempts within 72 hours of the first booking before the slot picker locks and HR has to reset it manually. None of that changes by source sheet, which matters in a multi-college drive specifically because it means a candidate from the smallest college isn’t getting a worse or slower booking experience than one from the largest college, only a different starting position on the combined shortlist.

The take

A combined shortlist across several colleges isn’t unfair because one college’s candidates score higher on average. It’s unusable if a recruiter has no way to check that each cohort is actually represented before the top of the ranked list runs out. The rubric doesn’t need to change per college. The review workflow does, and the Source filter is what makes that possible without asking anyone to run five separate spreadsheets by hand.

If your next drive spans more than one campus, set up the trigger sheets with clear source names from day one, agree on whether you’re guaranteeing per-college slots before candidates start arriving, and check the Source filter daily rather than only skimming the combined list from the top. For the setup steps themselves, the campaign setup guide and the campus-versus-lateral configuration walkthrough cover the sheet-connection mechanics this piece assumes. And once a drive closes, what you actually send each college back is its own question, covered in what to send the placement cell after a drive closes.

To see how the combined shortlist and the Source filter actually look on a live campaign, the HR dashboard is the place to check it firsthand.