Building Student Job Eligibility in My Placement Portal with Django and Next.js

As the Placement Portal grows, I’m reaching the stage where individual modules need to work together instead of existing in isolation.

Today's work focused on connecting the frontend and backend to create the first complete student workflow—from logging in to viewing eligible jobs and preparing to apply.

Protecting Dashboard Routes

The first improvement was on the frontend.

A dashboard should never be accessible unless a user is authenticated.

To enforce this, I implemented Next.js Middleware.

Whenever a request is made to a route beginning with /dashboard, the middleware checks whether the required authentication cookies are present.

If either the Access Token or Refresh Token is missing, the user is redirected to the login page.

This ensures that dashboard pages remain protected without requiring authentication checks inside every individual page.

Building the Dashboard Layout

With route protection in place, I started building the dashboard itself.

The first version includes:

• A fixed sidebar
• User avatar
• Profile information
• Navigation menu

Although simple, this establishes a consistent layout that future dashboard features can build upon.

Connecting Students to Jobs

The backend work focused on defining which jobs a student should actually be able to see.

Every job posting now belongs to one or more academic batches.

Likewise, every student belongs to a specific batch.

Instead of showing every published job to every student, the portal compares these relationships.

If:

Student.batch == Job.batch

the job becomes visible.

Otherwise, it remains hidden.

This creates a simple yet effective eligibility system for campus recruitment.

Refining the Student Model

I also refined the user creation workflow.

When a new account is created, the system now automatically creates the corresponding profile based on the user's role.

For example:

• Student users receive a Student profile.
• Company users receive a Company profile.

This keeps authentication separate from business-specific data while simplifying the onboarding process.

Introducing the Application Model

Another important milestone was creating the Application model.

This model connects:

• Student
• Job
• Application Status

For the MVP, I defined three application states:

• Applied
• Rejected
• Placed

Whenever the application status changes, the record's update timestamp changes automatically, making it easier to track the recruitment lifecycle.

Why This Matters

Today's work wasn't about adding flashy features.

It was about connecting multiple parts of the system into a meaningful workflow.

A student can now:

1. Log in securely.
2. Access only protected dashboard pages.
3. View only the jobs they are eligible for.
4. Prepare to submit job applications.

Each of these small decisions contributes to a more secure and maintainable placement management system.

What's Next?

With the application model now in place, the next milestone is implementing the complete application flow:

• Resume upload
• Applying to jobs
• Preventing duplicate applications
• Company-side applicant management

This will complete the first end-to-end recruitment workflow in the Placement Portal.

As always, I'm documenting every architectural decision while building this project in public.