HackerRank open-sourced its resume screener. The same resume scored 66 to 99.

HackerRank put the code that grades your resume on GitHub. The repo, interviewstreet/hiring-agent, is MIT-licensed and sits at 3.3k stars. For once you can read the exact pipeline that decides whether a human ever sees your application. What people found inside is not reassuring.

The headline problem is consistency. A developer who writes as Dan Kinsky ran one unchanged resume through the tool 100 times and logged the spread: scores landed anywhere from 66 to 99 out of 100. His first four manual runs alone returned 90, then 74, then 88, then 83. Same PDF. Same prompts. Different luck. That matters to every engineer whose first-round screening is now a model call instead of a recruiter, because the number it spits out is closer to a dice roll than a grade.

What HackerRank actually shipped

The project is a resume-to-score pipeline, not the full HackerRank product. Per the README, it parses a PDF, runs six separate large-language-model calls to extract structured fields (basics, work history, education, skills, projects, awards), scrapes the candidate’s GitHub profile for signal, then combines everything into a scored, “explainable” evaluation. HackerRank ships it under MIT with two model backends: local Ollama models like gemma3:4b, or Google’s hosted Gemini. There’s no Claude or OpenAI wiring in the box; you bring your own model.

The scoring rubric is the part worth reading carefully. Open-source contributions are worth 35 points, personal projects 30, work experience 25, and technical skills 10, with up to 20 bonus points for things like startup time or a technical blog. Add the first two and you get the line that lit up Hacker News: open-source plus side projects account for 65% of the score, while actual paid engineering work caps out at a quarter.

Why the score keeps moving

Kinsky’s sharper claim is that the randomness isn’t a tuning bug you can dial out. He points to a GitHub issue from October 2025 showing six consecutive runs at temperature 0 returning 27, 34, 32, 34, 34, and 30. Temperature 0 is supposed to be the deterministic setting. It wasn’t.

Some commenters pushed back on the framing. As one noted on Hacker News, “temperature is not some kind of ‘deterministic’ switch, but rather it affects the sampling distribution.” Fair. Floating-point non-determinism on GPUs, batching, and model-server quirks all leak variance even at temperature 0. But that nuance cuts the wrong way for job seekers: if the people who build these tools can’t get a stable number out of one resume, the score on the other side of an application portal is noise dressed up as a measurement. Kinsky’s own summary: “If your cutoff sits at 85, I fail 65% of the time. Same exact resume, different luck.”

The rubric weighting drew its own fire. “Open source and personal projects are fine, but in no sane world are they worth 65% of a resume’s score,” wrote one commenter, when work experience sits at 25%. Another compared the whole setup to an old recruiting habit: “The AI learned the old HR trick: take 50% of resumes and throw them out without looking.”

What this means for you

If you’re job hunting in engineering, treat automated screening as the lossy filter it is, not a verdict on your work. Two concrete moves. First, feed an ATS the signals it over-weights: a GitHub profile with real, readable repos and a couple of finished side projects move this particular rubric far more than another line of job history. Second, when a company offers any human channel, a referral, a hiring manager’s inbox, a careers email, use it, because a referral skips the dice roll entirely. The flip side is the uncomfortable one for employers: if your screening cutoff sits at a hard number and your scorer swings 30-plus points on an identical input, you are rejecting qualified people at random and calling it a process. The fix isn’t a better prompt. It’s not pretending a stochastic model output is a stable score in the first place.