Gautam Buddha University Students: Debugging Routine for Frontend Internship Beginners

The most reliable debugging routine for a frontend beginner is a fixed order: reproduce the bug, read the console, check the network tab, then pause the code with breakpoints, and write every bug into a journal. Following the same order every time stops you from guessing, and over a 14-day internship the journal turns each fix into a skill you can explain in an interview. This guide gives you the flowchart, the journal template and a day-by-day plan.

Why a fixed debugging order beats guessing

Most beginners debug by changing code until something works. That feels fast, but it hides the real cause, and the same bug returns in a different form. A routine forces you to collect evidence before touching anything. In frontend work, evidence lives in three places:

• The console shows JavaScript errors, warnings and anything you chose to log.
• The network tab shows every request the page makes, with status codes, payloads and timings.
• The debugger (breakpoints) lets you freeze execution and inspect real variable values at a specific line.

There is a fourth place, the Elements panel, which matters for layout and CSS bugs. This article focuses on logic and data bugs first, then covers styling briefly.

The step-by-step debugging flowchart (console, network tab, breakpoints)

Read this as a flowchart in text form. Start at step 1 and only move on when the current step gives you no answer.

1. Reproduce the bug. Write the exact clicks or inputs that trigger it. If you cannot reproduce it twice, you cannot confirm a fix.
2. Open DevTools and refresh with the Console visible. Is there a red error?
   • Yes: read the message and the file and line number beside it. Click the link and go to that line. Go to step 6.
   • No: continue to step 3.
3. Open the Network tab and repeat the action. Did the expected request fire?
   • No request: the problem is in your event handler or condition. Go to step 5.
   • Request fired: continue to step 4.
4. Inspect the request and response. Check the URL, method, status code, request payload and response body.
   • Status 4xx or 5xx, or a wrong URL or payload: fix the request or raise it with whoever owns the API. Go to step 7.
   • Status 200 but the screen is wrong: the data arrives fine, so the bug is in how you use it. Go to step 5.
5. Set a breakpoint on the first line of the relevant handler or render function. Trigger the bug, then step through line by line and watch the Scope panel. Find the first line where a value stops matching what you expected.
6. Form one hypothesis about the cause, based on the evidence. State it in a sentence before editing.
7. Change one thing, retest the exact reproduction steps, and confirm the symptom is gone and nothing nearby broke.
8. Write the bug journal entry. Symptom, cause, fix, and what you would check sooner next time.

What to look at in each tool

Reading console errors without panic

Three messages account for a large share of beginner bugs:

• “Cannot read properties of undefined”: you are accessing a field on something that has not loaded or does not exist. Check what the variable holds at that moment, often before an API response arrives.
• “X is not defined”: a typo, a missing import, or a variable used outside its scope.
• “Unexpected token” or a JSON parse error: you tried to parse something that is not JSON, commonly an HTML error page returned by the server. Look at the raw response in the network tab.

Read the stack trace from the top. The first line that points to your own file, not a library, is usually where to start.

Breakpoints that save the most time

• Line breakpoint: click a line number in the Sources panel. Execution pauses before that line runs.
• Conditional breakpoint: right-click a line and add a condition such as item.id === 42. Useful inside loops.
• debugger; statement: pauses execution when DevTools is open. Remove it before committing.
• Event listener breakpoint: pause on a click or submit without knowing which file handles it.
• Step controls: step over (run this line), step into (go inside the function), step out (finish the function). Beginners usually need step over and step into only.

Prefer breakpoints to scattered console.log lines when you do not yet know where the problem is. Use logs when you want to watch a value change over time, such as during typing or scrolling.

Bug journal template: symptom, cause and fix

Copy this into a notes file, a spreadsheet or a markdown document. One row or block per bug.

Bug #: 
Date / Day of internship: 
Page or component: 

SYMPTOM (what I saw, in user terms):
STEPS TO REPRODUCE:
1.
2.
3.
EXPECTED:
ACTUAL:

EVIDENCE
Console message:
Network request (URL, status):
Value at breakpoint:

HYPOTHESIS (one sentence):
ROOT CAUSE (confirmed, not guessed):
FIX (what I changed and in which file):
RETEST (what I re-ran, what still works):

CATEGORY: logic / data / network / styling / state / tooling
TIME TO FIND: 
WHAT I WOULD CHECK FIRST NEXT TIME:

The “category” and “check first next time” fields are what make the journal useful. After a week you will see patterns, for example that most of your bugs are data-shape mistakes, which tells you to inspect the response body earlier.

Journal as a table, for quick scanning

The rows above are illustrative entries to show the format, not results from a real project.

Worked example: a search box that shows no results

This scenario is illustrative. Suppose you build a small page where typing a name into a search box should filter a list fetched from an API. You type “ravi” and the list goes empty.

1. Reproduce: load the page, type “ravi”, the list disappears. It happens every time.
2. Console: no red errors. Move on.
3. Network: one request fires on page load, returning 200. No new request on typing, which is expected if filtering happens locally.
4. Response: the body is an array of objects with a field called fullName.
5. Breakpoint: set one inside the filter function. Pausing there, the Scope panel shows user.name is undefined for every item, so undefined.toLowerCase().includes("ravi") style logic returns no matches (or throws if written differently).
6. Hypothesis: the code uses the wrong field name.
7. Fix: change user.name to user.fullName, and retest with “ravi”, “RAVI” and an empty box.
8. Journal: category Data. Next time, check the response shape before writing the filter.

Notice that guessing could have taken far longer: the console was silent, and the network call looked healthy. Only the breakpoint exposed the mismatch.

A 14-day debugging practice plan for a short internship

If you join the free two-week online internship from CareerSwami, you get 14 days to build and fix small frontend projects, with a free offer letter and a free completion certificate after successful completion. Use the days like this so debugging is practised, not just mentioned:

Gautam Buddha University students: fitting debugging practice around internship rules

GBU is a state university in Greater Noida, and its 2026-27 admission brochure states that internships and research projects are integral and compulsory for all UG and PG programmes. It also describes a Corporate Relations Cell (CRC) that offers training, summer and final placement assistance and industry liaison. So building a debugging record is directly useful when you speak to the CRC or a mentor about your work.

For B.Tech CSE, the 2024-28 programme structure from USICT says Industrial Training is done individually after third year in the summer break, for a minimum of 4 weeks, and is evaluated in semester VII. It lists a semester VIII internship of a minimum of 4(-6) months, and says USICT will provide a mentor or supervisor. That document is from 2024 and the credit wording in the extracted text was partly unclear, so check the PDF itself and the current version for your batch.

What the documents we reviewed do not say is whether an online internship, such as a two-week remote programme, counts toward any of these requirements. Treat a CareerSwami internship as a skill-building and portfolio addition, not as a substitute for the university’s mandated training, unless your department confirms otherwise in writing. The School of Management also publishes a tentative MBA (Business Analytics and Data Science) structure with a 4-credit Summer Internship, so rules differ by school.

Verification steps for GBU students

1. Download the programme structure PDF for your exact batch from your school’s page and read the industrial training and internship lines.
2. Email your department coordinator or training mentor asking: “Can an online two-week internship be reported as part of industrial training, or only as extra learning?”
3. Ask what documents are needed for evaluation (report, certificate, mentor sign-off) and request the format in writing.
4. Check the Academic Calendar 2026-27 via the Examinations Portal for break dates before planning your 14 days.
5. Visit the CRC and ask whether they review project portfolios or debugging write-ups before summer placement activity.

Common frontend bug types and the first place to look

Habits that make the routine stick

• Change one thing at a time. Two edits at once leave you unsure which one worked.
• Tick “Disable cache” in the Network tab while DevTools is open, so you are not testing old files.
• Keep the Console filter on “Errors” when the log is noisy, then switch to “All”.
• Copy error messages exactly into your journal. You will search for them again.
• Explain the bug aloud, step by step, to yourself or a friend. Gaps in your explanation often point to the cause.
• Use version control commits after each confirmed fix so you can roll back a bad change.

Frequently Asked Questions

What should a beginner check first when a webpage breaks?

Open the console and look for a red error with a file and line number. If there is none, move to the network tab to confirm the expected request was sent and returned a sensible response, then use a breakpoint.

When should I use console.log and when a breakpoint?

Use a breakpoint when you do not know where the problem is, because it lets you inspect every variable at one moment. Use console.log to watch values change over time, such as during typing, timers or repeated renders.

What does a 404 or 500 in the network tab mean for my code?

A 404 usually means the URL or path is wrong. A 500 means the server failed, which is often outside your frontend code, though a malformed request body can trigger it. Check the request payload and tell the API owner exactly what you sent.

How detailed should my bug journal be?

Detailed enough that you could fix the same bug again in five minutes. Record the symptom, evidence, confirmed cause, fix and a “check first next time” note. Short entries written immediately are better than long ones written later.

Can I show my bug journal to recruiters or mentors?

Yes, a cleaned-up selection of two or three entries shows structured thinking. Remove anything confidential. It works well alongside a small project on GitHub with commits that match each fix.

Will a two-week online internship count as my GBU industrial training?

This is not confirmed. The B.Tech CSE structure we reviewed specifies a minimum of 4 weeks for industrial training and does not mention online internships. Ask your department in writing before assuming it counts.

What is the difference between a bug’s symptom and its cause?

The symptom is what the user sees, such as an empty list. The cause is the specific code or data fault behind it, such as reading the wrong field name. Fixing symptoms without finding causes leads to repeat bugs.

How do I debug a bug I cannot reproduce every time?

Note the conditions each time it happens: network speed, input values, browser and sequence of actions. Throttle the network in DevTools, clear storage, and add logging around the suspect code until a pattern appears.

Related Frontend Development guides

• KREA University: Frontend Internship for Liberal Arts Students Building Data Stories
• University of Patanjali Students: Frontend Internship Project for a Wellness Website
• Rani Channamma University: Frontend Internship Guide for Kannada and Multilingual Interfaces
• All Frontend Development internship guides