Most software internship screens in India test two things: competitive-programming ability and the capacity to sit an aptitude paper. Neither correlates especially well with being useful in an engineering team.
What follows is what the better enterprise screens actually look at, and why.
Live from our candidate database
Counted at render time and refreshed every six hours. This is a supply-side view of one platform, not a national labour-market statistic.
Skills present in this pool
The GitHub read is worth more than the résumé read
Ten minutes in a candidate's repository history tells you more than an hour with their CV. You are looking for commit cadence over months rather than a single dump, for code that responds to a real problem rather than a tutorial, and for any evidence of the candidate having read their own work critically.
The negative signal is equally clear: a repository consisting of forked tutorials with the original commits intact is not a portfolio, and treating it as one is how weak candidates pass strong-looking screens.
Data structures depth still matters — for a specific reason
The case for DSA screening at graduate level is not that engineers spend their days writing balanced trees. It is that the topic is the only body of knowledge every Indian computer-science graduate has been exposed to, which makes it the fairest available comparator across wildly uneven institutions.
That justification also bounds it. Screening for competitive-programming speed rather than reasoning quality selects for a hobby, not for a job, and reliably filters out excellent engineers who never enjoyed contests.
The project defence is the highest-signal twenty minutes
Ask a candidate to walk through one project end to end, then push on the decisions: why this database, what broke, what you would change. Candidates who built the thing answer fluently and volunteer the failures. Candidates who did not, cannot — and the gap opens within three questions.
This exercise also surfaces communication ability, which is the most under-screened attribute in early-career engineering hiring. Code review is a writing job; an engineer who cannot explain a decision in prose will cost their team time every week.
What to stop screening for
CGPA cut-offs above a modest threshold add noise rather than signal, and they disproportionately exclude candidates from institutions with harsher grading. Brand-name institution filters have the same problem in a more expensive form.
Aptitude papers are worth keeping only if you are hiring at a volume where you genuinely cannot interview everyone. They are a throughput tool, not a quality tool, and treating them as the latter is how enterprise funnels end up full of test-takers.
Key takeaways
- Read the repository, not just the résumé — commit history over months is the highest-value ten minutes.
- DSA screening is justified as a fair comparator across uneven institutions, not as job-relevant knowledge.
- A twenty-minute project defence separates builders from résumé-writers within three questions.
- CGPA and institution filters add noise; aptitude papers are throughput tools, not quality tools.
Questions
Should we run a take-home assignment?+
Only if it is short and you commit to reviewing every submission. Long unpaid take-homes select for candidates with free time rather than ability, and unreviewed ones damage your employer brand more than a rejection ever would.
How do we screen candidates with no internship experience?+
That is the normal case at this level, and it is what the project defence is for. Any substantial self-directed build — even an unfinished one — gives you something to interrogate.
Is a CGPA filter ever appropriate?+
A low floor can be a reasonable proxy for consistency. Anything above a modest threshold is filtering on institution grading policy, not on candidate quality.