Abhishek Roka
Abhishek Roka

Designing a Dynamic Job Application System for My Placement Portal

One of the biggest lessons from my stakeholder meeting was surprisingly simple:

Every user sees the same product differently.

When I initially started thinking about the administrative side of my Placement Portal, I imagined that university staff could work from the same dashboard.

It seemed simpler.

One dashboard.

One interface.

One set of features.

But after understanding how different stakeholders actually work, I realized that this approach would create a problem.

Different users have different responsibilities.

And if their responsibilities are different, their interfaces should probably be different too.

Two Roles, Two Different Workflows

The first major design decision I'm moving toward is separating university staff into two distinct experiences.

The Head of Department

The HoD has a broader responsibility around student management.

They may need visibility into complete student records and other administrative information.

Their dashboard therefore needs to provide a broader view of the student population.

The HoD's primary concern isn't necessarily managing individual recruitment drives.

It's having visibility and control over the larger academic and administrative picture.

The Placement Officer

The Placement Officer has a much more focused responsibility.

Their job is:

Placement. Placement. Placement.

They need tools that help them:

They don't necessarily need every piece of academic information stored by the university.

Showing irrelevant information doesn't make a dashboard more powerful.

It can make it harder to use.

The Principle: Show Users What They Need

This led me to a principle I'm now trying to follow throughout the project:

Don't give every user access to everything just because the system has the data.

Instead:

Give each user the information and tools required to complete their job.

This isn't only an access-control decision.

It's a user-experience decision.

A simpler interface can make a complex system feel much easier to use.

Stop Asking Students for the Same Information

The same thinking applies to students.

Companies frequently ask for information such as:

If this information already exists in the student's profile, why should the student enter it again for every application?

They shouldn't.

Instead, common information can live inside the student's profile.

The profile can contain information such as:

Then, when the student applies for a job, the system can use the information it already has.

This removes unnecessary repetition from the application process.

But Every Company Is Different

There's another side to the problem.

While some information is common across applications, companies often have their own requirements.

One company might only care about CGPA.

Another might ask for:

A fixed application form can't handle this efficiently.

That's why I'm designing the application form to be dynamic.

The Placement Officer Becomes the Form Builder

Instead of creating a new form every time the requirements change, the Placement Officer will configure the application form while creating the job posting.

The form will have two major sources of fields.

Predefined Fields

These are fields that already exist in the student's profile.

For example:

The Placement Officer can select which of these fields should appear for a particular job.

The student doesn't need to enter the information again.

Custom Questions

Then there are company-specific requirements.

The Placement Officer can create custom questions such as:

This gives each job its own application form without requiring developers to modify the code for every recruitment drive.

The Job Defines Its Own Application Experience

This changes the relationship between a job and an application.

Instead of having one global application form, each job can define its own requirements.

Conceptually:

Job
 │
 ├── Predefined Fields
 │     ├── CGPA
 │     ├── 12th Percentage
 │     └── Backlogs
 │
 └── Custom Questions
       ├── Portfolio URL
       ├── Preferred Location
       └── Company-specific Question

When a student applies, the frontend can render the form defined for that particular job.

This gives the Placement Officer flexibility without requiring constant backend changes.

Eligibility Should Also Be Configurable

The application form isn't the only thing that varies between companies.

Eligibility requirements vary too.

Initially, I was thinking about job visibility largely around student batches.

But real recruitment requirements can be more specific.

A company might require:

So the Placement Officer should be able to define these criteria while creating the job.

The system can then use those criteria to determine which students should be able to see or apply for the opportunity.

The goal is straightforward:

Students shouldn't have to spend time applying for jobs they aren't eligible for.

Applications Should Become a Recruitment Workspace

Once students start applying, the Placement Officer needs more than a basic application list.

The dashboard should help answer questions such as:

Instead of displaying the same fixed columns for every job, the application table can reflect the fields configured for that particular job.

For example:

Student | CGPA | Backlogs | Portfolio | Status

Another job could have:

Student | 12th % | Passing Year | Relocation | Status

The interface adapts to the recruitment requirement.

That's the real value of a dynamic application system.

The Architecture Follows the Workflow

What I'm realizing now is that these aren't isolated features.

The pieces connect together:

User Role
   ↓
Dashboard
   ↓
Job Posting
   ↓
Eligibility Criteria
   ↓
Dynamic Application Form
   ↓
Student Application
   ↓
Recruitment Workflow

The role determines what the user needs to accomplish.

The dashboard provides the tools for that responsibility.

The job defines the eligibility and application requirements.

The student submits the required information.

The application then becomes part of the recruitment workflow.

Once I started looking at the project this way, the architecture became much easier to reason about.

Building Around the Real User

My design question has changed.

Previously, I would ask:

"What database structure should I create?"

Now I'm more likely to ask:

"What is this user actually trying to accomplish?"

For the HoD:

Manage and understand students.

For the Placement Officer:

Manage placements and recruitment.

For the student:

Manage their profile and apply for relevant opportunities.

For the company:

Find and evaluate suitable candidates.

Those are different jobs.

The software should reflect those differences.

Final Thoughts

The more I work on this Placement Portal, the more I realize that good architecture isn't simply about designing tables and APIs.

It's about understanding workflows.

A database might tell me that I have users, jobs, resumes, and applications.

But the real product is the workflow connecting them.

That's why stakeholder feedback has become so important to my development process.

It forces me to step away from the code and ask a more important question:

"How does this actually work in the real world?"

The answer to that question is what should eventually shape the architecture.

Because the best software isn't designed around what the database can store.

It's designed around what the user needs to accomplish.

— Abhishek Roka