Web Frontend
Career Paths
How to interpret this table?
You may choose this advanced topic if you like doing the things listed under “they usually do”, and you are fine with not doing the things listed under “they usually do not do”.
Alternatively, you may choose it if you are interested in applying for the listed job roles and want to practice work that is close to those roles.
| Job title | They usually do | They usually do NOT do | Real-life examples |
|---|---|---|---|
| Frontend Software Engineer | Implement browser-based user interfaces, manage client-side state, handle user interactions, integrate with backend APIs, ensure usability and responsiveness | Design backend architectures, implement server-side business logic, manage infrastructure or deployment pipelines | Gmail web UI, Trello frontend |
| UI / UX-focused Developer | Build clear, usable interfaces, apply basic UX principles, ensure accessibility and responsive layouts | Conduct formal UX research, produce marketing designs, or define product strategy | Notion editor UI, Figma web app |
| Full-Stack Developer (frontend-leaning) | Implement frontend features, connect to APIs, handle auth flows in the browser, debug client-server interaction | Deep backend optimization, infrastructure scaling, or data modeling decisions | Airbnb web frontend, Spotify web player |
Affected SDLC Phases
If a team chooses this advanced topic, the system design, implementation, and testing phases are most strongly affected, as the focus shifts toward browser-based execution, frontend architecture, user interaction, and UI quality. Planning emphasizes feature scoping from a user-interface perspective. Deployment is minimal and focuses on running the application in a common browser (e.g. Chrome).
Affected Tasks
Features are defined
Minimum Viable Product (MVP)
By the end of this task, your team has defined at least six frontend features that are visible and usable in a web browser. Each feature must describe what the user can see and do in the UI. Teams must clearly state whether they build a thin client (mostly backend-driven UI) or a thick client (significant client-side logic) and apply this choice consistently across all features.
Technical Details
Before defining features, the team must choose exactly one frontend style: thin client or thick client. This decision must be stated clearly in README.md and applies to all features.
Use a consistent feature issue template. Each feature must include:
- User-visible behavior (what the user does and what changes on screen)
- Main UI elements involved (views, components, pages)
- Required backend interaction (API call or data source), if any
- Done criteria expressed in observable UI terms
Features must be end-to-end from the browser perspective. Avoid vague items like “build frontend” or “improve UI”.
Quality
High-quality feature definitions are concrete, user-facing, and testable in a browser. Each feature clearly explains how a user interacts with the UI and what outcome they see. The chosen frontend style (thin or thick client) is applied consistently, without mixing approaches. Feature scopes are realistic and independently implementable, with clear boundaries and observable completion criteria.
System is working
Minimum Viable Product (MVP)
By the end of this task, your team demonstrates a working web frontend running in a common browser (e.g. Chrome). The demo must show at least one frontend feature working end-to-end, including user interaction and visible UI updates, without crashes. The system must be runnable by the tutor using the instructions in README.md.
Technical Details
The demo must be performed in a real browser, not screenshots or mockups.
Show at least one complete user flow:
- User action (click, input, navigation)
- Frontend logic execution
- UI update (new content, state change, or navigation)
If the frontend communicates with a backend, the interaction must be real (not mocked) for the demonstrated feature. The demo scenario must be repeatable and documented.
Quality
High-quality demos show a stable and understandable frontend application. UI interactions are smooth, predictable, and clearly explained. The demonstrated behavior matches the earlier feature definitions. Extra quality comes from basic robustness (e.g. handled invalid input) and clarity of the user flow, not from visual polish alone.
Bug fixing
Minimum Viable Product (MVP)
During development, your team must report and fix one reproducible frontend bug that occurs in the browser (e.g. broken interaction, incorrect UI state, rendering issue). The bug must be demonstrated visually. The same steps must reliably reproduce the problem before the fix and must no longer fail after the fix.
Technical Details
The bug report must include:
- Browser and environment used
- Steps to reproduce using concrete user actions
- Expected vs actual UI behavior
- Visual evidence (screenshots or short video)
The fix must be implemented after the bug is reported. After fixing, repeat the same user actions and show that the UI behaves correctly. If applicable, add a small regression check (manual checklist or automated test).
Quality
High-quality bug fixing shows a clear frontend bug lifecycle: observable failure, correct diagnosis, and verified resolution. The report focuses on what the user sees, not internal code structure. The fix addresses the root cause and does not introduce new UI issues elsewhere.