No unified stage tracking
Drives have multiple rounds. There was no system that showed all candidates, all stages, in one place.
Context
A two-sided platform with three different users
Skillbrew is an AI-powered placement platform built for students, colleges, and companies. Students come to practice coding, mock interviews, and aptitude. Colleges and companies come to run placement drives - screening hundreds of candidates across multiple rounds without the manual overhead.
I was brought in to design the Hiring Board: the system that colleges and companies use to manage drives end to end, from creating a placement round to making a hire. I also designed the role-based onboarding that separates what students see from what institutions see.
The problem
Running a placement drive was entirely manual
Before Skillbrew's Hiring Board, placement cells and recruiters managed drives the hard way: interviews conducted one by one, answer sheets collected by hand, candidate progress tracked across spreadsheets. For a college managing 200+ students across a 5-stage drive, this was genuinely exhausting - and things fell through the gaps.
Everything was done one candidate at a time
Status updates, contact tracking, feedback - every action required clicking into each candidate individually. Across 200+ applicants, this compounded into hours per round.
No AI-assisted shortlisting
Recruiters manually read every resume to judge JD fit. No system to surface match scores or flag strengths and gaps automatically.
Students and institutions shared the same interface
Both user types landed on the same screens. Half the features were irrelevant to each group creating confusion from the first moment.
Design strategy
Design for the actual job, not an idealised version of it
The instinct in most design projects is to simplify - strip back, hide, progressively disclose. But after understanding what a recruiter actually does mid-drive, I realised that instinct would have been wrong here.
The guiding principle
Build a system that respects the genuine operational complexity of running a placement drive - without letting that complexity feel chaotic.
Solution 01 · Role-based onboarding
Separating students from institutions from the first step
A student using Skillbrew is here to practice, apply, and prepare. An institution is here to create drives, assess candidates, and make hiring decisions. The same starting point serves neither of them well.
I proposed splitting the onboarding entirely by role. Students land on a dashboard built around their practice, applications, and AI interview prep. Institutions land on a dashboard centred on drives, pipelines, and candidate management. The trigger was one student who said "I don't know where to go from here" - not a research study, but a signal worth acting on.
Solution 02 · Drive creation wizard
Configuring a drive before it goes live
A recruiter or placement officer starts by creating a drive: naming it, uploading the JD, selecting whether it's public to all Skillbrew users or private to one university. Then they define the stages - how many rounds, what each one is - and set the criteria the AI will use to score candidate interviews.
The setup is a progressive wizard. Each step unlocks only after the previous one is complete - this prevents drives from going live half-configured.
Solution 03 · The Hiring Board
One view. Every candidate. Every stage.
The Hiring Board is where the real management happens. Each stage in a drive has a candidate table - every applicant at that stage, visible at once. The table is deliberately dense: candidate profile, AI CV-to-JD match score, recruiter feedback, contact status, and stage status are all on the same row.
The hard call
Every design instinct says simplify. I discussed this with the founders and developers - "is this too much on one screen?" came up more than once. But we kept coming back to the same question: what does a recruiter actually need mid-drive? Hiding data behind extra clicks doesn't reduce cognitive load for a power user. It adds friction at exactly the moment they can't afford it. We chose density over false minimalism.
Solution 04 · Bulk action bar
The design decision that changed the workflow
In V1, every status update was applied to one candidate at a time. For a drive with 150 applicants at the resume shortlisting stage, moving the first round forward meant 150 individual interactions. That's not a design problem. That's a workflow problem.
The contextual bulk action bar
When a recruiter selects multiple candidates, a bar appears at the bottom of the table showing exactly how many are selected (e.g. "47 of 150 selected") and exposing bulk actions: update status, mark as contacted, move to next stage - all in one step. Deselect everyone and the bar disappears. Select one person and it still shows, so the recruiter always has the same interaction pattern regardless of selection size.
Status system
Four states that move candidates through rounds
Each candidate in a drive has one of four statuses at any stage:
Passed
Candidate advances to the next stage automatically.
Hired
Candidate is hired directly, skipping all remaining stages. Built for cases where a recruiter wants to fast-track someone after just one round.
On Hold
Candidate stays at the current stage - decision deferred.
Rejected
Candidate is removed from progression. Still visible in history.
Learnings
What this project taught me
Simplicity is not always the right goal
The most important design decision I made here was resisting the urge to strip the interface down. Recruitment operations are complex. Designing a system that acknowledges that complexity - and makes it manageable - was harder than building something minimal, and more honest about what the user actually needs.
One signal is a hypothesis, not a conclusion
The student who said "I don't know where to go from here" pointed me toward the right question - but I was working with a sample of one. I've since learned to ask: is this one person's problem, or a pattern? And what's the underlying cause, not just the symptom?
Designing with developers early changes what's possible
My conversations with the dev team while designing the bulk action bar changed the final implementation. Had I handed over a finished spec, we would have lost that. Early collaboration is not a soft skill - it's a design tool.
Designs
Take a look at the designs
Next case study