Code quality checklist for students

← Back to Learn

A class project graded on whether it runs is a different bar than a GitHub repo you're linking from your resume. Here's a practical checklist for the second case — the one a recruiter or a hiring manager might actually open.

Before you link a repo on your resume

• Does it have a README? One paragraph on what the project does and how to run it. An empty or default README is one of the fastest ways to look unfinished.
• Is there a LICENSE file? Doesn't need to be complicated — MIT or Apache 2.0 is fine — but an unlicensed public repo technically has no clear terms for anyone to reuse it.
• Are commit messages readable? A history of "fix", "fix2", "asdf" is a minor thing individually and a pattern reviewers notice collectively.
• Does the longest function fit on one screen? A 300-line function is a specific, checkable red flag — not a vague impression, an actual number you can look up.
• Are there any bare except: blocks or empty catch blocks? These are exactly the kind of thing an interviewer skimming your code will notice, because they're a known anti-pattern taught in most CS courses.
• Is there at least one test? Doesn't need full coverage — one test file signals you know testing exists as a practice.

Common mistakes that stand out for the wrong reasons

• Hardcoded credentials or API keys committed to the repo — an instant red flag for any technical reviewer, independent of code quality.
• A single 1000-line file holding the entire project, with no separation between logic, I/O, and configuration.
• Copy-pasted boilerplate left in from a tutorial, including the tutorial's own comments and variable names.
• No .gitignore — a repo with node_modules/ or a virtual environment committed directly signals unfamiliarity with basic tooling.

A five-minute pre-submission routine

1. Read the README as if you'd never seen the project before. Does it actually explain what to do?
2. Run the repo through REPO-SIGHT — no signup, no install. Look at the grade and the single longest function it finds.
3. Fix the worst one or two things it flags. You don't need a perfect score — you need to not have an obvious, fixable outlier sitting in a repo someone's about to open.
4. Re-run it once, confirm the grade moved, and move on. Don't chase a perfect score on a student project — a clean, honest B is more convincing than a suspiciously perfect A on something that was clearly never really tested.

Why this matters more than it seems

A recruiter or interviewer who opens your linked repo is spending maybe two or three minutes there. They're not going to read every file — they're forming an impression from the README, the file structure, and whichever function they happen to click into first. A five-minute pass before you submit is genuinely cheap insurance against that impression being the wrong one.