Search for a command to run...
No comments yet. Be the first to comment.
Detailed breakdowns of real software engineering and AI projects, from problem definition and technical decisions to implementation, trade-offs, and lessons learned.
Disclosure: This case study is anonymized. Product branding, source code, production screenshots, employee and candidate information, internal architecture, commercial details, and performance metrics have been excluded.
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
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 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.
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?
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.
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.
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.
| Fragmented process | Connected workflow |
|---|---|
| Candidate data entered repeatedly | One profile supports related activities |
| Status communicated manually | Workflow state can drive visible updates |
| Interviews managed separately | Scheduling remains associated with the application |
| Evaluations stored in documents | Scores and feedback remain connected to the candidate |
| Approvals handled through messages | Pending decisions appear inside the workflow |
| Offers prepared in isolation | Offer activity remains part of the hiring record |
| Candidates request updates | Relevant progress can be surfaced directly |
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.
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:
A candidate created or completed a profile.
The candidate submitted an application.
The HR team reviewed the application.
The candidate was shortlisted, rejected, or held for further consideration.
An interview was scheduled where appropriate.
Interviewers submitted evaluations.
A hiring decision moved through any required approval process.
An offer was prepared and presented.
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.
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.
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.
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.
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:
The hiring decision reached the offer stage.
Required information was entered or confirmed.
The offer moved through the appropriate approval workflow.
A document was generated or prepared.
The approved offer became available for delivery.
Candidate action was recorded.
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.
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.
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.
Candidates could access relevant information about their application progress and upcoming actions without relying entirely on manual follow-up.
Recruitment activities could remain associated with the same candidate and job records rather than being managed as unrelated administrative tasks.
Applications, interviews, evaluations, decisions, offers, and pre-boarding activities could be represented as parts of one lifecycle.
Recruiters, interviewers, approvers, and candidates could receive interfaces and actions appropriate to their responsibilities.
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.
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.
Candidates experience uncertainty and progression. HR teams experience queues, decisions, and coordination. The product must support both without allowing them to contradict each other.
“Under review” may depend on assignments, evaluations, approvals, permissions, and server state. The label is simple; the system behind it is not.
Live events improve responsiveness, but the current server state remains authoritative. A dependable product still needs refresh and recovery behaviour.
An approval button represents more than a state change. It depends on role, sequence, current status, and whether the underlying record has changed.
Candidates should understand their progress without receiving confidential evaluations or internal decision details.
Resume and offer-document features include data preparation, versioning, validation, processing, failure handling, and access control.
“No applicants yet,” “feedback pending,” “offer not created,” and “failed to load” may all produce empty space, but they describe completely different situations.
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.
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.
What I demonstrated
Frontend development · API integration · WebSocket workflows · Role-aware interfaces · Recruitment state modelling · Approval workflows · Document experiences · Responsive UI · Cross-functional collaboration
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.
