Side Projects vs GPA: What Actually Gets You a Tech Job

A recruiter at a mid-size SaaS company told me something blunt during a panel in early 2025: “We stopped filtering by GPA two years ago. I can’t remember the last time I even looked at it.” She wasn’t the only one. According to NACE’s Job Outlook survey, only 38.3% of employers now use GPA as a screening criterion for college hires, down roughly 35% from five years earlier. That’s not a fringe trend. That’s most hiring managers already ignoring the number you spent four years optimizing.

This doesn’t mean GPA is worthless everywhere. But for most software engineering roles, the calculus has shifted. The question is what actually fills the gap.

What hiring managers actually look at instead

The short answer, frustratingly, is “proof that you can build things.” That sounds vague until you understand what it means in practice.

When a resume lands on a hiring manager’s desk with no real-world experience, they’re trying to answer one question fast: can this person ship working software? A GPA doesn’t answer that. A transcript doesn’t answer that. A GitHub repo with a project that has real users, tests, and readable commit history starts to answer it.

The NACE data backs this up. Nearly 90% of employers in that same survey said they’re looking for evidence of problem-solving ability, and internship experience ranked as the top deciding factor for new grads. Side projects fill the same signal function as internships when internships aren’t on the resume. They’re artifacts. They’re things you made that exist independently of a grade.

The 2024 Stack Overflow Developer Survey found something in the same vein: 66% of professional developers hold a formal degree, but only 49% learned to code in school. More than half learned elsewhere. Hiring pipelines, at least at companies that know what they’re doing, have adapted to that reality. You can read the full breakdown at survey.stackoverflow.co/2024/developer-profile.

What makes a side project actually count

Here’s where a lot of advice goes wrong. “Build side projects” is common wisdom. What’s less discussed is which side projects don’t move the needle at all.

A to-do app tutorial you followed on YouTube doesn’t count. A clone of a tutorial project with your name in the README doesn’t count. Neither does a project you started in January 2023 and haven’t touched since, with zero commits, zero users, and no clear problem it was solving.

Projects that actually help you tend to share a few qualities. They solve a real problem, even a small one. There are real users, even if that’s just 12 people from a Reddit thread. The README explains what problem you were solving and why you made certain technical decisions. And critically: the code is readable and the project has some documentation. Not perfect documentation. Just enough that someone landing on it isn’t immediately lost.

I’d add one more thing that’s underrated: having an opinion about what you built. “I chose Postgres over SQLite here because I expected concurrent writes” is a better interview moment than a perfect codebase with no reasoning behind any decision.

Project ideas worth building (and ones not worth your time)

Some project categories show up constantly and have stopped signaling much. Another weather app. Another bookmarking tool. Another basic blog engine. Interviewers have seen hundreds of these, and while a well-built version can still be decent portfolio evidence, it’s harder to be memorable with them.

What tends to stand out more:

• A tool that automates something tedious in a workflow you actually use, with at least a few real users (even if just teammates or people from a Discord server)
• An open-source contribution to an active project, especially if your contribution got merged and had a real effect on behavior
• A data project that answers a specific question with real data you collected or cleaned yourself, not a Kaggle tutorial dataset everyone has used
• A browser extension or CLI tool that solves something specific, published somewhere people can actually find it

I’m genuinely uncertain whether the specific category matters as much as the narrative. A weather app with 400 active users and a clear explanation of how you handled API rate limits and caching is more interesting than a clever idea with a half-finished codebase. The project has to work well enough that you can talk about it without hedging.

When GPA still matters

It would be dishonest to say GPA never matters. It does, in specific contexts.

Quantitative finance roles, government clearance positions, and some defense contracting roles still filter by GPA, often with a hard 3.5 cutoff applied before any human looks at the resume. Graduate school applications weight it heavily. Some large financial institutions and certain legacy enterprise companies still have ATS filters set to screen for GPA, particularly for campus recruiting pipelines set up years ago by people who aren’t thinking about this the same way startups are.

If you’re targeting any of those paths specifically, GPA does matter, and this post isn’t for you. But most software engineering roles at product companies, startups, and mid-size tech firms have largely moved away from it as a primary filter. The shift isn’t complete and it isn’t uniform, but the NACE numbers show a clear directional trend.

How to actually talk about your projects in interviews

Building something is step one. Being able to discuss it well is step two, and plenty of people skip step two.

The questions you should be able to answer about any project you put on your resume: What problem does this solve and for whom? What was the hardest technical decision? What would you do differently if you rebuilt it today? What broke in production (or in testing) and how did you fix it?

If you can’t answer those four questions fluently, the project isn’t interview-ready yet. Practicing answers to these with a mock interview tool before you sit down with an actual hiring manager is worth doing. The mock interview product at LastRoundAI is built for exactly this kind of prep, and running through a few behavioral rounds with your project as the anchor gives you a clearer sense of where the gaps in your explanation are before they surface in a real conversation.

For a broader picture of how technical rounds work, the guide on passing coding interviews covers the mechanics that sit alongside your portfolio work when you get to the actual interview loop. And if you’re still building your resume around these projects, the ATS resume tips post is worth reading for how to present project work so it doesn’t get filtered before a human reads it.

One thing I’ll say directly: GPA isn’t going to zero. Some roles will always care. But for the majority of candidates applying to engineering roles at product companies right now, a well-built project with real users and a clear explanation of your technical choices will do more work for your application than half a GPA point will. That feels like the right bet to make with limited time.