Internship Code Review Checklist: 5 Red Flags We Reject in First PR

Introduction: Why First PR Reviews Matter More Than Code Quality

At Agentic Academy Labs in Sikar, we run a hands-on developer internship that pairs every intern with a senior engineer for a full code review cycle. The first pull request an intern opens is not really about whether the code compiles. It is about whether the intern can communicate like an engineer, think like a teammate, and ship something a stranger can trust.

Code reviews are mandatory for shipping code and are a key mechanism for maintaining quality, sharing knowledge, and passing on team culture Code Review - The Software Engineer Internship Survival Guide. That is true at every company, but it hits interns harder. Interns often struggle with code review because it is rarely taught, so they expect lots of feedback early on and aim to show progress by reducing repeated comments over time Code Review - The Software Engineer Internship Survival Guide.

We learned this the hard way. Our first internship batch in early 2026 had a 40 percent return-offer rate. The second batch, after we published a written code review guide, hit 85 percent. The difference was not talent. It was a checklist.

The Incident: My First PR Got Rejected on a Friday Afternoon

I am Rajat, a senior engineer at the lab. In February 2026, I reviewed a first PR from an intern named Aaroh. The PR added a student enrollment endpoint to our learning portal. The code worked. The tests passed. But the PR description was two lines: "Added enrollment API. Fixes #42."

I left five comments. Three were blockers. Aaroh pushed fixes within 40 minutes, which was great. But the damage was done. The PR sat in draft for a week while Aaroh refactored the error handling and added unhappy-path tests. By the time it merged, the sprint had shifted and the feature was deprioritized.

That Friday afternoon taught me that a first PR is a signal, not a task. It tells the team whether the intern can ship independently or needs hand-holding. Here are the five red flags we now reject in every first PR.

Red Flag #1: No Business Context in the PR Description

A PR description that only says what changed, not why it changed, is the fastest way to earn a request for more context. Before reviewing any pull request, make sure you understand the business context first The Perfect PR Review Checklist No One is Talking About.

We ask every intern to fill out a template before opening a PR:

## What does this PR do?
Adds POST /api/v1/enrollments to let a student join a course.

## Why is this needed?
Students currently email support to enroll. This automates the flow and reduces support tickets by an estimated 30 percent.

## How was it tested?
- Unit tests for success and failure cases
- Manual test with curl against staging
- Verified IDOR protection with a second student account

If the business context is not clear from the PR itself, that is the first red flag The Perfect PR Review Checklist No One is Talking About. We tell interns to reach out to the developer and get context before proceeding with the review.

Red Flag #2: Silent Exception Swallowing in Error Handling

Error handling that catches an exception and does nothing is worse than no error handling at all. It hides bugs and makes debugging impossible.

In Aaroh's PR, the enrollment service caught a database error and returned a generic 500 response without logging anything. The fix was to log the error with context and return a safe message:

try:
    enrollment = db.save(new_enrollment)
except IntegrityError as e:
    logger.error("Enrollment failed for student %s in course %s: %s", student_id, course_id, e)
    return jsonify({"error": "Unable to enroll at this time"}), 500

A useful review covers five categories of substance. Logic correctness, security, performance, error handling, and test coverage. Formatting and variable naming do not belong here Code Review Best Practices for India Dev Teams 2026.

Red Flag #3: N+1 Query Pattern in Database Access

N+1 queries are the silent killers of production databases. They pass unit tests with a handful of records and explode under real traffic.

Aaroh's PR loaded each student's courses in a loop:

for student in students:
    courses = db.query(Course).filter(Course.student_id == student.id).all()

The fix was a single join query:

courses = db.query(Course).join(Enrollment).filter(Enrollment.student_id.in_([s.id for s in students])).all()

Performance implications like N+1 patterns often do not appear in unit tests or low-traffic staging environments, but they are consistently the source of production incidents when traffic scales Code Review Best Practices for India Dev Teams 2026.

Red Flag #4: Missing Unhappy Path Tests

A PR that ships a feature with tests only for the success case is incomplete. Test the case where the payment gateway returns an error Code Review Best Practices for India Dev Teams 2026.

Aaroh wrote tests for successful enrollment but not for duplicate enrollment, invalid course ID, or database failure. We asked for three more tests before approving:

def test_enroll_duplicate_student(self):
    response = self.client.post("/api/v1/enrollments", json={"student_id": 1, "course_id": 1})
    self.assertEqual(response.status_code, 409)

def test_enroll_invalid_course(self):
    response = self.client.post("/api/v1/enrollments", json={"student_id": 1, "course_id": 999})
    self.assertEqual(response.status_code, 404)

Red Flag #5: Security Blind Spot - IDOR Vulnerability

IDOR, where a user can access another user's data by changing an ID in a URL parameter, is frequently missed because it requires thinking about authorization at the object level, not just at the route level Code Review Best Practices for India Dev Teams 2026.

Aaroh's endpoint accepted a student ID from the request body without checking if the authenticated user was allowed to enroll that student. The fix was to derive the student ID from the session token instead:

student_id = get_current_user_id()
course_id = request.json.get("course_id")

For any code that touches user input, check for SQL injection, XSS, and IDOR vulnerabilities Enhance your code quality with our guide to code review.

What We Tried First (And Why It Failed)

Our first attempt at internship code review was informal. We told interns to "just write good code" and reviewed whatever they submitted. That failed because it assumed interns already knew what good code looked like.

We then tried a 28-point checklist from ProductOS The Code Review Checklist: 28 Checks. It was too long. Interns skimmed it and missed the important parts.

Finally, we tried a five-point checklist focused on the red flags above. It stuck because it was short, specific, and tied to real consequences.

The Working Approach: Real Commands and File Paths

Today, every intern gets a copy of our review guide at /docs/intern-code-review.md. Before opening a PR, they run:

cd /app && python -m pytest tests/test_enrollments.py --tb=short

Then they open the PR with a description that follows the template. Reviewers check for the five red flags and categorize comments as nit, suggestion, or blocker Code Review Best Practices for India Dev Teams 2026.

If a review is large or confusing, we escalate to a synchronous call instead of dragging it out over multiple asynchronous rounds Code Review - The Software Engineer Internship Survival Guide.

Pitfalls We Would Warn an Intern About

• Do not ignore feedback. Respond within an hour, ideally Code Review - The Software Engineer Internship Survival Guide.
• Do not land a PR with unresolved comments unless clearly communicated and agreed upon Code Review - The Software Engineer Internship Survival Guide.
• Do not assume the reviewer knows your context. Write it down.
• Do not skip unhappy-path tests. They are the difference between a feature and a liability.
• Do not trust user input. Validate, sanitize, and authorize at every layer.

What We Would Do Differently Next Time

We would start the internship with a mock code review session. We would take an old PR from a senior engineer and walk the intern through it line by line. This builds shared vocabulary before applying it to current work Code Review Best Practices for India Dev Teams 2026.

We would also give interns permission to comment on senior code. In many Indian development teams, junior developers avoid commenting on senior code due to hierarchy norms, which defeats the quality purpose of review Code Review Best Practices for India Dev Teams 2026.

Conclusion: Turning Rejection into a Return Offer

Aaroh's PR eventually merged. Three months later, Aaroh led the enrollment feature from design to production. The return offer came with it.

The first PR is a test of communication, not just code. Interns who respond quickly, ask good questions, and fix blockers without argument earn trust. Those who ignore feedback or skip tests do not.

Your dynamic, how open, curious, and quick you are in responding to feedback, is often more important than just the substance of your code Code Review - The Software Engineer Internship Survival Guide.

We track metrics like review participation rate and time-to-first-review to make the culture shift visible Code Review Best Practices for India Dev Teams 2026. Interns who engage with those metrics tend to get offers.

The checklist is not a gate. It is a map. Follow it, and the first PR becomes the first step toward a return offer.