BMS College of Engineering Students: Frontend Development Internship Report Structure and Evidence

A strong frontend internship report has seven parts: a short project summary, the problem and scope, UI screenshots with captions, a component hierarchy, implementation notes, testing notes, and a reflection. Each claim should point to evidence a reader can check, such as a screenshot, a repository link or a test note. BMS College of Engineering students should treat the skeleton below as a working structure and confirm the college’s own format before final submission.

What “evidence” means in a frontend report

Frontend work is visual and interactive, so a paragraph saying “I built a responsive dashboard” proves very little. An evaluator, a faculty guide or a future recruiter wants to see what the page looked like, how it was put together, and how you know it worked. Evidence in this domain usually falls into five groups:

• Visual evidence: labelled screenshots at defined screen widths, in specific states (empty, loading, error, success).
• Structural evidence: a component tree or folder map showing how the interface is divided.
• Process evidence: dated commit history, task notes, or a short log of what was done each day.
• Quality evidence: testing notes covering functionality, responsiveness, accessibility and browser behaviour.
• Judgement evidence: reflection on trade-offs, mistakes and what you would change.

A short internship, such as the free two-week online internship from CareerSwami, which runs for 14 days and offers a free offer letter and a completion certificate after successful completion, produces a compact body of work. The report should therefore be tight: a small project, documented properly, beats a large one described vaguely.

Report skeleton you can copy

The table below is a complete skeleton. Page counts are suggestions for a report of roughly 15 to 25 pages including figures. They are not a requirement from any institution.

UI screenshots: rules that make them count

Screenshots are the most visible part of a frontend report, and the easiest to do badly. Cropped, unlabelled, or taken only at one width, they show little. Use these rules:

1. Number every figure (Figure 5.1, 5.2) and refer to it in the text.
2. Write a caption that states the screen, the viewport width and the state, for example “Figure 5.3: Order list, 375 px wide, empty state”.
3. Capture at least two widths: a phone-sized view (around 375 px) and a desktop view (around 1280 px). Add a tablet view if your layout changes there.
4. Show states, not only the happy path: loading, empty, error and success.
5. Annotate sparingly: a numbered marker on a screenshot, explained below it, helps a reader find the navbar or form without extra paragraphs.
6. Keep personal data out: use dummy names and emails. Do not show API keys, tokens or private URLs in devtools screenshots.
7. Keep the original image files in an appendix folder so the report can be regenerated at higher quality.

Screenshot checklist

• Is each screenshot sharp enough to read the text on it when printed?
• Does every figure have a number, caption and in-text reference?
• Do screens appear in the order a user would meet them?
• Is there a before-and-after pair for at least one improvement, such as a layout fix?
• Are browser address bars and bookmarks free from unrelated personal content?

Component hierarchy: how to document it

A component hierarchy shows how the interface is broken into reusable parts and where data lives. It is the strongest evidence that you understand structure rather than copied a template. Document three things: the tree, the responsibility of each component, and who owns the state.

You can use a diagram, but an indented text tree is easy to write and easy to check. The same idea applies whether you used React, Vue, Angular or plain HTML, CSS and JavaScript with modules.

Component table template

Add one sentence on why state sits where it does. For example, the cart lives in App because both MenuList and CartPanel need it. That single justification shows more understanding than a long description.

Worked example (illustrative, fictional project)

The example below is invented to show the level of detail expected. The project, numbers and findings are not from a real student or institution, and no code or tests were run for this article. Replace everything with your own work.

Fictional project: “QuickBite” canteen pre-order page

Problem statement (illustrative): Students waste time queueing at a campus canteen. QuickBite is a single-page interface where a student browses the menu, adds items to a cart and sees a pickup summary. There is no real payment and no backend; menu data comes from a local JSON file.

Scope line: Included are menu browsing, cart, responsive layout and keyboard navigation. Excluded are login, payment and order history.

Component tree (illustrative):

App
├── Header
│   └── CanteenSelector
├── MenuList
│   └── MenuItemCard (repeated)
├── CartPanel
│   └── CartLine (repeated)
└── StatusBanner

Screenshot plan (illustrative):

• Figure 5.1: Menu, 1280 px, default state.
• Figure 5.2: Menu, 375 px, with cart collapsed.
• Figure 5.3: Cart with three items, 375 px.
• Figure 5.4: Empty-cart message.
• Figure 5.5: Error banner when the menu file fails to load.

Implementation note (illustrative): The cart total was wrong when the same dish was added twice because each click created a new line. The fix was to store quantity against the item id and calculate the total from that. A short excerpt in the report might look like this:

// Illustrative excerpt, not executed
function addToCart(cart, item) {
  const existing = cart.find(line => line.id === item.id);
  if (existing) {
    return cart.map(line =>
      line.id === item.id ? { ...line, qty: line.qty + 1 } : line
    );
  }
  return [...cart, { id: item.id, name: item.name, price: item.price, qty: 1 }];
}

The report would then explain in two lines why the function returns a new array instead of changing the old one, and refer to the commit where the bug was fixed.

Testing notes (illustrative table):

Reflection excerpt (illustrative): “I first treated the cart as display-only and put its state inside CartPanel. When MenuList also needed to show ‘already added’ badges, I had to lift the state up to App. Next time I would sketch the data flow before writing components.”

Testing notes: what a frontend report should cover

Many students list “tested on Chrome, works fine” and stop. A better testing section is a short table plus a few honest observations. Cover these areas:

• Functional checks: each user action, with steps and expected result.
• Responsive checks: at least 320, 375, 768 and 1280 px widths.
• Accessibility checks: keyboard-only use, visible focus, alt text on images, form labels, and colour contrast of body text.
• Browser checks: the browsers you actually opened, with versions if you know them. Do not list browsers you did not use.
• Performance observations: a Lighthouse or devtools reading, if you ran one, with the date and what you changed afterwards.
• Bugs found and fixed: a short log with cause and fix. This is often the most convincing evidence in the report.

Report only tests you really performed, and state the outcome as it was. A failure followed by a fix reads better than a column of identical passes.

Evidence scorecard: rate your own report

Score each row from 0 to 2 (0 = missing, 1 = partial, 2 = complete and checkable). A total of 20 or more out of 24 suggests the report is ready for review. This scorecard is a self-check tool, not an official marking scheme.

Reflection prompts

Reflection is where a report stops being a diary. Answer at least five of these in specific terms, with a concrete moment from your project each time.

1. Which design decision did you change after seeing it on a real phone-sized screen, and why?
2. Where did you first put state, and where did it end up? What did that teach you?
3. Which bug took longest to find, and what finally revealed the cause?
4. What did you choose not to build in two weeks, and how did you decide?
5. Which accessibility problem did you not notice until you used only the keyboard?
6. Which tool or documentation page helped most, and what did you misunderstand about it at first?
7. If a classmate had to continue the project, what would they need to know?
8. Which one skill would you practise next, and how will you measure progress?

Daily log template for a 14-day internship

A simple log makes the process section easy to write. Keep it as you go instead of reconstructing it later.

BMSCE frontend internship reports: where the college’s own rules apply

BMS College of Engineering describes itself as autonomous since 2008 with UGC approval, approved by AICTE and affiliated to VTU, Belagavi. Its own regulations call it an “Autonomous Institute Affiliated to VTU” and apply them to its autonomous BE, MTech, MBA and MCA programmes. In practice, the format and evaluation of a frontend internship report are set by the college and your department, not by a generic university template.

The 2018 academic rules list Internship (IN) as a UG curriculum component, taken in summer or winter semester breaks and assessed through a seminar and a report submitted in the odd or even semester. For a frontend intern, that means the report and a short seminar are likely to be assessed together, so the UI screenshots, component table and test notes should be easy to present on slides. These rules date from 2018, so check the current version.

An excerpt from the 2018-21 CSE syllabus describes a technical seminar (SR-2) based on a summer or winter internship of at least two weeks, after the 4th and 5th semesters. This is an older scheme and an excerpt, so a 14-day log may or may not match your batch’s requirement.

Postgraduate students face different rules. The M.Tech regulations from 2016-17 describe a 16-week internship with a departmental evaluation committee and a viva with the external guide. The MBA 2024-26 syllabus lists a four-week internship (MBAIN387) with a report assessed internally in the third semester. Those students should follow their own programme document.

The fetched regulations do not address online internships, and no required certificate documents were confirmed. Do not assume a remote frontend internship is accepted until the department says so.

Checks before you start writing the BMSCE report

• Ask your department coordinator for the internship rules and scheme that apply to your admission year, since the documents found are from 2016 to 2018 and 2024.
• Confirm in writing whether an online or short internship counts, and the minimum duration for your semester.
• Ask when the report and seminar are due, relative to the odd or even semester start, and who evaluates them.
• Ask which documents must accompany the report, such as the certificate or offer letter.
• Check the Training and Placement Cell page for its contact (placement@bmsce.ac.in) if you need to ask whether the cell handles any internship paperwork.
• Check whether screenshots, code excerpts and repository links are allowed in the submitted file.

Frontend report mistakes that weaken your evidence

• Pasting entire source files. Use short excerpts and link the repository.
• Screenshots without context. A picture with no width, state or caption is hard to evaluate.
• Claiming features you did not build. Keep the scope section honest and list what is left out.
• Copying a tutorial project unchanged. If you started from a tutorial, name it and describe what you changed.
• Treating testing as an afterthought. Write test cases while building, not on the last day.
• Writing a reflection of generic praise. Specific mistakes and decisions are what readers remember.
• Inflating outcomes. A completion certificate shows you completed the internship. It is not a guarantee of marks, credit, selection or a job, so do not describe it that way in the report.

Final submission checklist

• Title page, declaration and contents page are present and match the college format, if one exists.
• Every figure and table is numbered, captioned and mentioned in the text.
• Component hierarchy and state ownership are explained in plain sentences.
• Test table contains real results, including failures and fixes.
• Repository and demo links open without login, and the README explains how to run the project.
• No secrets, personal data or unrelated browser content appear in any image.
• Borrowed assets, icons, fonts and tutorials are credited.
• The PDF is checked on another device, so images and fonts display correctly.
• Names, dates and track details match your offer letter and certificate.

Frequently Asked Questions

How many screenshots should a frontend internship report have?

Quality matters more than count. Eight to fifteen well-captioned figures in the main body is a reasonable range for a small project, covering key screens at phone and desktop widths and at least one error or empty state. Put the rest in an appendix.

Should a frontend internship report include source code, or are screenshots and repository links enough?

Include only short excerpts that illustrate a problem you solved, and link the full repository. Pages of pasted code add length without adding evidence. If your college specifies a code appendix, follow that instruction.

What is the simplest way to draw a component hierarchy?

An indented text tree works well, as in the example above. Pair it with a table listing each component’s purpose, props and state. You can also export a diagram from a tool such as Figma or draw.io if you prefer something visual.

Can I use a fictional or practice project in my report?

That depends on the internship’s brief and your college’s rules. Where a self-chosen project is allowed, describe it honestly as a practice project and state its scope. Ask your coordinator if you are unsure whether it will be accepted.

How detailed should my testing notes be for a two-week internship?

Six to twelve test cases in a table, plus a note on responsive, keyboard and browser checks, is enough. Record the steps, expected result and actual result, and mention at least one bug you fixed.

Should I mention the offer letter and certificate in the report?

Yes, reference them in the internship overview and attach copies in the appendix, as the college allows. The CareerSwami internship offers a free offer letter and a free completion certificate after successful completion, so list the dates and track exactly as they appear on the documents.

Does the report format change if I use React instead of plain JavaScript?

The structure stays the same. Only the content changes: in React you describe components, props and hooks, while in plain JavaScript you describe modules, DOM updates and event handling. The screenshot, testing and reflection sections are identical.

Will this skeleton be accepted by BMSCE as it is?

That cannot be assumed. This is an independent guide and is not issued or endorsed by the college. Check the questions in the “Confirm with your college” list and adapt the skeleton to any format your department gives you.

Related Frontend Development guides

• Ramaiah Institute of Technology Students: Frontend Development Internship Readiness Checklist
• PSG College of Technology Students: Comparing Frontend Internship Roles in UI, Accessibility and Web Performance
• Thiagarajar College of Engineering Students: Frontend Internship Demo Guide Using a Component Library
• All Frontend Development internship guides