PES University Students: Reviewing a Java Pull Request Like an Intern Who Wants to Learn

To review a Java pull request like an intern who wants to learn, read the description first, run through a fixed checklist (purpose, correctness, readability, tests, Java-specific risks), and write comments as questions rather than orders. Your goal is to understand the change and flag genuine concerns politely, not to prove the author wrong. The checklist and comment bank below are built for exactly that.

Why a junior’s review still matters

Many students assume code review belongs to senior engineers. In practice, a fresh reader catches things the author has stopped seeing: a variable name that makes no sense without context, a missing explanation, a test that does not test what its title says. You are also learning the codebase faster by reading changes than by reading files cold.

The risk is tone. A junior who writes “This is wrong, change it” sounds presumptuous, and a junior who writes nothing learns nothing. The middle path is curious, specific, and kind: ask what the author intended, point to the exact line, and say what you noticed.

Before you open the diff: a five-minute preparation routine

1. Read the title and description. Can you state in one sentence what the change is meant to do? If not, that is your first comment.
2. Check the linked issue or ticket. Does the pull request solve that problem, or more, or less?
3. Look at the size. A change touching a dozen files needs a different reading order than a ten-line fix. Large changes may deserve a polite request to split them.
4. Read the tests first. Tests show what the author believes the code should do. Then read the production code and see whether it matches.
5. Pull the branch if you can. Building it locally, where your setup allows, lets you step through with a debugger instead of guessing.

The Java pull request review checklist

Use this table as a pass-by-pass guide. You do not need to comment on every row; the point is to make sure you looked.

Turning demands into questions: a comment bank

The difference between a demand and a question is small in words but large in effect. A question invites the author to explain, and sometimes the author is right and you learn something. Adapt these to your own situation.

Questions about intent

• Instead of “Why did you do it this way?”, try: “I want to make sure I follow the approach here. Could you share what led you to choose a HashMap over a TreeMap?”
• Instead of “This is unnecessary”, try: “I am not sure I understand what this extra check protects against. Is there a case where the value can be null at this point?”

Questions about correctness

• Instead of “This will crash on an empty list”, try: “What do we expect to happen if orders is empty? I could not tell from the tests whether that case is covered.”
• Instead of “You are comparing strings wrong”, try: “I noticed == on these two strings. Would equals be safer here, or am I missing a reason it is intentional?”

Questions about readability

• Instead of “Bad name”, try: “I read data2 a couple of times before I got what it holds. Would something like pendingOrders match what it represents?”
• Instead of “Split this method”, try: “This method seems to handle validation, saving and notification. Would it be easier to test if they were separate, or is there a reason to keep them together?”

Questions about tests

• Instead of “Add tests”, try: “Could we add a case for the discount being exactly zero? I wasn’t sure whether the current tests reach that branch.”

Comments that praise and learn

• “This use of try-with-resources is clean. I had not seen it applied to a scanner like this before.”
• “I learned something from the way you structured this builder. Is there a guideline in the project for when to use one?”

Worked illustrative example: reviewing a small discount-calculation change

The scenario below is made up for teaching. It is not from a real project, and no code was compiled or run.

A teammate opens a pull request titled “Add discount to order total”. The description says “added discount logic”. The core of the change looks like this:

public double calculateTotal(List<Item> items, String coupon) {
    double total = 0;
    for (Item i : items) {
        total += i.getPrice() * i.getQty();
    }
    if (coupon == "SAVE10") {
        total = total - total * 0.10;
    }
    return total;
}

Step 1, purpose. The description is thin. A good first comment: “Could you add a line to the description about which coupons are supported and where the rule comes from? I want to check the code against the requirement.”

Step 2, correctness. Three things stand out. The string comparison uses ==. The method will throw a NullPointerException if items is null. And money is stored in a double.

Comments you might leave:

• On the coupon line: “I think == compares references for strings, so a coupon read from user input might not match. Would "SAVE10".equals(coupon) be safer? Happy to be corrected if the value is always an interned constant.”
• On the method signature: “What should happen if items is null or empty? I could not find a test for either.”
• On the type: “I have read that BigDecimal is often preferred for currency because of rounding. Is double a deliberate choice here, or worth discussing?”

Step 3, tests. You find one test, with a single item and no coupon. Comment: “The coupon path does not seem covered. Could we add one test with a valid coupon and one with an unknown coupon?”

Step 4, tone check. Before submitting, reread each comment. Does it point to a line? Does it explain why you are asking? Does it leave room for the author to know something you do not? Add one genuine positive note, for example: “The loop is easy to follow and the method name says exactly what it does.”

A reading order that keeps you from drowning in a big diff

1. Description and linked ticket.
2. File list: which packages are touched? Does anything surprising appear, such as a config file or a build script?
3. Tests, to learn the intended behaviour.
4. Public interfaces and method signatures.
5. Implementation details, one file at a time.
6. A final pass for style, naming and leftover debugging code.

Leave comments as you go, but submit them as a single review rather than a flood of separate notifications. Summarise at the top: what you understood, what you liked, and the two or three points that matter most.

Sorting your comments by weight

Not every observation deserves the same urgency. Labelling comments helps the author prioritise and keeps you from sounding harsher than you mean to.

Reserve “concern” for things you can describe with a concrete scenario. If you cannot explain how it would fail, make it a question.

For PES University students: using pull request practice alongside your coursework

No verified, official PES University information on internship, industrial training or project-work rules was available for this article, so nothing here claims what the university requires, credits, or accepts. What is certain is that code review skills are portable: they apply to team projects, open-source contributions and any internship that uses Git.

If you are working on a team project for a course, you can practise right away. Agree on a rule with your teammates that every change goes through a pull request and gets at least one review before merging. Use the checklist above, and keep your comments in the repository as a record of what you learned. That history can later help you explain your contribution in an interview, as long as you describe it accurately.

If you plan to use any internship for university requirements, do not assume that a short online internship will be accepted for credit or evaluation. Rules may differ by programme, scheme year or school. Verify them before you start:

1. Find the official internship or project-work guidelines for your programme on the pes.edu website or in your student handbook, and note the scheme year they apply to.
2. Email your department’s internship coordinator or faculty mentor and ask in writing whether an online internship of 14 days qualifies for any requirement, and what documents they need.
3. Ask the training and placement or corporate relations office whether they keep a list of acceptable internship formats, and what proof they require.
4. Confirm whether your course project must use a particular repository host or whether you may use a personal Git account for review practice.
5. Ask your faculty whether peer code review can be mentioned in a project report or viva, and how contributions should be documented.
6. Check your academic calendar for semester breaks, so a 14-day internship does not clash with exams or lab submissions.

A 14-day plan to build the habit

If you are doing a two-week internship, a short routine makes review a habit rather than a one-off. The free two-week online internship at CareerSwami is one option for structured practice; it offers a free offer letter and a free completion certificate after successful completion, with 26 tracks to choose from. It does not promise a stipend, academic credit or a job, so treat it as a way to build skills and evidence of work.

Receiving a reply: how to handle the author’s answer

• If the author explains and you are satisfied, say so briefly and resolve the thread.
• If the author disagrees and the point is minor, let it go.
• If you still think there is a real risk, restate it with a concrete scenario rather than repeating yourself.
• If you were wrong, say “Thanks, that makes sense” and note what you learned. That is a sign of a good reviewer, not a weak one.

Frequently Asked Questions

Is it appropriate for an intern to comment on a senior’s code?

Yes, if the comments are specific and phrased as questions. Reviewers are not judging seniority; they are helping the team understand and trust a change. Asking “could you help me understand this line?” is welcome in most teams.

What if I do not understand the code at all?

Say so. A comment like “I could not follow the flow in this method; could you add a short comment or walk me through it?” is useful feedback, because unclear code is a legitimate finding.

How many comments should I leave on one pull request?

Focus on the few that matter most. Three to six well-chosen comments are usually more useful than twenty small ones. Group style points under a single “nit” summary where possible.

Should I approve a pull request if I only understood part of it?

Be honest in the review. You can leave comments without approving, or state which parts you reviewed and which you did not. Ask whoever owns the repository how approvals are expected to work on your team.

Which Java issues are most common in beginner pull requests?

Using == instead of equals for objects, ignoring null cases, catching exceptions and doing nothing, forgetting to close resources, and writing tests that never fail. The checklist table covers all of these.

Can I practise reviewing without a team?

Yes. Read pull requests on public Java repositories and write your comments privately, then compare them with what the actual reviewers said. You can also review your own code a day after writing it, as if a stranger wrote it.

Will code review practice count towards my university internship requirement?

That depends on your programme’s rules, which were not verified for this article. Ask your department coordinator in writing and keep a copy of the reply before you rely on any internship for university requirements.

How do I keep my tone friendly in writing?

Use “I” statements, point to a line, explain your reason, and include something positive. Avoid words like “obviously”, “just” and “wrong”. Reread each comment as if it were addressed to you.

Related Java & Enterprise Software guides

• Apex University Students: A Final-Week Checklist for Wrapping Up a Java Internship
• Vikrant University Students: Time Planning for a Java Internship During Exam Season
• SRM University-AP: What a First-Year Student Can Realistically Do in a Java Internship
• All Java & Enterprise Software internship guides