Skillbrew - Hiring Board
Skillbrew - Hiring Board
Designing an end-to-end placement drive management system for an AI-powered hiring platform and making the call to embrace complexity instead of hide it.
Designing an end-to-end placement drive management system for an AI-powered hiring platform and making the call to embrace complexity instead of hide it.
My Role
Product Designer
Collaboration
Founders
Developers
Platform
Web App
What I Owned
Onboarding
Hiring Board
Bulk Actions
Context
A two-sided platform with three different users
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.
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.
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
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.
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.
1
No unified stage tracking
No unified stage tracking
Drives have multiple rounds. There was no system that showed all candidates, all stages, in one place.
Drives have multiple rounds. There was no system that showed all candidates, all stages, in one place.
2
Everything was done one candidate at a time
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.
Status updates, contact tracking, feedback - every action required clicking into each candidate individually. Across 200+ applicants, this compounded into hours per round.
3
No AI-assisted shortlisting
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.
Recruiters manually read every resume to judge JD fit. No system to surface match scores or flag strengths and gaps automatically.
4
Students and institutions shared the same interface
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.
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
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 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.
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.
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
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.
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.
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 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
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.
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.
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
Four states that move candidates through rounds
Each candidate in a drive has one of four statuses at any stage:
Each candidate in a drive has one of four statuses at any stage:
Learnings
What this project taught me
What this project taught me
1
Simplicity is not always the right goal
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.
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.
2
One signal is a hypothesis, not a conclusion
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?
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?
3
Designing with developers early changes what's possible
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.
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 Designs
Take A Look at Designs
