Download App
I've been in talent acquisition for about six years now, the last three running fresher and early-career hiring for a mid-size product company. This season alone I've screened somewhere north of 1,400 resumes for eleven open seats across engineering and data roles.
Eleven. That math alone should tell you something about how a resume actually gets read, and it's not the way most career advice blogs describe it.
Everyone asks me the same question when they find out what I do: what are recruiters actually looking for. So here it is, from my side of the table, including the parts where I got it wrong.
The ten-second scan is real, and it's not fair
I'm not reading your resume in the first pass. I'm scanning it. Ten seconds, maybe twelve if something catches my eye. That's not a productivity hack — it's just what happens when you have 340 applications for four seats and a hiring manager asking why the req is still open three weeks in.
My eyes go to the projects section before anything else. I'm looking for one sentence that tells me this person built something and can explain a decision they made while building it.
"Built a food delivery app using React and Node.js" tells me nothing. Every third resume says some version of that.
But "switched from REST polling to WebSockets for live order tracking after the polling kept lagging on slow connections" — that's a different resume. That's someone who hit a wall and can describe the wall. I'll read the rest of that resume properly.
I also check the GitHub link, and in a specific way — I'm not cloning the repo, I don't have time. I'm checking whether the last commit is three years old from a college assignment, or whether there's something recent and a little messy that looks like a person who codes for reasons other than a resume line item.
And I'll say the quiet part out loud: a resume that's clearly run through the same generic template as fifty others I've already seen — same "leveraged," same "spearheaded" for a two-person project — gets deprioritized. Not because polishing your resume is wrong. Because when everything reads identically, the only signal left is the specific technical detail, and templates strip that out first.
The instant-reject list, in order of how often I actually see it: factual inconsistencies between the LinkedIn and the resume, contact info my ATS can't parse, and — this one surprises people — a "team lead" claim with zero example attached anywhere on the page.
The call that decides more than the resume did
If a resume clears the scan, next is a fifteen-to-twenty-minute screen. I can tell within ninety seconds whether someone memorized an answer or actually thought about how to talk about their own work.
The memorized version has this cadence — no pauses, perfectly even, like it's being read off a teleprompter. It's not wrong, but it tells me this candidate optimizes for sounding right over being clear. That pattern tends to resurface later, when a panel asks a follow-up that isn't in the script.
What I'm actually listening for is whether someone can explain their own project without hiding behind jargon.
I had a candidate — I'll call her the intern-to-offer story, because it's the one that stuck — who described her project as "an ML-based recommendation system." I asked her to walk me through it like I was a smart friend who didn't know ML.
Her register completely changed. "Imagine you've bought running shoes three times, I built the part that notices that pattern and shows you running socks before you even search. Honestly the hardest part wasn't the model — our dataset had duplicate users under different emails and the recommendations were skewing weird until I caught that."
Thirty seconds told me more than her entire resume. She got the offer. She's one of the stronger engineers on that team now, over a year later.
I also ask, almost every call, some version of "why this role, why us" — not for a polished answer, but for five minutes of homework. Do they know roughly what we build. Have they referenced anything specific from the JD.
There's a doubt I still carry about this stage, though. I know I sometimes read confidence as competence, and those aren't the same thing. I've probably screened out quieter candidates who would've been just as strong once the nerves wore off — I noticed myself doing this enough that I now deliberately give quieter candidates a longer runway on the call.
The technical round, from the note-taker's seat
I usually sit in as note-taker while the engineering panel runs the round, then debrief with them right after. The gap between "technically correct" and "the panel wants to work with this person" is enormous, and candidates rarely realize how much it matters.
A candidate who solves it in silence and says "done" scores fine on the scorecard but rarely gets an enthusiastic hire recommendation. The candidates who get that reaction are the ones who think out loud when they're stuck — especially when they're stuck.
I remember a debrief where the hiring manager said, almost word for word: "she didn't get the optimal answer, but I watched her realize her approach was O(n²), say so out loud, and reason her way to something better instead of freezing — that's literally the job." She got the offer that week, over a candidate who nailed the optimal solution but gave one-word answers to every follow-up.
The behavioral portion is where I see the most avoidable mistakes. Freshers often treat it as filler before the "real" questions. The strongest answers I've heard were always oddly specific — a disagreement over which library to use, a moment where a teammate wasn't contributing and how it actually got handled, not how they wish they'd handled it.
The offer, and the part nobody prepares candidates for
A detail from this season I still think about: we extended an offer, strong technical round, good culture fit, everyone excited — and the candidate simply stopped responding two days before joining. No call, no email.
It happens more than people outside recruiting realize, especially during peak placement season when candidates are juggling offers. I don't hold it against candidates in general — the market asks people to hedge, so people hedge. But I'd be lying if I said it doesn't sting a little, every time.
On the flip side, a candidate this year came back after our offer and asked, clearly and specifically, whether there was flexibility on her joining date because of a family commitment, and whether the CTC breakdown could be explained in more detail since it was her first job offer ever.
She wasn't aggressive about it, wasn't apologetic either. She just asked clearly. That's the kind of negotiation that actually earns respect internally — not squeezing the most money out of us, freshers rarely have leverage for that. Just asking clear questions instead of staying silent and resentful, or going in with a script that doesn't fit the actual conversation.
What I'd tell my younger self as a recruiter
If I'm honest about the biggest thing I've changed in six years, it's this: I used to weight the resume far more heavily than I do now, and I was wrong to.
The resume gets you the call. The call and the round are where I actually learn who you are. I've seen unremarkable-on-paper resumes turn into some of the best hires on the team, because the person could talk clearly about the one project they had. I've seen resumes stacked with certifications belong to candidates who couldn't explain a single one beyond the name.
I don't think there's a clean formula here, and anyone selling you one is probably oversimplifying. But if there's one thing I'd want a fresher to take from this, it's that specific beats impressive, every single time, at every stage I just walked through.
Half the resumes that actually make me pause now are ones where you can tell the person practiced explaining their own work out loud before applying — and a lot of the sharper ones I've seen lately look like they've spent time on something like devsunite.com/resources getting feedback on exactly that.