Placement Cell Portal for an Arts and Science College (MERN)

PlaceDesk is a web application that runs the daily work of the placement cell of a Chennai arts and science college — a cell that this season will register 40+ companies, run 25–30 recruitment drives and answer the same three questions all year: who is eligible, which round is pending, and what did we place last month. Today those answers live in Excel sheets emailed between the placement officer and department coordinators, with eligibility checked by eye and results pasted into group chats.

The portal has three roles. The placement officer registers companies, creates drives with an explicit eligibility rule set (minimum CGPA, maximum standing arrears, history-of-arrears policy, allowed departments and graduation year) and enters round results. The department coordinator verifies student records — semester-wise CGPA and arrears history — for their department. Students complete their profile, upload a resume, see explainable eligibility (each drive shows why they qualify or the exact rule they miss), apply within the drive window, and track round-by-round progress from Aptitude through Technical and HR interviews to the offer.

Two rules give the system its teeth: placed students are locked from further applications (with an officer-controlled upgrade path for offers above a configurable CTC threshold), and one application per student per drive is enforced by a database index, not by the UI. Built with React, Node.js/Express and MongoDB — the full stack of MC4201 with the document-modelling practice of MC4202 — it is a workflow-rich, viva-defensible Anna University MCA R2021 Semester-4 project.

College placement cells coordinate companies, eligibility rules, applications and multi-round results across hundreds of students using spreadsheets, notices and messaging groups. The parts are interdependent but the tools are not: eligibility is checked by eye against stale sheets, applications arrive after deadlines and in duplicate, round results are relayed by phone, and an accepted offer does not reliably stop further applications — leading to eligibility mistakes at interview venues, disputes about who applied in time, students sitting for drives after placement, and no trustworthy analytics for the college. There is a need for a role-based web portal that keeps verified academic profiles, publishes each drive with an explicit rule set, evaluates and explains eligibility per student, enforces application windows and one-application-per-drive, tracks rounds and offers, locks placed students under a written upgrade policy, and produces department- and company-level placement reports — while storing no Aadhaar, PAN or other government identity numbers.

Abstract

This project delivers a workflow-driven web portal for a college placement cell: verified student academic profiles, company and drive management with explicit eligibility rules, an explainable eligibility engine, deadline-bound applications, round-by-round result tracking, offer records with a placed-student lock, and placement analytics with CSV exports. The stack is React, Node.js/Express and MongoDB behind Mongoose, with JWT-based role control.

Introduction

An arts and science college's placement season is a data-intensive operation compressed into a few months. The placement officer juggles company visits, the coordinators maintain department student lists, and students hear about drives through notices and word of mouth. Every drive has its own eligibility fine print; every round eliminates students; every offer changes who may still apply. Spreadsheets and chat fail precisely because these facts are interdependent — an eligibility mistake surfaces at the interview venue, at the college's reputational cost.

Existing System and Its Limitations

• Student academic data (CGPA per semester, arrears) sits in separate Excel sheets per department, updated irregularly and unverified.
• Drive announcements go out as posters and group messages; eligibility is checked manually from the sheets.
• Applications are collected via forms or WhatsApp; duplicates and after-deadline entries are common.
• Round results live in the officer's notebook; students learn outcomes by phone.
• Limitations: no single source of truth, no audit trail, no explainable rejection, no analytics beyond year-end totals.

Proposed System

• Verified profiles: coordinators approve each student's semester-wise CGPA, arrears history and resume; eligibility depends only on verified data.
• Drives with rule sets: the officer configures minimum aggregate CGPA, maximum standing arrears, whether a history of arrears disqualifies, allowed departments and graduation years, and the application window.
• Explainable eligibility: the engine evaluates each student and returns a verdict with per-rule reasons, shown to the student before they apply — no silent rejections.
• Enforced windows: one application per student per drive, enforced by a unique index, with the deadline checked server-side.
• Round tracking: each drive defines ordered rounds; the officer records outcomes and shortlists advance automatically.
• Offers and the placed lock: an accepted offer marks the student Placed and blocks further applications; the officer may unlock for drives whose CTC exceeds the configured upgrade threshold.
• Analytics: department-wise placement percentage, median and highest CTC, company-wise selections and unplaced-student lists, all exportable as CSV.

Feasibility Study

• Technical: The MERN stack is taught end to end in MC4201; MongoDB models nested eligibility rules and round histories naturally, and unique indexes enforce the one-application and one-offer constraints. The portal runs on Node 20 and MongoDB 7 on a college desktop or a low-tier host, and resumes are stored as size-limited uploads.
• Economic: No licence cost; the college already owns the hardware. Against the coordination hours it saves across two semesters, the return is immediate.
• Operational: The officer's screens mirror the Excel workflow column for column; coordinators need a one-hour walkthrough, and a semester's data seeds the demo in minutes.

In scope

• One college, its departments, three roles, one placement season (~60 seeded students, 12 companies, 8 drives).
• Profile verification workflow, eligibility rule sets, applications, ordered rounds, offers, placed lock with upgrade path.
• Resume upload (PDF, size-limited), in-app notifications of results, CSV exports of all key reports.

Out of scope (v1)

• Company-side logins (companies are registered and updated by the officer; a company portal is future work).
• Online tests for aptitude/technical rounds (results are entered, not conducted).
• Interview scheduling and hall allocation; email/SMS gateways (notifications are in-app in v1).
• Multi-college (multi-tenant) deployment and government-category filters, which are deliberately excluded on fairness grounds.

The project follows an iterative and incremental SDLC with fortnightly demos to the guide — appropriate because the eligibility and lock rules are policy decisions that get refined once the coordinator and officer roles see them working.

Testing approach: Jest unit tests for the eligibility engine (every rule, boundary CGPAs, arrears combinations) and the CTC median calculation; Supertest integration tests for the API, including apply-after-deadline, duplicate applications, placed-lock attempts and role abuse; manual black-box test cases per screen; and a UAT session walking a seeded student from profile verification to offer.

The portal is a three-tier MERN application with a stateless REST API and all policy rules server-side.

1. Presentation tier: a React SPA (Vite build, Tailwind CSS) with role-aware routing — the officer's drive console, the coordinator's verification queue and the student's drive list render from the same API; forms validate with shared schemas before submission.
2. Application tier: Node.js/Express routes pass through JWT verification and role middleware into controllers and services; the eligibility engine, deadline checks, round advancement and the placed lock are services, so no client can bypass them.
3. Data tier: MongoDB via Mongoose with validated schemas; unique indexes on (drive, student) for applications and on the active offer per student; Multer stores size-limited PDF resumes outside the web root; ExcelJS/CSV streams produce the reports.

flowchart LR
  S["Student browser"] -->|"HTTPS + JWT"| API["Express REST API"]
  O["Placement officer browser"] --> API
  CO["Coordinator browser"] --> API
  API --> MW["JWT verify + role middleware"]
  MW --> SVC["Services: eligibility engine, windows, rounds, lock"]
  SVC --> DB[("MongoDB via Mongoose")]
  SVC --> UP["Multer resume store (PDF)"]
  SVC --> RPT["CSV report exports"]

Data model

erDiagram
  USER ||--|| STUDENT : "has profile"
  USER ||--o{ VERIFICATION : "performs"
  COMPANY ||--o{ DRIVE : offers
  DRIVE ||--o{ APPLICATION : receives
  STUDENT ||--o{ APPLICATION : submits
  DRIVE ||--o{ ROUND : "defines"
  APPLICATION ||--o{ ROUND_RESULT : "records"
  APPLICATION ||--o| OFFER : "ends in"
  STUDENT ||--o| OFFER : holds

  USER {
    string id PK
    string email UK
    string passwordHash
    string role
  }
  STUDENT {
    string id PK
    string userId FK
    string registerNo UK
    string department
    int graduationYear
    boolean verified
    decimal aggregateCgpa
    int standingArrears
    boolean arrearsHistory
    string resumePath
    string placementStatus
  }
  COMPANY {
    string id PK
    string name
    string industry
    string hrContact
  }
  DRIVE {
    string id PK
    string companyId FK
    string role
    decimal ctcLpa
    object eligibilityRules
    date windowOpens
    date windowCloses
  }
  APPLICATION {
    string id PK
    string driveId FK
    string studentId FK
    string currentRound
    string status
  }
  ROUND {
    string id PK
    string driveId FK
    int sequence
    string name
  }
  OFFER {
    string id PK
    string applicationId FK
    decimal ctcLpa
    string status
  }

Application and round flow

flowchart LR
  AP["Applied"] --> R1["Round 1: Aptitude"]
  R1 -->|"cleared"| R2["Round 2: Technical"]
  R2 -->|"cleared"| R3["Round 3: HR"]
  R1 -->|"eliminated"| EL["Eliminated"]
  R2 --> EL
  R3 -->|"cleared"| OF["Offer made"]
  OF --> ACC["Offer accepted: student locked"]
  OF --> DEC["Offer declined"]

The student record deliberately carries register number, department and academic history only — no Aadhaar, PAN or category data — a privacy stance stated in the report and defended in the viva.

• Company self-service portal with job descriptions, shortlist downloads and offer uploads.
• In-app aptitude/technical round conduction with auto-scoring and instant shortlisting.
• Email/WhatsApp notifications for drive announcements, results and offer letters, with digital acknowledgement.
• Placement forecasting — drive-to-selection conversion per department to plan pre-placement training.
• Alumni referral network and multi-year analytics with NIRF/AICTE-format report exports.