Garden City University Students: A Code Review Checklist for Your Internship Pull Requests

Before a mentor reviews your pull request, you should review it yourself using a fixed checklist covering naming, tests, secrets, commit size and the PR description. Done properly, this takes about 15 minutes and removes most of the comments a mentor would otherwise leave. This guide gives you the full checklist, a PR description template with before and after versions, and a 14-day plan for building the habit.

Why self-review matters in a 14-day full stack internship

A short internship gives you very few review cycles. If your mentor spends the first round pointing out a vague variable name, a committed .env file and a 900-line diff, you may have only one or two rounds left to discuss the real design. Self-review moves those trivial fixes to your side so that the mentor’s time goes to logic, structure and learning.

The free two-week online internship from CareerSwami includes a free offer letter and a free completion certificate after successful completion, and it spans 26 tracks, including full stack web development. Whatever track and project you work on, the habit below transfers to any team that uses pull requests.

The pull request self-review checklist: naming, tests, secrets and commit size

Work through this table top to bottom on your own diff, ideally in the pull request view on your Git host rather than in your editor, because the diff view shows what the reviewer will see.

Naming: what to look for in practice

• Rename anything you had to explain to yourself while writing it.
• Prefer fetchUserOrders over getData; the first tells the reader what comes back.
• Keep API route names as nouns for resources (/orders) and let the HTTP method carry the verb.
• Avoid one-letter names outside tiny loops or callbacks.

Tests: a minimum that is realistic in two weeks

You are not expected to reach full coverage. Aim for tests on the logic that could break silently: validation functions, calculations, and API handlers that return different responses for different inputs. If your project has no test setup at all, say so in the PR description and list the manual steps you used instead. Do not leave the mentor guessing.

Secrets: the one mistake that cannot be undone by a new commit

If a key is committed, deleting it in the next commit does not remove it from history. Treat any exposed key as compromised: revoke or regenerate it at the provider, then ask your mentor how the team wants history cleaned. Prevent this by checking the changed-files list for configuration files before every push.

Commit size: how big is too big

There is no universal number, but a useful test is whether a reviewer can hold the whole change in their head. If your diff touches the database schema, the API, the UI and the styling all at once, split it. A sensible order is schema or model first, then API, then UI, each as its own PR or at least its own commit.

PR description template with before and after examples

Copy this template into your repository’s pull request description box, or save it as .github/pull_request_template.md if your mentor agrees.

## What this PR does
(One or two sentences.)

## Why
(Link to the task or describe the problem.)

## How I tested it
- [ ] Automated tests added or updated: (names)
- [ ] Manual steps: (numbered list)

## What to look at closely
(Parts you are unsure about.)

## Not included
(Anything deliberately left for a later PR.)

## Self-review checklist
- [ ] Names are clear and consistent
- [ ] No secrets or .env files in the diff
- [ ] No debug logs or dead code
- [ ] Change is small enough to review in one sitting

Before and after: a weak and a strong PR description (illustrative)

The following example is invented for teaching. It does not come from a real project and no code was run.

Before:

Title: updates
Description: Added login stuff and fixed some bugs. Also changed styling.

Problems: the title says nothing, three separate jobs are mixed together, there is no testing information, and the reviewer cannot tell where to start.

After:

Title: Add email format validation to login form

## What this PR does
Rejects malformed email addresses on the login form and shows an inline error message.

## Why
Task 4: users currently see a generic server error when they mistype their email.

## How I tested it
- [x] Added 3 unit tests for validateEmail (valid, missing @, empty string)
- [x] Manual: submitted empty, "abc", and a valid address; error shows only for the first two

## What to look at closely
Regex in validateEmail.js: is it too strict for addresses with a plus sign?

## Not included
Password rules and the styling changes; these will be separate PRs.

The reviewer now knows the scope, the evidence, and exactly where you want a second opinion.

A worked self-review on a messy diff (illustrative)

Imagine you built a product listing page and your diff shows 14 changed files and about 700 added lines. Walking through the checklist:

1. Commit size: the diff includes a new Product model, a /products endpoint, a React list component, and a CSS reset you changed along the way. You move the CSS reset to its own branch and split the model plus endpoint from the UI. The first PR is now about 200 lines.
2. Secrets: searching for mongodb:// finds a connection string in db.js. You move it to an environment variable, add a placeholder to .env.example, and regenerate the database password because the string was already committed locally.
3. Naming: a function called getData becomes fetchProductList; the state variable flag becomes isLoading.
4. Tests: you add a test that the endpoint returns an empty array when no products exist, and another for an invalid category filter.
5. Cleanup: you remove four console.log lines and an unused import flagged by the linter.
6. Description: you fill in the template, noting that pagination is intentionally not included.

The mentor now receives a focused, safe, testable PR instead of a dump of work in progress.

Garden City University students: fitting PR review habits around your internship requirements

Garden City University describes itself as established under Karnataka State Act no. 47 of 2013 and approved by UGC. Its admissions FAQ, last modified on 30 September 2026, says compulsory internships are built into the curriculum across all programmes. The Rules and Regulations page states mandatory six-month internships for B.Com and M.Sc. Data Science and Analytics students, and mentions assessment through viva sessions and case studies among other methods.

What this means for you: a university internship may be assessed by someone who was not there while you worked. A clean pull request history, with clear descriptions, small commits and documented tests, is evidence you can show in a viva or report. Programmes such as the BCA, which lists C programming and data structures early on, give you the fundamentals; PR discipline is the layer that turns those fundamentals into reviewable team work.

The published pages do not make clear how a short online internship, such as a 14-day one, would count toward any university requirement. The FAQ’s internship share figure also appears incomplete in the excerpt. Do not assume the CareerSwami internship satisfies any university requirement or earns credit; check first.

Verification steps:

1. Email your department coordinator asking in writing whether a 14-day online internship can count toward your programme’s internship requirement, and keep the reply.
2. Ask for the current internship guidelines or regulation document for your programme and batch, including required documents and evaluation format.
3. Ask whether the assessment expects a report, viva or portfolio, and whether links to pull requests can be included as evidence.
4. Open the FAQ page and confirm what the internship share figure means and which unit it uses.
5. Contact the Career Guidance and Placement Office (named on the 2025 Internship Drive page) to ask about the process for externally arranged internships.
6. Check with your mentor and coordinator whether sharing repository links publicly is allowed for your project.

A 14-day plan to build the self-review habit

Warning signs that a pull request is not ready for a mentor

• You cannot explain the change in one sentence.
• The changed-files list includes lock files, build folders or node_modules that you did not intend to change.
• You have not run the app since your last edit.
• The description says “see code”.
• You are hoping the reviewer will find the bug for you.

Receiving review comments without losing momentum

• Reply to every comment, even if just “Done” with a commit reference.
• If you disagree, explain your reasoning with evidence and ask a question rather than defending.
• Push fixes as new commits during review so the mentor can see what changed; ask whether to squash at the end.
• Keep a personal list of recurring comments and add them to your checklist.

Frequently Asked Questions

How long should a self-review take?

Around 10 to 15 minutes for a small PR. If it takes much longer, the PR is probably too large and should be split.

How many lines should a pull request have?

No fixed rule exists, but a few hundred lines is usually easier to review than a thousand. Ask your mentor what the team prefers and follow that.

What should I do if I accidentally commit an API key?

Revoke or regenerate the key immediately at the provider, then tell your mentor. Removing the file in a later commit does not erase it from history.

Do I need tests for a two-week internship project?

Add tests for logic that could break silently. If time or setup prevents it, say so in the PR description and document your manual testing steps.

Should I squash my commits before review?

Ask your mentor. Some teams squash on merge, others want a clean commit history. Either way, write meaningful messages as you go.

Can PR links be used as proof of my internship work?

They can show what you built, but whether they count for any university assessment is for your department to decide. Ask in writing, and check that the repository can be shared.

What if my mentor does not use pull requests?

Still work on a separate branch and write the same description in a document or message. The review habits apply to any way of sharing code.

Does the CareerSwami internship count as academic credit?

CareerSwami offers a free offer letter and a completion certificate after successful completion. It does not state academic credit, so confirm with your university before relying on it.

Related Full Stack Web Development guides

• Pacific University Students: Writing a README That Explains Your Full Stack Internship Project
• HNB Garhwal University Students: Remote Internship Habits for Hill-Region Connectivity
• Chettinad Academy Students: Adding a Simple Login System Safely in an Internship Project
• All Full Stack Web Development internship guides