Building the frontend experiences and integrations behind recruitment, evaluation, offers, and pre-boarding

Industry: Recruitment and workforce management

Project type: Recruitment workflow and candidate-management platform

My contribution: Frontend Developer (Integration & Development)

Team:

• Shebaan Kalim - UI/UX Designer

• Musadiq Shariq - Frontend Developer

• Mohammad Maheer - Backend Lead

• Noman Shahid - Backend Developer

Overview

Recruitment rarely happens inside one form.

A candidate submits an application, recruiters review it, interviews are scheduled, interviewers provide evaluations, managers approve decisions, offers are prepared, and successful candidates move toward pre-boarding.

When those activities are spread across email, spreadsheets, calendars, document templates, and disconnected systems, both sides lose visibility.

Candidates may not know whether their application has been reviewed or whether the organization expects another action from them. Recruiters must reconstruct the current state by checking several tools and asking colleagues for updates.

Our team developed a web platform that brought these connected recruitment activities into a shared workflow.

My contribution focused on the frontend experiences used by candidates and HR teams. I developed dashboards and workflow screens, integrated backend APIs, supported application-status updates, contributed to resume-management features, and coordinated implementation details with the design and backend teams.

The real problem was fragmented state

The obvious problem appeared to be tool fragmentation.

Recruiters might use one system for job postings, another for communication, calendars for interviews, documents for evaluations, and templates for offer letters.

The deeper problem was that no single place represented the complete state of a candidate.

A candidate could be:

• Newly applied.

• Under review.

• Shortlisted.

• Awaiting an interview.

• Interviewed but not yet evaluated.

• Waiting for approval.

• Selected for an offer.

• Rejected.

• Moving into pre-boarding.

Each stage depended on actions performed by different people.

The platform therefore needed to answer two different sets of questions.

What candidates needed to know

• Was my application received?

• Has its status changed?

• Is an interview scheduled?

• Does the organization need anything from me?

• Can I update or reuse my profile and resume?

• What happens next?

What HR teams needed to know

• Which candidates require review?

• Which interviews need scheduling?

• Which interviewers have submitted feedback?

• Which decisions are waiting for approval?

• Which offers need preparation or review?

• Which successful candidates are ready for the next stage?

The engineering challenge was not simply displaying this information.

It was ensuring that both interfaces represented the same underlying recruitment process without exposing internal actions inappropriately or allowing the two views to contradict each other.

My contribution

I worked primarily on the frontend implementation and integration of the candidate and HR experiences.

My contribution included:

• Developing candidate-facing dashboard screens.

• Developing HR and recruitment-management interfaces.

• Integrating application, job, interview, evaluation, approval, and offer-related APIs.

• Supporting application-status updates through WebSocket and REST-based interactions.

• Presenting workflow progress and pending actions clearly to candidates.

• Building interfaces for interview scheduling and interview evaluations.

• Supporting approval workflows for recruitment decisions and offers.

• Collaborating on resume creation, upload, and download experiences.

• Handling loading, empty, successful, restricted, and recoverable error states.

• Implementing responsive behaviour across supported screen sizes.

• Coordinating frontend requirements with the product designer, backend engineers, and senior frontend engineer.

I did not design or develop the entire platform independently.

The designer owned the intended product experience. Backend engineers implemented the services and domain rules behind recruitment operations. Frontend responsibilities were shared across the team. My work centred on implementing substantial parts of the user-facing workflows and connecting them to those supporting services.

Why separate tools were not a complete solution

Using specialized tools for each recruitment activity can appear flexible.

A calendar handles interviews. A spreadsheet tracks applicants. Email manages communication. Documents record evaluations. Templates produce offers.

The weakness emerges at the boundaries.

An interview rescheduled in one system may not update the applicant tracker. An evaluation may exist but remain invisible to the person responsible for approval. A candidate may receive an offer while their application status still appears unchanged elsewhere.

The organization then depends on people manually keeping every tool synchronized.

The platform’s value was therefore not that it replaced every specialized tool.

It created a shared workflow in which the relationship among those activities could be represented consistently.

Designing recruitment as a stateful workflow

Recruitment is not a straight sequence in which every candidate advances through identical stages.

Candidates may be rejected early, returned for additional review, interviewed more than once, moved between openings, or left waiting while an approval is pending.

The frontend needed to represent these paths without making the experience appear unpredictable.

A representative lifecycle included:

1. A candidate created or completed a profile.

2. The candidate submitted an application.

3. The HR team reviewed the application.

4. The candidate was shortlisted, rejected, or held for further consideration.

5. An interview was scheduled where appropriate.

6. Interviewers submitted evaluations.

7. A hiring decision moved through any required approval process.

8. An offer was prepared and presented.

9. An accepted candidate moved toward pre-boarding.

Each transition affected available actions.

For example:

• An interview should not be evaluated before it occurs.

• A candidate should not see confidential interviewer notes.

• An offer should not appear as final while approval remains pending.

• A rejected application should not continue displaying actions intended for active candidates.

• A rescheduled interview should not remain visible as two unrelated active events.

The interface therefore needed to understand not only what data existed, but what that data allowed each user to do next.

Engineering principle: A recruitment platform is a permission-aware state machine presented as a series of dashboards and forms.

Keeping candidate and recruiter views consistent

The candidate dashboard and HR dashboard served different purposes.

Candidates needed a clear, limited view of their own applications and required actions. HR users needed broader operational information for managing candidates, interviews, approvals, and offers.

Those experiences could not simply expose the same response objects with different styling.

The frontend needed to translate recruitment state according to the current user’s context.

For candidates, that meant presenting:

• Current application status.

• Upcoming interviews.

• Relevant requests or next steps.

• Resume and profile information.

• Appropriate offer or pre-boarding actions.

For HR teams, it meant presenting:

• Candidate queues.

• Job-specific application lists.

• Interview schedules.

• Pending evaluations.

• Approval requirements.

• Offer progress.

• Records requiring follow-up.

The challenge was preserving consistency without revealing internal information.

A candidate might need to know that a decision was still in progress. They did not necessarily need to know which manager had not yet approved it or what an interviewer had written.

This required the frontend to distinguish between shared workflow state and role-specific presentation.

Integrating live application-status updates

Application status is one of the most visible parts of a recruitment product.

A stale status undermines the transparency the feature is supposed to provide. At the same time, the frontend cannot assume that every change occurs within the candidate’s current browser session.

Recruiters and other authorized users may update the application from a separate interface. Approval services may change the state later. Interview activity can also modify what the candidate should see.

The frontend used WebSocket and REST interactions to support updated workflow information.

That introduced several responsibilities:

• Listening for relevant state changes.

• Updating the visible application without duplicating records.

• Refreshing dependent information when necessary.

• Handling reconnection or unavailable live updates.

• Avoiding contradictory local and server states.

• Providing a reasonable fallback when immediate updates were unavailable.

• Preventing the interface from announcing changes that the user was not permitted to inspect.

Real-time behaviour was therefore not simply a matter of receiving an event.

The interface still needed to determine what had changed, whether the current view depended on it, and how to present that change safely.

Coordinating interviews, evaluations, and approvals

Interview scheduling appears to be a calendar problem, but the calendar is only one part of the workflow.

A scheduled interview may depend on:

• The candidate’s current application stage.

• Interviewer availability.

• The interview round.

• The position being considered.

• Required evaluation criteria.

• Whether previous feedback has been completed.

• Which users can reschedule or cancel the meeting.

After the interview, evaluations also need to return to the appropriate recruitment record.

The interface must distinguish between:

• An interview that is scheduled.

• An interview that is awaiting completion.

• An interview that was rescheduled.

• A completed interview awaiting feedback.

• Submitted feedback awaiting a decision.

• A decision waiting for further approval.

This is where several seemingly simple features become one coordinated system.

The frontend connected scheduling, evaluation, and decision states so that the current recruitment condition remained understandable across different screens.

Managing offer and approval workflows

An offer letter is not only a downloadable document.

It can be the output of a controlled workflow involving compensation details, review, authorization, generation, delivery, acceptance, or rejection.

The interface needed to avoid presenting a draft or pending offer as finalized.

It also needed to make pending work visible to the appropriate HR users without exposing sensitive details to unauthorized users.

A representative offer process included:

1. The hiring decision reached the offer stage.

2. Required information was entered or confirmed.

3. The offer moved through the appropriate approval workflow.

4. A document was generated or prepared.

5. The approved offer became available for delivery.

6. Candidate action was recorded.

7. The workflow either progressed toward pre-boarding or closed.

The frontend’s responsibility was to represent that lifecycle accurately and limit actions according to the current state and user permissions.

Supporting candidate profile and resume management

Candidate information often exists in several formats.

A candidate may complete structured profile fields, upload an existing resume, or use the platform to create and download a resume.

These options provide flexibility, but they also introduce data-consistency questions.

For example:

• Which information is displayed when the profile and uploaded resume differ?

• Does updating the profile change an already submitted application?

• Which version of the resume is attached to a particular application?

• What happens if document generation fails?

• Can a candidate download a resume without submitting an application?

• Which file formats and sizes are accepted?

• How should upload progress and errors be communicated?

The interface needed to make those distinctions understandable rather than treating “resume” as one interchangeable file.

This was another example of frontend complexity coming from product rules rather than visual components.

Outcome

The project delivered connected frontend experiences for candidates and HR teams across a broader recruitment workflow.

The work supported:

• Job and application management.

• Candidate dashboards and application visibility.

• Interview scheduling.

• Interview evaluations and scoring.

• Hiring-decision and offer approvals.

• Offer preparation and tracking.

• Candidate profile and resume management.

• Pre-boarding progression.

• Status updates across candidate and administrative interfaces.

From an engineering perspective, the implementation produced several qualitative outcomes.

Better visibility for candidates

Candidates could access relevant information about their application progress and upcoming actions without relying entirely on manual follow-up.

A more connected HR workflow

Recruitment activities could remain associated with the same candidate and job records rather than being managed as unrelated administrative tasks.

More consistent workflow state

Applications, interviews, evaluations, decisions, offers, and pre-boarding activities could be represented as parts of one lifecycle.

Clearer coordination across roles

Recruiters, interviewers, approvers, and candidates could receive interfaces and actions appropriate to their responsibilities.

Reusable frontend patterns

The project established patterns for role-aware dashboards, asynchronous updates, approval states, document workflows, and multi-stage operational processes.

These are qualitative implementation outcomes.

This case study does not claim measured improvements in hiring time, administrative hours, candidate satisfaction, offer acceptance, recruitment cost, or employee retention because supporting analytics and disclosure permission are not available.

Limitations

The platform brought several recruitment activities into a connected workflow, but software alone does not make a hiring process transparent or fair.

Candidate experience still depends on:

• Whether recruiters update statuses promptly.

• Whether evaluation criteria are clear and consistently applied.

• Whether interviewers submit feedback on time.

• Whether candidates receive useful communication.

• Whether access controls protect sensitive information.

• Whether the organization’s process itself avoids unnecessary stages and delays.

A well-designed interface can make operational state visible.

It cannot compensate indefinitely for an unclear or poorly maintained recruitment process.

What I learned

1. Recruitment software serves two narratives

Candidates experience uncertainty and progression. HR teams experience queues, decisions, and coordination. The product must support both without allowing them to contradict each other.

2. Status labels are condensed business logic

“Under review” may depend on assignments, evaluations, approvals, permissions, and server state. The label is simple; the system behind it is not.

3. Real-time updates require a fallback

Live events improve responsiveness, but the current server state remains authoritative. A dependable product still needs refresh and recovery behaviour.

4. Approval workflows are permission systems

An approval button represents more than a state change. It depends on role, sequence, current status, and whether the underlying record has changed.

5. Candidate transparency needs deliberate boundaries

Candidates should understand their progress without receiving confidential evaluations or internal decision details.

6. Document generation is a workflow, not a download link

Resume and offer-document features include data preparation, versioning, validation, processing, failure handling, and access control.

7. Connected products need consistent empty states

“No applicants yet,” “feedback pending,” “offer not created,” and “failed to load” may all produce empty space, but they describe completely different situations.

Closing reflection

This project was broader than building a job board or a collection of HR dashboards.

The engineering challenge was to represent one recruitment process across candidates, recruiters, interviewers, and approvers while keeping the underlying state consistent.

My contribution focused on building and integrating those user-facing workflows: candidate and HR dashboards, application-status behaviour, interviews, evaluations, approvals, offers, resumes, and responsive interaction states.

The central lesson was that recruitment transparency does not come from displaying more information.

It comes from accurately translating a complex, role-dependent process into information and actions each participant can understand.

Engineering Takeaways

• Model workflows as explicit states, not scattered UI logic.

• Keep the backend as the source of truth for transitions and permissions.

• Pair real-time updates with reliable fallback mechanisms.

• Separate business state from presentation to keep systems maintainable.

Portfolio callout

What I demonstrated

Frontend development · API integration · WebSocket workflows · Role-aware interfaces · Recruitment state modelling · Approval workflows · Document experiences · Responsive UI · Cross-functional collaboration

Publication note

All accompanying diagrams and interface illustrations must be labelled representative or conceptual. They must not be presented as production screenshots, exact architecture diagrams, customer analytics, or reproductions of the product’s proprietary workflow.

"It's just a screen."

"Backend does the real work."

"AI can generate that."

"Just use ShadCN."

"Just copy the component."

"It's just a checkbox."

And every frontend developer silently smiles because they know where this story is headed. Because somewhere, deep inside Jira, a "simple checkbox" is preparing to ruin someone's week.

The Great Myth: Frontend Being Easy

People outside frontend often imagine our job like digital LEGO.

Everything looks simple. Until somebody says:

"Can we add a checkbox?"

And suddenly four days disappear from your life.

Ask me how I know.

The Story: It's Just a Checkbox

At my previous company, we were building a project management platform for a large auditing firm.

One day our PM asked for a checkbox on a senior consultant's dashboard. PM said:

It's just a checkbox. You can probably do it in two hours. In fact, I'm giving you the whole day so you can test it too.

According to her, she was being generous.

Honestly, I thought the same.

How hard could a checkbox be?

My assumptions needed debugging.

Day 1: The Checkbox Doesn't Exist For Everyone

Turns out the checkbox wasn't for every senior consultant.

It should only appear if:

• The project is from a certain type of client, OR

• The project is from the clients having ARR above the given limit.

• The project is active.

• The project belongs to a specific category.

• The consultant is actually responsible for that project.

• And few other client and project related checks.

Okay.

Not terrible.

Just some filtering and conditions.

Still sounds like a checkbox.

Right?

Wrong.

Day 2: Clicking It Doesn't Actually Do Anything

Checking the box wasn't the real feature.

The checkbox created a request that needed approval from the consultant's senior manager.

Now we're talking about:

• New API endpoints.

• New request states.

• Approval workflows.

• Error handling.

• Loading states.

• Notifications.

Funny enough, the checkbox itself became the least interesting part.

Day 3: Management Doesn't Like Delays at Their End

Then another requirement appeared.

Senior managers didn't want requests piling up when they weren't around.

So the checkbox should only be visible when the corresponding manager was currently using the application.

Wait… what?

Not online recently.

Not active today.

Actively connected.

At that moment.

Because if the manager wasn't available, consultants shouldn't create requests that would just sit there.

Which meant we needed real-time presence.

Not for chat.

Not for notifications.

For a checkbox.

Computers are fascinating and mildly offensive.

Day 4: Congratulations, You've Built a System

By this point, we had:

• Modified database models.

• Added new API contracts.

• Introduced new frontend states.

• Defined new data flows.

• Added presence tracking.

• Maintained socket connections.

• Managed synchronization between users.

• Tested edge cases.

• Handled loading, errors, and race conditions.

And somewhere in the middle of all that…

There was a checkbox.

Thirty hours later, the feature was done.

Not because drawing a checkbox takes thirty hours.

Because business rules do.

The Funny Thing About Frontend

Frontend isn't difficult because buttons are hard. The complexity comes from translating human requirements into behavior.

Every "simple" feature eventually turns into:

"What if this happens?"

"What if they're offline?"

"What if two people click simultaneously?"

"What if permissions change?"

"What if the API is slow?"

"What if the socket disconnects?"

"What if this user shouldn't even see the button?"

The UI is where all these questions become visible.

Backend systems have complexity.

No doubt.

But frontend has to absorb complexity coming from users, business rules, permissions, accessibility, responsiveness, loading states, and the beautiful chaos known as changing requirements.

And unlike backend, everyone sees frontend. Which means everyone has opinions about it.

Including people who think AI can replace it because it generated a pretty card component once.

Just Use ShadCN

I love ShadCN. And use AI daily.

Component libraries are amazing. They remove boring work.

But they don't solve business problems.

ShadCN gives you a checkbox.

It doesn't tell you:

• Who should see it.

• When it should disappear.

• Which projects qualify.

• How approvals flow.

• How real-time presence works.

• What happens when connections fail.

• How state should synchronize.

The hard part was never drawing the box. It was understanding what the box actually meant.

AI Can Generate Components. It Can't Generate Context.

AI is fantastic at producing buttons, forms, and layouts.

But business logic lives inside conversations, assumptions and requirements nobody mentioned until Wednesday afternoon.

And every frontend developer knows this magical sentence:

"Oh, one more thing…"

Those four words have probably consumed more engineering hours than TypeScript errors.

Conclusion: Is Frontend Easy?

Honestly?

Yes.

Right up until you actually build something. Then you realize frontend isn't about pixels. It's about translating human chaos into something people can click. And somehow making it feel simple.

Maybe that's why the best frontend work looks easy.

Not because it is.

But because somebody spent four days making a checkbox feel like a checkbox.

And honestly, that's the fun part.

Reasoning models are designed to think step by step, and the common assumption is simple:

More thinking = better results.

I expected reasoning models to dramatically outperform simpler ones.

Surprisingly, the improvements weren't always as large as expected.

Sometimes AI just spends more computation reaching nearly the same answer.

Bigger Brain, Bigger Bill

Reasoning comes with costs:

• More tokens

• More GPU time

• More energy

• Higher latency

• Higher costs

Like using a supercar for a five-minute grocery trip, extra power isn't always necessary.

The Real Question

The important question isn't:

"Can AI think harder?"

It's:

"Does thinking harder consistently produce better results?"

The answer appears to be: not always.

Just as humans can overthink, AI can sometimes add complexity without adding much value.

Complexity Has a Cost

We often equate complexity with intelligence, but efficiency matters too.

More parameters and longer chains of reasoning don't automatically mean better outputs.

Sometimes effort is mistaken for effectiveness.

There's an Environmental Cost Too

Longer reasoning means more computation and more electricity.

At scale, millions of extra tokens translate into higher energy consumption and a larger carbon footprint.

Smarter AI should also aim to be more efficient.

Better Prompts Can Matter More

Another surprise: clearer instructions often improve results significantly.

Not bigger models.

Not more reasoning.

Just better communication.

Sometimes asking better questions matters more than thinking longer.

So, Is Overthinking a Red Flag?

Not always.

Complex problems need deep reasoning.

But many tasks don't.

In some cases, answers produced in 5 seconds are nearly identical to those produced in 50.

The real goal may not be building AI that thinks harder, but AI that knows when to stop thinking.

And that might be the smarter approach.

One More Thing 📚

I originally wrote this post while working on a research paper about the same question.

If you're curious about the detailed experiments, results, and comparisons, you can find them in the paper. This post is more about the strange ideas, surprising observations, and "Wait, what?!" moments I ran into along the way.

Zubair, M. A., Bouchelligua, W., Danish, S., Ahmad, S., & Ksibi, A. (2026). Evaluating AI Reasoning and Prompt Engineering in Automated Test Case Generation: A Comparative Study of GPT-4o, O1 Models, and Human QA. Applied Soft Computing, 201, 115708. https://doi.org/10.1016/j.asoc.2026.115708

Apparently, "Wait… what?" is a valid research methodology.

And honestly, that's the fun part.