A good frontend code review checklist makes you review your own pull request before anyone else does: check readability, naming, tests, performance and accessibility, then write a description that lets a reviewer approve quickly. Used consistently, it cuts review rounds and shows maintainers you respect their time. This guide gives you a scored rubric, sample reviewer comments with replies, and a 14-day plan for IIIT Hyderabad students doing open-source style work.
Why self-review matters in a 14-day frontend internship
Fourteen days is short. If each pull request (PR) needs four review rounds with a day’s delay each, you can finish only a few. Reviewers in open-source style projects are usually busy, and a PR that is small, clear and already checked gets attention first. A self-review pass catches the cheap problems (stray console.log calls, unclear names, a missing test, an unlabelled button) so the reviewer can spend time on design questions.
Self-review also builds the habit that matters in real teams: treating the diff as something someone else must understand without you in the room. The free two-week online internship from CareerSwami includes a free offer letter and a free completion certificate after successful completion, and its 26 tracks give you a place to practise this routine on real tasks. The skill itself, though, applies to any repository you contribute to.
The scored self-review rubric for frontend pull requests
Score each row 0 (not done), 1 (partly done) or 2 (done). Do this on the “Files changed” tab, not in your editor, because you notice different things when you see the diff as a reviewer does.
| Area | Question to ask the diff | 2 points means |
|---|---|---|
| Scope | Does this PR do exactly one thing? | One purpose, no drive-by reformatting of unrelated files |
| Readability | Can a stranger follow each component top to bottom? | Components are short, logic is not deeply nested, comments explain why rather than what |
| Naming | Do names say what a thing is or does? | Components are nouns, handlers start with handle or on, booleans read as questions (isOpen, hasError) |
| Tests | Is every new behaviour covered or explained? | Tests assert what the user sees or does; any gap is stated in the PR |
| Performance | Did I add avoidable work on render, load or scroll? | No unnecessary re-renders, large imports, or unoptimised images |
| Accessibility | Can it be used by keyboard and screen reader? | Semantic elements, labels, visible focus, sufficient contrast |
| Consistency | Does it match the project’s style and structure? | Linter and formatter pass; file placement follows existing patterns |
| Description | Does the PR text explain what, why and how to check? | Linked issue, summary, steps to test, screenshots for visual changes |
Total out of 16. A score of 14 or more is ready to submit. Between 10 and 13, fix the lowest rows first. Below 10, the PR is probably too big; split it.
Free 2-Week CareerSwami Internship
Online, 14 days, with a free offer letter and a free completion certificate once you finish the work. Check with your college that it fits your requirement before you enrol.
Readability checks that reviewers notice first
- Remove debug leftovers. Search the diff for
console.log, commented-out blocks andTODOnotes that you will not resolve. - Flatten nesting. If a component has three levels of ternaries or nested
ifstatements, use early returns or extract a small helper. - Keep components focused. If a file mixes data fetching, formatting and markup, consider separating them.
- Avoid magic values. Replace unexplained numbers and strings (
if (status === 3)) with named constants. - Comment the reason. “Debounce to avoid a request per keystroke” helps; “set state” does not.
- Keep the diff small. As a rough habit, aim for a PR that can be reviewed in one sitting. If it cannot, split it.
Naming conventions to check line by line
Names are the most-commented item in beginner PRs because they cost nothing to fix and a lot to misread. Check the following, then follow whatever the project’s own guide says if it differs.
- Component names use PascalCase and describe the thing:
CourseCard, notBox2. - Event handlers describe the action:
handleSubmit, passed to props namedonSubmit. - Booleans read naturally in a condition:
isLoading,hasUnsavedChanges. - Avoid vague names such as
data,temp,obj,handleClick2. - CSS class names follow one convention across the project (BEM, utility classes or modules), not a mix.
- Test names describe behaviour: “shows an error when the email is empty”.
Tests: what a frontend reviewer expects to see
You do not need to test everything, but you should be able to say what you tested and why. Prefer tests that describe what a user experiences over tests that inspect internal state.
- Check whether the project already has a test setup and follow it. Do not introduce a new testing library in a small PR.
- Cover the main path, one empty or error state, and one edge case (very long text, zero items, slow network).
- Query elements the way a user finds them: by role, label or visible text, not by fragile class names.
- If you changed visuals only, attach before and after screenshots and say how you checked at narrow and wide widths.
- If you could not add a test, write the reason in the PR description instead of leaving it for the reviewer to discover.
- Run the full existing test suite and the linter locally before pushing, and report only results you actually saw.
Performance checks for everyday frontend changes
| Check | What to look for | Typical fix |
|---|---|---|
| Images | Large files, missing dimensions, no lazy loading below the fold | Resize, compress, set width and height, use lazy loading |
| Imports | Pulling a whole library for one function | Import only what you need or use a lighter alternative |
| Re-renders | New objects or functions created in render and passed to children; state held too high | Move state closer to where it is used; memoise only after you have a reason |
| Lists | Missing or index-based keys, huge unpaginated lists | Stable unique keys; paginate or virtualise |
| Events | Scroll or input handlers firing on every event | Debounce or throttle |
| Layout shift | Content jumping as images or fonts load | Reserve space with dimensions or aspect ratio |
Measure before optimising. The browser’s developer tools performance and network panels will show whether a change is worth making. Do not add memoisation everywhere “just in case”; reviewers often ask you to remove it.
Worked illustrative example: scoring a search-box PR
This example is illustrative. It describes a hypothetical PR and was not run against real code.
Imagine you add a search box to a course-listing page. Your first pass at the diff shows a component called Box, a fetch call on every keystroke, no test, an input with only a placeholder, and a leftover console.log. Scoring it:
| Area | Score | Reason | Fix before submitting |
|---|---|---|---|
| Scope | 2 | Only the search feature changed | None |
| Readability | 1 | Debug log left in | Remove it |
| Naming | 0 | Box and data say nothing |
Rename to CourseSearchInput and matchingCourses |
| Tests | 0 | No coverage | Add a test for typing a term and seeing filtered results, plus an empty-result message |
| Performance | 0 | Request per keystroke | Debounce the input |
| Accessibility | 1 | Placeholder only | Add a real label |
| Consistency | 2 | Linter passes | None |
| Description | 1 | One line only | Add steps to test and a screenshot |
The score is 7 out of 16, so the PR is not ready. After fixing the rows above, a rescore would reach the mid-teens, and the reviewer sees a cleaner diff on the first look.
Review comments to expect and how to respond
Comments are about the code, not about you. Reply to each one, even if only to say “Done”. Sample comments and suitable replies:
| Likely comment | What it usually means | Useful reply |
|---|---|---|
| “Can you rename this? It’s unclear.” | The name hides intent | “Renamed to matchingCourses in the latest commit.” |
| “Please split this PR.” | It mixes concerns or is too long to review | “Makes sense. I’ll keep the search box here and move the layout cleanup to a separate PR.” |
| “Where are the tests?” | New behaviour is unverified | “Added tests for results and empty state. I did not cover the error state; should I add it here or open a follow-up?” |
| “This re-renders the whole list.” | State or props cause avoidable work | “Moved the state down into the input component. Let me know if you’d prefer a different approach.” |
| “Nit: trailing whitespace / import order.” | Minor style; often auto-fixable | “Fixed, and I’ve enabled the formatter on save.” |
| “Why this approach?” | A genuine question, not necessarily an objection | Explain the trade-off briefly and offer to change it if they prefer. |
| “Not sure we want this feature.” | Scope or direction concern | Ask what outcome they want; do not argue or rewrite without agreement. |
Rules for disagreeing politely
- Say what you understood, then give one reason for your choice.
- Offer a small change or follow-up rather than a debate.
- If the maintainer repeats the request, make the change. Maintainers own their project’s conventions.
A 14-day plan for pull requests and reviews
- Days 1-2: Read the contributing guide, set up the project locally, run the tests, and pick a small issue.
- Days 3-5: Build the change. Commit in small steps with clear messages.
- Day 6: Run the rubric on your diff and fix every row below 2.
- Day 7: Open the first PR with a full description and screenshots.
- Days 8-9: Respond to review within a day. Start a second small task while you wait.
- Days 10-12: Finish the second PR using the same rubric, and review someone else’s PR if the project allows it.
- Days 13-14: Close out open comments, tidy your PR descriptions, and write a short note on what the reviews taught you.
IIIT Hyderabad students: where an online internship and the institute’s own programmes differ
One verified item at IIIT Hyderabad is relevant context. The IHUB-DATA hub advertises a Young Research Internship Program, described as a full-time, offline internship of about 3 to 6 months on campus for pre-final or final-year B.Tech and M.Tech students, with no accommodation or fellowship. That information comes from a 2025 excerpt, so check the current version before relying on it.
What this means in practice: that programme is a research placement run by a hub, with a different format and time commitment from a 14-day online frontend internship. It does not tell you how the institute treats a short online internship in its curricular rules. We have not verified IIIT Hyderabad’s rules on curricular internships, credit, evaluation, documents or online internships, so do not assume a CareerSwami internship counts for any credit or requirement. CareerSwami’s internship is free and gives an offer letter and a completion certificate; it does not provide a stipend or academic credit.
The practical benefit for you is the portfolio. Merged or reviewed PRs with clear descriptions are evidence of skill that you can show to research groups, project mentors or employers, whatever the institute’s rules say.
Verification steps for IIIT Hyderabad students before you commit
- Ask your academic office or programme coordinator in writing whether an external online internship can be recorded on your transcript, and in what form.
- Request the current internship or project-work regulation for your programme and year, and check the duration, credit and documentation clauses.
- Ask whether a certificate and offer letter from an external provider are accepted as supporting documents, and who signs off.
- Check with the career development or placement office whether there are rules on internships during semesters or breaks.
- If you plan to apply to the IHUB-DATA programme, read the current brochure on the hub site for eligibility, dates and application steps.
- Keep your PR links, review threads and certificate in one folder so you can answer any question quickly.
Frequently Asked Questions
How long should a self-review take as a International Institute of Information Technology student?
For a small PR, 15 to 30 minutes is realistic. Read the diff in the pull request view, score each rubric row, fix the weak ones, and then re-read once. If it takes much longer, the PR is likely too large.
How big should a pull request be?
Small enough to review in one sitting and focused on one purpose. There is no universal line count; follow the project’s guide if it states one, and split unrelated changes into separate PRs.
Do I need tests for a purely visual change?
Not always. If the project has no visual tests, attach before and after screenshots, state which screen widths you checked, and mention any accessibility checks you did. Say plainly what you did not test.
What if a reviewer’s comment seems wrong?
Ask a clarifying question and explain your reasoning once, politely. If the maintainer still prefers their way, adopt it. Conventions belong to the project, and arguing costs you review time.
Should I optimise performance in every PR?
No. Avoid obvious waste, such as huge images, unnecessary imports and handlers that fire constantly, but measure before doing anything complex. Premature memoisation makes code harder to read.
Can a short internship PR go into my portfolio?
Yes, if the repository owner allows it. Link the PR, summarise the problem, your change and what the review improved. Do not claim merges or outcomes that did not happen.
Will the internship count for credit at my institute?
CareerSwami does not offer academic credit. Whether your institute recognises any external internship is a question for your academic office, so ask in writing and keep the reply.
How do I handle review delays in a 14-day window?
Open your first PR by about day 7, keep a second task ready, and ask politely after two working days of silence. Make your PR easy to approve with a clear description and small scope.
Related Frontend Development guides
- University of Ladakh Students: Offline-First Frontend Internship Project for Remote Regions
- M.S. Ramaiah University of Applied Sciences: Frontend Internship Testing with Jest and Testing Library
- Starex University Students: Frontend Internship Common Failures and How to Avoid Them
- All Frontend Development internship guides
Ready to put this into practice?
Join the free two-week CareerSwami online internship in Frontend Development. The internship, the offer letter and the completion certificate are free.
