# ThinkNCollab Student Engineering & Project Management Handbook Official Technical Publication for CS/IT Students, Engineering Graduates & Hackathon Teams Domain: https://www.thinkncollab.com/project-management/students ## Table of Contents & Learning Modules ### Module 01: Career Scope: Why Project Management Matters for Engineering Students Why coding syntax alone is not enough in the AI era. Transitioning from junior programmer to APM, TPM, Tech Lead, and Founder. **Learning Objectives**: - Understand the changing landscape of software development in the generative AI era - Distinguish between individual contributor (IC) and managerial/leadership career tracks - Examine real market compensation, demand, and skill requirements for modern PM roles - Learn how understanding scope, architecture, and prioritization accelerates career velocity ### Module 02: Academic Projects vs. Production Engineering: Bridging the Reality Gap A 10-point side-by-side comparison between college coursework habits and professional cloud-native engineering standards. **Learning Objectives**: - Identify the 5 catastrophic traps of college coding projects - Understand why "it works on my laptop" is unacceptable in production environments - Transition from single-file monolithic scripts to decoupled, modular architecture - Adopt trunk-based Git workflows, automated test gates, and continuous delivery ### Module 03: The Final Year / Capstone Project Master Playbook (Semester-Long Success) A 4-phase agile blueprint to plan, build, test, and defend a semester-long capstone project with equitable team accountability. **Learning Objectives**: - Structure a 16-week engineering semester into 8 actionable, two-week sprints - Draft a professional Software Requirements Specification (SRS) and PRD - Solve the "one person works while three spectate" dilemma using RACI and WIP gates - Prepare live production demonstrations and academic viva defenses with zero failures ### Module 04: The 24-48 Hour Hackathon Survival Engine (From Ideation to Winning Demo) An hour-by-hour countdown protocol using Basecamp Shape Up appetite scoping, rapid scaffolding, and 3-minute pitch defense. **Learning Objectives**: - Size project appetite in Hour 0-2 to avoid running out of time in Hour 40 - Scaffold databases, mock endpoints, and CI/CD pipelines in the first 4 hours - Enforce strict feature freezes at Hour 36 to guarantee a polished user journey - Craft a winning 3-minute jury presentation structured around problem, solution, and metric impact ### Module 05: The Junior Engineer & Intern 90-Day Survival Protocol Navigating massive legacy codebases, the 15-Minute Rule for asking help, writing PRs seniors love, and standup etiquette. **Learning Objectives**: - Deconstruct a 100,000-line production repository without getting overwhelmed - Apply the 15-Minute Rule to avoid burning hours blocked while protecting senior engineers time - Write structured Pull Request descriptions using Given/When/Then acceptance criteria - Conduct daily standups focused on business outcomes and blockers rather than commit logs ### Module 06: Industry Jargon Decoded: Plain-English Dictionary for Freshers Clear definitions and academic analogies for Epics, Stories, Story Points vs Hours, Velocity, Tech Debt, Spikes, and SLAs. **Learning Objectives**: - Master the agile hierarchy: Theme -> Epic -> Story -> Task -> Subtask - Understand why estimation in relative Story Points outperforms raw hour guessing - Differentiate between Definition of Ready (DoR) and Definition of Done (DoD) - Grasp blameless post-mortems, SLAs, SLOs, and technical debt accumulation ### Module 07: Resume, GitHub Portfolio & Behavioral Interview Toolkit Presenting student repositories like senior engineers, the STAR framework, and model answers for delivery-focused interview questions. **Learning Objectives**: - Transform amateur GitHub repositories with architecture diagrams, CI badges, and live demo links - Master the STAR method (Situation, Task, Action, Result) for behavioral viva questions - Answer classic fresher delivery questions: resolving team conflict, handling missed deadlines, and scoping MVPs - Position capstone projects on technical resumes to stand out to engineering recruiters ### Module 08: Production Markdown Templates for Student Engineering Teams Ready-to-use production markdown templates for Capstone PRDs, Hackathon Pitches, PR Review Checklists, and Viva Defense sheets. **Learning Objectives**: - Download and customize the Student Capstone PRD template - Utilize the Hackathon Pitch and Scope Matrix template - Deploy the Student Git Pull Request and Code Review Checklist - Review the Viva and Final Demo Defense Sheet for faculty reviews --- ## Modern Career Pathways in Software Delivery ### Associate Product Manager (APM) - **Focus**: Product Strategy, User Discovery, Problem Scoping & Metrics - **Why Coding Knowledge Helps**: Engineers who understand code cannot be fooled by feasibility estimates and write vastly superior technical specifications. - **Entry Requirements**: B.Tech/BCA/MCA/B.S., strong analytical reasoning, empathy for user friction, basic SQL/data analysis, and project portfolio. - **Average Compensation**: INR 10-18 LPA (India entry) / USD $85,000-130,000 (US entry) - **Growth Ladder**: APM -> Product Manager -> Senior PM -> Group PM -> VP of Product -> Chief Product Officer (CPO) - **Core Responsibilities**: - Synthesizing customer feedback into structured user stories and acceptance criteria - Defining success metrics (North Star, activation rate, feature retention, churn) - Balancing engineering feasibility, design usability, and commercial viability - Managing product backlogs, prioritizing sprints via RICE scoring, and running beta launches ### Technical Project Manager (TPM) / Program Manager - **Focus**: Cross-Functional Execution, Architecture Alignment, Dependency Tracking & Delivery - **Why Coding Knowledge Helps**: TPMs must understand distributed system architecture, microservices, cloud deployments, and API integrations to foresee blockers. - **Entry Requirements**: Strong engineering background, system design familiarity, mastery of Agile/Scrum/Kanban, risk governance, and Gantt/dependency tooling. - **Average Compensation**: INR 12-22 LPA (India entry) / USD $95,000-145,000 (US entry) - **Growth Ladder**: Associate TPM -> Technical Program Manager -> Senior TPM -> Principal TPM -> Director of Technical Program Management - **Core Responsibilities**: - Mapping complex multi-team cross-dependencies and critical paths - Identifying architectural risks, infrastructure bottlenecks, and security vulnerabilities early - Maintaining release schedules, automated CI/CD gating, and cutover checklists - Running incident triage, blameless post-mortems, and executive delivery reporting ### Engineering Lead / Tech Lead - **Focus**: Code Quality, Technical Architecture, Velocity Optimization & Team Mentorship - **Why Coding Knowledge Helps**: Tech Leads are hands-on coders who also shoulder sprint planning, code review standards, and technical debt management. - **Entry Requirements**: 3-5 years software engineering experience, mastery of data structures, clean architecture, automated testing, and team leadership. - **Average Compensation**: INR 24-45 LPA (India) / USD $160,000-240,000 (US) - **Growth Ladder**: Software Engineer -> Senior Engineer -> Tech Lead -> Engineering Manager / Staff Engineer -> Director of Engineering -> VP / CTO - **Core Responsibilities**: - Deconstructing complex system specifications into bite-sized developer tickets - Enforcing Definition of Done, automated linting, test coverage, and security scanning - Mentoring junior developers and unblocking pairing sessions - Balancing business feature requests against refactoring and technical debt reduction ### Scrum Master / Agile Delivery Coach - **Focus**: Team Velocity, Process Hygiene, Flow Optimization & Blocker Demolition - **Why Coding Knowledge Helps**: A technical Scrum Master understands pipeline failures, local environment stalls, and merge conflicts far better than a non-technical coach. - **Entry Requirements**: CS/IT degree, Scrum Master certification (CSM/PSM I), deep empathy, queuing theory fundamentals, and sprint ceremony leadership. - **Average Compensation**: INR 9-16 LPA (India entry) / USD $75,000-115,000 (US entry) - **Growth Ladder**: Scrum Master -> Senior Scrum Master -> Agile Coach -> Enterprise Delivery Coach -> VP of Agile Transformation - **Core Responsibilities**: - Facilitating Sprint Planning, Daily Standups, Sprint Demos, and Retrospectives - Protecting the engineering team from mid-sprint stakeholder interruptions and scope creep - Tracking team metrics: cycle time, lead time, burndown curves, and WIP violations - Coaching teams on continuous improvement and eliminating workflow friction ### Student Founder / Indie Hacker / Startup CTO - **Focus**: Rapid MVP Scoping, Zero-to-One Architecture, Capital Efficiency & Continuous Shipping - **Why Coding Knowledge Helps**: Founders who manage projects empirically ship working products in weeks instead of spending months building features nobody wants. - **Entry Requirements**: High agency, full-stack prototyping speed, extreme user focus, willingness to talk to customers, and disciplined sprint focus. - **Average Compensation**: Variable equity + high upside; early grants and venture funding - **Growth Ladder**: Student Hacker -> Solopreneur / Co-Founder -> Seed Stage CTO -> Growth Stage Executive - **Core Responsibilities**: - Ruthlessly cutting feature scope to launch a functional MVP within 2 to 4 weeks - Deploying telemetry and user behavior tracking on day one - Iterating on customer feedback through rapid weekly release cycles - Setting up foundational collaboration infrastructure, task tracking, and CI/CD pipelines --- ## Academic Projects vs Production Engineering: 10-Point Reality Bridge ### Code Organization - **Academic Approach**: Single monolithic file (main.py / app.js with 2,000+ lines), messy global variables, logic combined with UI. - **Industry Production Standard**: Decoupled layered architecture (controllers, services, repositories, schemas, models) with strict single-responsibility principles. - **Why It Matters**: Monoliths break immediately when multiple engineers attempt to write code simultaneously; modular code enables parallel collaboration. ### Version Control (Git) - **Academic Approach**: Direct commits to "main" branch, commit messages like "update", "fixed bug", "done", zero branch protection. - **Industry Production Standard**: Trunk-based development, feature branches (feat/user-auth), signed commits, descriptive commit messages, and protected main branches. - **Why It Matters**: Unregulated commits cause silent overwrites, broken builds, and untraceable regressions in team environments. ### Code Reviews - **Academic Approach**: Zero peer review. Everyone writes in isolation; code is merged blindly hours before project presentation. - **Industry Production Standard**: Mandatory Pull Request (PR) reviews with at least one senior approval, automated CI test gates, and static security analysis. - **Why It Matters**: Peer review catches architectural flaws, memory leaks, and logic errors before they cause customer outages. ### Testing & Verification - **Academic Approach**: Manual "eyeball testing": clicking two buttons in the browser once; if it does not crash, it is assumed complete. - **Industry Production Standard**: Automated test pyramids: unit tests (Jest/Mocha), integration tests (Supertest), and end-to-end browser tests (Playwright/Cypress). - **Why It Matters**: Manual verification fails to detect regressions when new features alter existing database relationships or API payloads. ### Configuration & Secrets - **Academic Approach**: Hardcoded database credentials, API keys, and JWT secrets committed directly into public GitHub repositories. - **Industry Production Standard**: Strict environment variables (.env), secrets managers (HashiCorp Vault, AWS Secrets Manager), and automated git pre-commit scanning. - **Why It Matters**: Leaked credentials lead to unauthorized database drops, compromised cloud instances, and expensive API usage bills. ### Requirements Definition - **Academic Approach**: Vague paragraph in an assignment prompt: "Build an online library portal with user login and book checkout." - **Industry Production Standard**: Product Requirements Documents (PRDs) with executable Given/When/Then acceptance criteria, edge cases, and API specs. - **Why It Matters**: Vague requirements lead to building the wrong product, scope creep, and bitter disagreements during final evaluation. ### Team Task Allocation - **Academic Approach**: One heroic student codes everything at 3 AM while three teammates prepare slides or do nothing; resentment ensues. - **Industry Production Standard**: Transparent Kanban boards with visible WIP limits, story point estimation, daily async standups, and shared sprint goals. - **Why It Matters**: Single-developer heroics do not scale in production companies; squads succeed or fail together through transparent accountability. ### Deployment & Hosting - **Academic Approach**: Runs only on localhost:3000 on a single laptop; fails to boot on the evaluator machine due to missing local libraries. - **Industry Production Standard**: Docker containerization, reproducible builds, automated CI/CD deployment to staging and production cloud infrastructure. - **Why It Matters**: Software has zero business value if customers or evaluators cannot access it reliably across devices and operating systems. ### Error Handling & Logs - **Academic Approach**: console.log("here") and blank catch blocks: catch(e) {} that swallow critical errors silently. - **Industry Production Standard**: Structured JSON logging (Winston/Pino), error boundaries, centralized monitoring (Sentry), and alerting metrics. - **Why It Matters**: Silent error swallowing masks production database corruption and makes debugging impossible in live environments. ### Post-Project Lifecycle - **Academic Approach**: Project is completely abandoned 5 minutes after the final viva exam; code is never touched or refactored again. - **Industry Production Standard**: Continuous delivery, customer telemetry analysis, performance monitoring, blameless post-mortems, and technical debt refactoring. - **Why It Matters**: Real software starts its true lifecycle on the day of deployment; maintenance and operational reliability represent 80% of engineering cost. --- ## Semester-Long Capstone Project Playbook (4-Phase Lifecycle) ### Phase 1 (Weeks 1-4): Discovery, Problem Validation & The Capstone PRD - **Deliverables**: Problem Statement Validation, User Personas & User Journeys, Product Requirements Document (PRD), Tech Stack Evaluation Matrix - **Milestone Gate**: Sign-off from project advisor/mentor on PRD and system boundaries. Out of scope items explicitly listed as No-Gos. - **Common Pitfall**: Starting to write code on Day 1 without agreeing on database schemas or user journeys. ### Phase 2 (Weeks 5-8): Architecture Blueprint, Schema Contracts & Core Spike - **Deliverables**: System Architecture Diagram, Normalized Database Schema (ERD), OpenAPI / Swagger Endpoint Specification, High-Risk Technical Spike (Proof of Concept) - **Milestone Gate**: Working "Walking Skeleton": a containerized micro-app that successfully executes a database write, read, and basic authenticated API call. - **Common Pitfall**: Polishing CSS animations and button shadows while the core database schema remains unverified. ### Phase 3 (Weeks 9-13): Agile Sprint Execution & Bi-Weekly Increments - **Deliverables**: Two-Week Sprint Iterations, Transparent Kanban Board Tracking, Automated Unit & Integration Test Suites, Weekly Working Software Demos - **Milestone Gate**: Feature complete baseline achieved by Week 12. Strict feature freeze declared at Week 13 for bug fixing and stress testing. - **Common Pitfall**: Attempting to add new feature ideas in Week 13 instead of polishing and hardening the existing baseline. ### Phase 4 (Weeks 14-16): Production Hardening, Cloud Deployment & Viva Defense - **Deliverables**: Live Cloud Deployment with Custom Domain, Automated Health Check & Monitoring Dashboard, Exhaustive Project Documentation / Report, 3-Minute Demo Video & Interactive Slide Deck - **Milestone Gate**: Successful rehearsal of the live presentation. Evaluators are provided live staging links and test user credentials with pre-seeded data. - **Common Pitfall**: Relying entirely on a live local server during the presentation without having an offline backup video recorded. --- ## 24-48 Hour Hackathon Survival Engine ### Hour 00 - 02: Appetite Sizing & The Shape Up Pitch **Objective**: Decide what NOT to build. Define the singular core value hypothesis. **Action Checklist**: - Formulate the one-sentence problem statement and target beneficiary - List 3 core user flows and explicitly mark everything else as "Out of Scope / No-Go" - Select known technologies: do not experiment with an unfamiliar language during a 24-hour hackathon - Agree on the 3-minute final demo scenario before writing any code *Golden Rule*: If a feature cannot be demoed in 20 seconds to a judge, cut it from the hackathon backlog immediately. ### Hour 02 - 06: Foundation Scaffolding & API Contract Signing **Objective**: Establish the project backbone and parallelize team execution. **Action Checklist**: - Initialize Git repository with protected branch and invite all team members - Scaffold backend server with database connection and pre-seeded mock datasets - Document mock API endpoints and JSON response formats so frontend developers can build without waiting for backend logic - Setup shared environment variables and deploy a blank staging link to verify hosting early *Golden Rule*: Frontend and backend must never block each other. Define API contracts in a shared document on Hour 3. ### Hour 06 - 30: The Core Engine Sprint (WIP Limit = 1) **Objective**: Build the primary differentiating feature with relentless focus. **Action Checklist**: - Enforce Work-In-Progress (WIP) limit: each teammate works on exactly one card at a time - Conduct a 5-minute sync every 4 hours to check dependencies and merge working branches - If an engineer gets blocked for more than 20 minutes, initiate immediate pair programming - Build end-to-end functionality for the golden path first; edge cases can be handled later *Golden Rule*: A half-finished complex feature scores zero points. A finished, working, simple feature wins competitions. ### Hour 30 - 40: Feature Freeze & User Journey Hardening **Objective**: Stop adding features. Polish UI, verify data flows, and eliminate crashes. **Action Checklist**: - Declare strict Feature Freeze: zero new feature commits permitted - Test the application from start to finish on a clean browser in incognito mode - Pre-seed high-quality demo data (avoid test strings like "asdasd" or "test1234") - Deploy final build to public URL and verify SSL certificate and response latencies *Golden Rule*: Judges judge what they see, not what is written in your commit history. Polish beats complexity. ### Hour 40 - 48: Demo Video Recording & Pitch Defense Crafting **Objective**: Win the evaluation in the first 60 seconds of presentation. **Action Checklist**: - Record a 90-second screen capture walkthrough as insurance against venue WiFi failure - Structure the 3-minute pitch: Hook (30s) -> The Live Demo (90s) -> Architecture & Scalability (30s) -> Impact (30s) - Prepare for judge technical questions: database schema, security safeguards, and cost at scale - Test presentation slides on the projector display to verify contrast and readability *Golden Rule*: Never run a live demo over unpredictable venue WiFi without a locally cached backup or recorded video. --- ## Production Student Templates ### Student Capstone PRD (Product Requirements Document) (Academic Capstone) A complete, industry-standard Product Requirements Document tailored for engineering capstone projects, academic reviews, and accreditation portfolios. ```markdown # [Project Title] - Product Requirements Document (PRD) ## 1. Project Metadata - **Project Name**: [e.g., CampusSync - Distributed Lab Reservation System] - **Team Members**: [Member 1 (Lead), Member 2 (Backend), Member 3 (Frontend), Member 4 (DevOps/QA)] - **Faculty Advisor / Mentor**: [Name & Designation] - **Academic Term**: [e.g., Fall 2026 / Semester VIII] - **Target Completion Date**: [Date] - **Live Staging URL**: [https://staging.project.domain] --- ## 2. Problem Statement & Background ### 2.1 The Core Problem Describe the specific, validated problem your project solves. Avoid generic statements. Include who suffers from the problem and the current manual workarounds. ### 2.2 The Proposed Solution Explain your proposed technical solution in 2-3 sentences. Focus on how it changes the existing user workflow. --- ## 3. Scope Boundaries (Appetite & Out-of-Scope) ### 3.1 In-Scope (Must Have for Final Viva) 1. **Core Feature 1**: [Description + testable outcome] 2. **Core Feature 2**: [Description + testable outcome] 3. **Core Feature 3**: [Description + testable outcome] ### 3.2 Explicitly Out-of-Scope (No-Gos) - Mobile native apps (responsive web only) - Cryptocurrency / complex third-party billing - AI recommendation engines before basic search is operational --- ## 4. User Personas & User Journeys ### Persona A: [e.g., Student Researcher] - **Goal**: Reserve high-performance GPU cluster for 4 hours. - **Pain Point**: Manual paper slips, uncertain availability, wasted trips to the department lab. - **Golden Flow**: Login -> View Real-Time Lab Availability Grid -> Select Time Slot -> Receive QR Pass. --- ## 5. Technical Specifications & Architecture - **Frontend Stack**: [e.g., React.js / Vite / Tailwind CSS] - **Backend Stack**: [e.g., Node.js / Express / Clean Architecture] - **Database Engine**: [e.g., PostgreSQL / MongoDB with Prisma ORM] - **Authentication**: [e.g., JWT with HTTP-only Secure Cookies + RBAC] - **Hosting & Infrastructure**: [e.g., Render / Docker Container / AWS EC2] --- ## 6. Functional Acceptance Criteria (Gherkin Format) ```gherkin Feature: Lab Slot Reservation Scenario: Successful slot reservation within capacity Given an authenticated student with active academic standing When they select an available 2-hour slot on GPU-Node-01 And they confirm the booking Then the system reserves the slot with status "CONFIRMED" And decreases available room capacity by 1 And sends an automated confirmation email with access token Scenario: Conflict prevention on concurrent booking Given two students attempt to book the identical slot simultaneously When student B submits request 10ms after student A Then student A receives "BOOKING_CONFIRMED" And student B receives "SLOT_CONFLICT_ALREADY_RESERVED" And database transaction rolls back cleanly without data corruption ``` --- ## 7. Milestone Timeline & Sprint Roadmap | Sprint | Weeks | Primary Goal | Deliverable & Viva Evidence | | :--- | :--- | :--- | :--- | | **Sprint 1** | Week 1-2 | Architecture & Schema | ERD, API specs, Walking Skeleton deployed | | **Sprint 2** | Week 3-4 | Authentication & Roles | Multi-tenant auth, role-based access control | | **Sprint 3** | Week 5-6 | Core Business Logic | Slot reservation engine with concurrency locks | | **Sprint 4** | Week 7-8 | Real-Time Sync | WebSockets live grid updates across connected users | | **Sprint 5** | Week 9-10 | Admin & Telemetry | Admin approval dashboard, PDF export reports | | **Sprint 6** | Week 11-12 | Testing & Hardening | 80%+ test coverage, vulnerability audit, feature freeze | | **Sprint 7** | Week 13-14 | Cloud Deployment | Production deploy, SSL, load testing verification | | **Sprint 8** | Week 15-16 | Defense Rehearsal | Project report, demo video, final viva presentation | ``` ### Hackathon Pitch & Scope Matrix (Rapid Prototyping) A battle-tested pitch canvas and scoping matrix to select, build, and pitch a hackathon project in 24 to 48 hours. ```markdown # Hackathon Sprint Canvas & Jury Pitch Deck ## 1. Hackathon Profile - **Hackathon Name**: [e.g., Global DevSprint 2026] - **Track / Theme**: [e.g., Developer Tooling / Open Source Productivity] - **Team Name**: [e.g., Team KernelPanic] - **Live Demo Link**: [https://hackathon-demo.domain] - **GitHub Repository**: [https://github.com/org/repo] --- ## 2. The 30-Second Elevator Pitch > **For** [target user] > **Who** [has this urgent bottleneck] > **Our Project** is an [application category] > **That** [delivers this immediate, measurable benefit] > **Unlike** [existing inefficient alternative] > **Our solution** [provides this unique technical differentiator]. --- ## 3. The 24-Hour Scope Matrix (What We Built vs What We Skipped) | Feature Area | Hackathon Working Implementation | Skipped / Post-Hackathon Future Work | | :--- | :--- | :--- | | **Authentication** | One-click GitHub OAuth with pre-configured demo account | Multi-provider OAuth, password reset, 2FA | | **Database** | Lightweight PostgreSQL with 5 core tables & pre-seeded data | Complex sharding, multi-region replication | | **User Interface** | Polished desktop dashboard optimized for presentation screen | Complex responsive mobile layouts, themes | | **Core Engine** | Real-time WebSocket terminal stream with sub-100ms latency | Full historical playback archive | | **Payments** | Simulated sandbox checkout webhook | Production Stripe gateway integration | --- ## 4. The 3-Minute Presentation Script (Jury Defense) - **0:00 - 0:30 (The Hook & Problem)**: Share an relatable personal developer pain point. Present one shocking metric (e.g., "Developers waste 4.2 hours every week context-switching between 8 tabs"). - **0:30 - 2:00 (The Live Demo)**: Open the browser. Perform the golden action live. Show the end-to-end outcome in real-time. Show the receiver seeing the result. - **2:00 - 2:35 (Architecture & Innovation)**: Display one clean architecture diagram. Explain why your technical choice (e.g., WebSockets, WebRTC SFU, distributed queues) solves the scaling bottleneck. - **2:35 - 3:00 (Business Impact & Next Steps)**: Summarize cost efficiency, target user acquisition strategy, and thank the jury. ``` ### Student Pull Request & Code Review Checklist (Engineering Standards) Standard operating procedure for student development squads to submit, review, and merge code without breaking main branches. ```markdown # Student Pull Request (PR) Standard Operating Checklist ## PR Title Format: `type(scope): concise description of change` *Examples*: - `feat(auth): implement JWT refresh token rotation` - `fix(database): add unique constraint on student roll number` - `test(reservation): add concurrency integration tests for slot booking` --- ## Pull Request Template Body ```markdown ### 1. Summary of Changes - Implemented [feature name] to resolve issue #[ticket-id]. - Decoupled [module A] from [module B] to prevent circular dependency. - Added input validation schema using Joi / Zod. ### 2. Motivation & Context Why is this change necessary? What user problem does it solve? ### 3. Acceptance Verification (Given / When / Then) - [x] Given valid credentials, when user submits login form, then JWT token is issued in HTTP-only cookie. - [x] Given expired token, when user requests protected resource, then API returns 401 Unauthorized. - [x] Given malformed JSON payload, then API returns 400 Bad Request with field-level validation errors. ### 4. Code Quality Self-Check - [x] No hardcoded secrets, database passwords, or private keys in code. - [x] No commented-out dead code or uninformative console.log statements. - [x] All new functions have descriptive names and single responsibility. - [x] Unit/integration tests added and passing locally (`npm test`). ### 5. Visual Proof (UI Changes Only) Attach screenshot or GIF showing working feature in both Light and Dark mode. ``` --- ## Reviewer Acceptance Criteria Before approving this Pull Request, the peer reviewer must confirm: 1. Does this branch build cleanly without warnings or errors? 2. Are edge cases (null values, network dropouts, duplicate submissions) handled? 3. Is database query efficiency verified (no N+1 query loops)? 4. Has at least one team member approved this PR before merging into `main`? ``` ### Academic Viva & Technical Defense Cheat Sheet (Academic Defense) Comprehensive preparation framework for defending software architecture, database design, and project management decisions in front of academic examiners. ```markdown # Academic Viva & Technical Defense Cheat Sheet ## 1. Top 5 Questions Examiners Ask & How to Answer Them ### Question 1: "Why did you choose this tech stack instead of [Alternative X]?" - **Weak Answer**: "Because we found a YouTube tutorial on it" or "Because React is popular." - **Professional Answer**: "We evaluated [Our Stack] against [Alternative X] across three criteria: latency requirements, ecosystem library support for our specific feature set, and development velocity within our 16-week timeline. For example, our choice of PostgreSQL over MongoDB was driven by our relational data model requiring strict ACID transactions during simultaneous slot reservations to prevent double-booking." --- ### Question 2: "What is the biggest technical challenge your team faced and how did you resolve it?" - **Answer Structure (STAR Framework)**: - **Situation**: Explain the specific roadblock (e.g., race condition under concurrent requests). - **Task**: Identify what needed to be achieved (e.g., guarantee zero duplicate allocations). - **Action**: Detail your technical intervention (e.g., introduced database row-level locking with `SELECT ... FOR UPDATE` within a transaction block). - **Result**: Quantify the outcome (e.g., tested with Artillery load tester at 500 concurrent requests; zero data anomalies recorded). --- ### Question 3: "How did your team split the work and ensure everyone contributed?" - **Answer Structure**: - Show your ThinkNCollab / Kanban board. - Explain your story point estimation process and Definition of Done. - Highlight git commit logs and pull request reviews demonstrating that each member owned distinct modules with peer review oversight. --- ### Question 4: "If this application scaled to 100,000 daily active users tomorrow, where would it break first?" - **Professional Answer**: Identify your architectural bottleneck candidly: - "Our primary bottleneck would be the single-instance database connection pool during peak hours. To scale, we would first introduce Redis caching for read-heavy room availability queries (reducing database load by ~70%), followed by horizontal scaling of the stateless Node.js application containers behind a cloud load balancer." --- ### Question 5: "What would you do differently if you had to start this project over again?" - **Professional Answer**: - "We would define our OpenAPI contracts on Day 1 rather than Day 14. Initially, frontend and backend teams experienced integration friction because of minor payload discrepancies. Adopting contract-first development would have saved us approximately two weeks of refactoring." --- ## 2. Emergency Backup Checklist for Live Presentation Day - [ ] Staging URL active and pre-warmed on cloud hosting. - [ ] Offline backup video (1080p, 60fps) saved locally on laptop desktop. - [ ] Mobile hotspot fully charged and tested in case campus WiFi disconnects. - [ ] Pre-seeded demo user accounts with memorable credentials (e.g., student@demo.com / Demo123!). - [ ] Printed A4 copies of Architecture Diagram, ERD, and PRD ready for examiners. ```