AI Interviewer
An internal web app that runs the first round of technical screening, so engineers don't have to.
I was the only designer on a seven-person team and designed the full platform: the candidate assessment and the dashboards for TA, recruiters and leadership. I also ran the early POC testing and the TA interviews and synthesised the findings. The tool is used in real hiring, and the version described here is the second one, rebuilt after launch.
Candidates complete two rounds:
TA, recruiters and leadership review the results, proctoring flags, and each candidate's hiring status on their own dashboards. After the assessment, candidates get an email with feedback on how they performed, but not the final result.
Where AI belonged
The product was a technical screening platform to replace the manual first round. Early on, the most ambitious idea was an AI voice that would run the whole interview. Here's what decided it, in order:
So Version 1 became a familiar technical assessment, with the AI chatbot only in the system design round.
Version 1: a three-round assessment
Before any design, I built the research foundation: a TA and recruiter persona from primary research (the TA interviews), a candidate persona from secondary research, a user journey map, and a Kano prioritisation run with the team to decide what the MVP included.
I built the candidate persona around a deliberate worst case: the least experienced candidate, on their most stressful day. If the assessment worked for them, it would work for everyone else.
The first version had three rounds: technical MCQ, coding, and system design. I based the format on familiar coding-test platforms, which most candidates already know, so they wouldn't have to learn a new interface under time pressure. The AI chatbot only appeared in system design.
It shipped in about six weeks.
What launch showed us
Soon after launch, TA noticed candidates getting full marks on MCQ and coding and then doing badly in system design. The gap was too consistent to be chance. Candidates were using AI tools to answer the two automated rounds.
Version 2: testing understanding
The team decided to drop the MCQ round. I redesigned the coding round into the reverse-engineering task: rather than writing code, candidates explain AI-written code.
We couldn't stop candidates from using AI, so the round now checks whether they understand what it produces. System design stayed, because it was the one round that had held up.
Designing for nervous candidates
A job assessment is stressful, and a nervous candidate performs below their level, which makes the results less accurate.
My first candidate interface had all the right information but was cluttered. I simplified the layout and added:
- A pre-test screen with instructions and the timer, so candidates know what's coming before the clock starts
- Tooltips that explain each part of the interface before the test begins
- A feedback email after the assessment, which I suggested so candidates know how they performed and what happens next instead of waiting without hearing anything
Proctoring
Before starting, candidates accept permissions for full-screen recording and camera access. During the test, the system detects multiple faces in the frame and switching between tabs, and flags the affected responses.
Flags appear on the reviewer side, where TA decides what to do with them, rather than as warnings that interrupt the candidate during the test.
Dashboards
TA, recruiters and leadership each see assessment results, proctoring flags and where each candidate is in the hiring process.
What didn't get built, and what I'd push for
Closing the proctoring gaps. The current system is easy to get around. Someone off-camera can help, or a candidate can read from a second screen without switching tabs. I proposed detecting other voices and tracking eye movement. Both were cut for technical reasons. If they were added, I'd make sure flags still go to a human reviewer and never reject a candidate automatically, since eye tracking in particular produces false flags.
Help during the test. If a candidate's connection drops or something breaks mid-test, there's nobody they can contact. I wanted a built-in way to reach support immediately, so a technical problem doesn't turn into panic about their result. It wasn't built.
What I learned
The biggest early decision, how much of the product AI should run, was settled by build time. My part was testing it with people, and the POC showed the constraint pointed the right way: a fully AI-run interview would have cost candidates' trust. Keeping the rest a familiar assessment is also what made the tool shippable in six weeks.
The second lesson came from launch: candidates will bring AI to an AI assessment. The first version tried to test skills the AI could fake. The second version assumes they'll use AI and tests whether they understand the output.