GitHub Profile Checklist for Software Engineering Internships

Most Indian engineering students treat GitHub as a backup drive: dump coursework, clone a few tutorials, forget it exists. Then they paste the link on a resume and wonder why product-company recruiters never call back. The problem isn't your skill level — it's that your profile gives a stranger no reason to believe you can build software. This checklist fixes the specific things a recruiter or hiring manager actually scans in the first 30 seconds, with a decision framework for what to pin, what to archive, and what to build when you have nothing yet.

What do recruiters actually look at on a GitHub profile in the first 30 seconds?

They look at four things, in this order: your profile README, your pinned repositories, your recent commit activity, and whether the top pinned repo has a working demo link. That's it. Total repo count, follower count, and star count barely register. A recruiter screening 200 resumes for three internship slots is not reading your code — they're looking for a fast yes/no signal that you write software outside of exams.

This is the same scan pattern that governs your resume checklist for engineering students: a human makes a snap judgment, then a technical interviewer verifies it later. Your GitHub has to survive the snap judgment first.

If your top pinned repo has no README and no live link, the scan ends there. Nothing below the fold matters.

The 3-good-repos rule: how to decide what to pin and what to archive

Three well-documented repositories beat thirty tutorial clones every time. A recruiter who opens your profile and sees fifteen repos named todo-app, weather-app, and python-practice reads one message: this person follows tutorials. A profile with three repos — one full-stack project, one algorithmic or systems project, one domain-specific build — reads: this person ships.

Run this decision on every public repo you own:

• Does it have a README with setup steps? If no, it's not pinnable. Either write the README or archive the repo.
• Did you write the core logic, or copy it from a tutorial? If you can't explain a random function in an interview, archive it.
• Does it do something a non-programmer can see? A working URL, a screenshot, or a 15-second GIF. If a recruiter has to run your code locally to understand it, you've lost them.
• Is it older than 18 months with no updates? Archive it. Stale repos drag down the average quality of your profile.

Archive, don't delete. Archived repos stay visible if someone digs, but they drop off your main page and stop competing with your good work. Private is fine too, but archive signals intent — you curated, you didn't hide.

What should a repo README contain to signal real competence?

A competent README answers five questions in under 60 seconds of reading: what problem does this solve, what's the tech stack, how do I run it, what does it look like, and where can I try it live. Most student READMEs answer none of these — they're either empty or a single line copied from the assignment sheet.

Here's a template you can paste into any repo and fill in. It's deliberately short. Long READMEs don't help; structured ones do.

# Project Name

One sentence on what it does and who it's for.

Live demo: [link]  |  Screenshots: [image or GIF]

Tech stack: React, Node.js, PostgreSQL, deployed on Render

Setup:
1. git clone …
2. npm install
3. Add .env with these keys: …
4. npm run dev

What I built vs. what I used: I wrote the auth flow, the booking logic, and the API layer. Used Clerk for auth, Tailwind for styling.

That last section — what you built versus what you used — is the one most students skip and the one interviewers care about most. It tells them where to probe. It also protects you: if you used a library for auth, saying so up front is honest and stops an interviewer from assuming you wrote it and then watching you fumble.

How do you build a GitHub profile when you have no real projects yet?

You convert what you already have. Almost every tier-2 and tier-3 student has three sources of presentable work sitting unused: coursework, hackathon attempts, and self-learning exercises. None of them are portfolio-ready as-is, but all three can be reshaped in a weekend.

Coursework → a real repo

Take your best DBMS, OS, or web-dev assignment. Rewrite the README as if a stranger found the repo. Add a screenshot. If it's a CLI tool, record a 20-second terminal GIF. If it's a web app, deploy it to Vercel or Render's free tier. The code doesn't change — the packaging does. That's the difference between "assignment" and "project."

Hackathon attempts → a scoped-down build

Most hackathon projects die half-finished. Don't pin the half-finished version. Pick the one feature that worked, extract it into a clean repo, and document that. A working single-feature project beats a broken five-feature one. If you can't extract anything working, treat the hackathon as practice and start fresh.

Self-learning → a guided build with your own twist

If you followed a tutorial to learn React or Django, rebuild the same app without the tutorial, then add one feature the tutorial didn't cover. That's the repo you pin. The original tutorial clone stays archived. This is also the fastest way to build the kind of project that survives a technical interview — see our breakdown of projects that actually get you shortlisted for what separates a portfolio piece from a practice exercise.

Commit hygiene that actually matters for students

Consistency over months beats a green streak. Recruiters and interviewers look for evidence that you code regularly — two to three commits a week on real projects over three months reads far better than a 365-day streak built on README edits and empty commits. The streak is a vanity metric; the activity graph is a proxy for whether you actually build things.

Two rules matter more than volume:

• Commit messages should describe the change. "Fix login redirect bug" beats "update" every time. Nobody expects conventional commits from a student, but a commit history that reads like a changelog signals you understand version control as a tool, not a checkbox.
• Don't fake activity. Interviewers who care will open your commit history. A 200-day streak of one-line README edits tells them you optimized for the graph instead of the work. That's a worse signal than a sparse but real history.

If your profile has been dormant for six months, don't panic-commit. Start one real project this week and let the graph rebuild naturally. A recruiter looking at a profile in March doesn't care what you did in August.

What should your GitHub profile README contain as a student?

Keep it to five elements: your name, your target role, four to six technologies you're genuinely comfortable with, links to your resume, LinkedIn, and portfolio, and two to three pinned project names with one-line descriptions. That's a mini-resume. It takes ten minutes to write and it's the first thing a recruiter reads.

What to leave out: motivational quotes, badge walls, "currently learning DSA" banners, GitHub stats cards, and streak counters. These add visual noise and zero hiring signal. A recruiter scanning your profile wants to know what you build and what you're targeting — not that you're "passionate about coding."

One more thing: put your target role in the README. "Final-year CSE student targeting backend SDE internships" tells a recruiter exactly where to slot you. Generic READMEs get generic treatment.

How is GitHub evaluated differently across service companies, product companies, and GCCs?

The evaluation bar changes completely depending on who's hiring. Applying the same profile to all three is a mistake.

For service companies, your GitHub link is mostly a formality — but a broken or empty profile is still a negative. For product companies and startups, the pinned repos are the first technical signal a recruiter sees, often before any coding round. For GCCs, an interviewer may open a specific repo during the technical round and ask you to walk through a function.

If you're targeting product companies or GCCs from a tier-2 or tier-3 college, your GitHub does more work than your college name. That's the leverage. Read our placement strategy for tier-3 college students and off-campus placement guide for how this fits into the broader application sequence.

Red flags that get GitHub profiles rejected

Four patterns kill an otherwise decent profile. Check yours against this list before you send another application.

• Forked-only repos. If your pinned repos are all forks of other people's projects, you've signaled you don't build. Fork to contribute, not to fill space.
• No README. A repo with code and no explanation is a dead end for anyone reviewing it. Write the README or archive the repo.
• Copied tutorial code with the original author's name in commits. This is the worst one. If your commit history shows someone else's name, or the code is a line-by-line match of a popular tutorial, an interviewer who recognizes it will end the conversation.
• No commits in 12+ months. A stale profile suggests you stopped building. Either update your top repo or pin something recent.

None of these are fatal on their own if you fix them before applying. The fix for all four is the same: spend two weekends on one real project, write a proper README, and pin it.

If you want a structured read on where your profile currently stands against what product companies and GCCs look for, you can assess your GitHub profile against benchmarked hiring data and get a report on the specific gaps to close.