Our name is a joke. The problem we solve isn’t.

If you have spent any time around online games, you have been told to “git gud.” It is what people type after beating you, usually while you are still staring at the respawn timer. It means: stop complaining, the problem is you.

We borrowed it for our name because it is a little funny, and because it is exactly the message most technical interviews send. Grind more LeetCode. Memorize more patterns. Practice inverting binary trees until you can do it in your sleep. The problem is you.

We don’t think the problem is you. The name is a wink. The work behind it is not: GetGud exists because technical hiring is measuring the wrong things, and that costs candidates their time and companies the people they should have hired.

The interview tests a job nobody has

HackerRank’s 2025 Developer Skills Report surveyed 13,732 developers, engineering managers, recruiters, executives and students across 102 countries.¹ The results read like a list of complaints about an exam that has drifted away from the course:

• 78% of developers say assessments don’t align with real-world tasks.
• 56% find algorithm-based questions irrelevant to their jobs.
• 66% would rather be evaluated on real-world skills.
• 96% believe problem-solving should matter more than memorization.

And candidates respond the way any rational person responds to a test that does not match the job: they study for the test. In HackerRank’s breakdown of the same survey, 71% of developers say they grind LeetCode to prepare, 62% feel they have to overprepare because they don’t know what will be thrown at them, and 42% name assessment prep as their single biggest hiring challenge.²

That is a lot of senior engineering time spent rehearsing for something other than engineering.

Researchers have been saying this for years

In 2019, researchers from NC State and Microsoft studied how developers talk about technical interviews on Hacker News.³ The themes will be familiar to anyone who has sat through a whiteboard round: a lack of real-world relevance, unnecessary anxiety and frustration, a demanding time commitment, a bias towards younger developers, and the need to learn “arbitrary, implicit, and obscure norms” just to pass. Their suggestion was more collaborative problem-solving sessions, closer to how people actually work together.

Industrial psychology has a longer track record on what predicts job performance at all. The U.S. Office of Personnel Management’s assessment guidance, adapted from Schmidt and Hunter’s widely cited 1998 meta-analysis, lists work sample tests at .54, structured interviews at .51 and unstructured interviews at .38.⁴

Those numbers have since been revised. In 2022, Sackett, Zhang, Berry and Lievens showed that earlier statistical corrections had systematically overstated many of these estimates.⁵ Most came down by .10 to .20, and the ranking moved:

These are correlations with later job performance, not percentages. The point is the shape: structured interviews came out as the single best predictor, and unstructured interviews (a friendly chat, a puzzle chosen on the spot, a gut feeling at the end) came out at half the value. The lesson is not “find a cleverer puzzle.” It is “ask everyone comparable, job-relevant questions and judge the answers against the same standard.”

Then AI walked into the interview

All of this was true before every candidate had a coding assistant. Now it is harder to ignore.

97% of developers in HackerRank’s survey use at least one AI assistant, and 76% say AI makes gaming the system easier.¹ HackerRank also reports that 56% of developers admit to using AI on their coding assessments, that its own plagiarism detection flags 6 out of 10 candidates for potential plagiarism, and that 3 out of 4 developers feel at a disadvantage if they don’t use these tools during the interview.⁶

So the classic take-home or timed algorithm test now has two problems. It measured the wrong thing to begin with, and it can no longer reliably tell you who did the measuring. The industry’s first instinct has been to fight harder: more proctoring, more lockdown browsers, more cameras pointed at people’s hands. That treats a test design problem as a policing problem.

Not using AI has a cost too

There is an awkward fact underneath the “no AI allowed” interview: almost nobody is hired to work without it. Banning AI in the interview means testing candidates in an environment they will never work in, for a job where refusing the tools could be the expensive choice.

But the evidence also says AI is not a button that makes everyone faster. In a randomized trial run by METR in early 2025, experienced open-source developers took 19% longer on real issues in their own repositories when allowed to use AI tools, while believing afterwards that AI had sped them up by 20%.⁷ When METR tried to rerun the study in late 2025, it ran into a new problem: 30% to 50% of developers said they had skipped tasks because they did not want to do them without AI. METR now thinks developers are likely more sped up than in early 2025, while calling its own data “only very weak evidence for the size of this increase.”⁸

Put those together and you get the actual skill worth hiring for. It is not “uses AI” or “doesn’t.” It is judgment: knowing when generated code is subtly wrong, noticing the race condition a model wrote with total confidence, reading an unfamiliar codebase well enough to know what a change will break. A team that hires people who cannot work with AI pays for it. A team that hires people who trust it blindly pays more, usually at 3am.

That judgment is exactly what a memorized algorithm hides, and exactly what an interview should make visible.

What we are building instead

GetGud is not a better LeetCode, and it is not a more invasive proctoring tool. It is built on the research above:

• Realistic scenarios instead of trivia. Candidates read unfamiliar code, find the bug, block the PR, or reconstruct how an incident unfolded. The same work they would do in their first month.
• Structure, so answers are comparable. Interviews are built from reusable templates and frozen when sent, so candidates for the same role answer comparable questions. Interviewers get guidance and structured follow-ups to probe how deep each answer goes.
• Objective correctness, kept separate from human judgment. Each question has a defensible answer and a deterministic score. What the interviewer hears while the candidate reasons out loud is recorded as evidence, not blended into the number.
• An explicit AI policy. Every interview says up front whether AI is prohibited, allowed or encouraged, so candidates are not guessing at the rules and interviewers know what they are looking at.
• Signals as context, never a verdict. We count things like focus changes and paste events so an interviewer can ask a better question. We do not record keystrokes, screens, cameras or microphones.

The goal is simple to say and hard to build: interviews that look like the job, so the people who are good at the job can show it.

About the author

Yes, AI helped write this article. Given everything above, it would be strange if it hadn’t.

It was also a useful demonstration. While we checked every number against its source, we found that our first draft quoted a statistic that wasn’t on the page it was attributed to, credited a research paper with recommendations it never made, and attributed a claim to a government page that doesn’t contain it. All of it sounded right. None of it would have survived a careful reviewer.

The tool was fast. The judgment had to come from a person. That is the job now, and it is what we think interviews should measure.

Footnotes

1. HackerRank, 2025 Developer Skills Report. ↩ ↩²

2. Matt McDougall, 5 ways tech hiring frustrates developers, HackerRank, April 23, 2025. ↩

3. Mahnaz Behroozi, Chris Parnin and Titus Barik, Hiring is Broken: What Do Developers Say About Technical Interviews?, IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), 2019. ↩

4. U.S. Office of Personnel Management, Designing an Assessment Strategy, table adapted from Schmidt, F. L. and Hunter, J. E. (1998), “The validity and utility of selection methods in personnel psychology,” Psychological Bulletin, 124, 262-274. ↩

5. Paul R. Sackett, Charlene Zhang, Christopher M. Berry and Filip Lievens, Revisiting Meta-Analytic Estimates of Validity in Personnel Selection: Addressing Systematic Overcorrection for Restriction of Range, Journal of Applied Psychology, 107(11), 2022. Figures from Table 3. ↩

6. HackerRank, The hiring crisis in an AI-driven world. The 56% figure is attributed there to HackerRank’s 2025 Developer Skills Survey; the plagiarism figure comes from HackerRank’s own detection systems. ↩

7. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 10, 2025. 16 developers, 246 real issues. ↩

8. METR, We are Changing our Developer Productivity Experiment Design, February 24, 2026. ↩