Candidates
An interview is stressful enough when there's another person in the room. How would that experience change when someone was recording responses alone, under a time limit?
Talent Select AI
Can an asynchronous interview be both structured and human?
At Talent Select AI, the CTO and I were given three months to create an asynchronous interviewing application that connected with our existing product.
And it wasn't just an interview experience. We also needed to give employers the ability to create and configure their own interviews.
The concept was straightforward. The requirements were anything but.
We needed to satisfy scientific assessment objectives, business priorities, employer expectations, and candidates who were already navigating a stressful situation.
I had a few questions.
01 / Who?
Who are we really designing this for?
The obvious answer was two groups: employers creating interviews and candidates completing them.
But each brought different needs to the table. So did the people responsible for the product.
Employers
They needed a reliable way to create interviews for different positions. But how much control could we take away before the product became too restrictive—especially for organizations with established interviewing practices?
Assessment Science
Our I/O psychologist wanted interviews to use carefully selected questions and sufficient response time to produce useful assessment data.
Business & Leadership
Our COO, a former recruiter, had evidence supporting shorter interviews. Our president was concerned about candidates using AI to generate their answers and wanted safeguards against it.
Everyone was trying to solve a legitimate problem.
The challenge was finding a solution that didn't create a new one for someone else.
02 / What?
What does the experience actually feel like?
Before designing anything, I researched asynchronous interviews and tried existing products from the candidate's perspective.
Some experiences worked reasonably well. Others used AI avatars whose movements didn't match their speech, static avatars, or text-only presentations.
My research also raised concerns about the stress candidates can experience during asynchronous interviews.
Then I started reviewing the questions employers would use.
Our I/O psychologist had provided hundreds of questions organized into categories. But when I read them aloud, something became apparent.
Many were written to be read, not spoken or heard.
Some were unnecessarily complicated. Others were awkward to say aloud or difficult to process in real time.
I raised the issue with our CTO, who began working with the psychologist to make the language more suitable for spoken interviews.
It was a small distinction with potentially significant consequences for the candidate experience.
03 / Why?
Why make an interview harder than it needs to be?
As we worked through the requirements, several competing ideas emerged.
I/O Psychologist
Our I/O psychologist favored more questions, extensive introductory instructions, and a prescribed question set. He also questioned whether employers would need multiple interviews for the same job role.
COO
Our COO's recruiting experience suggested that candidates were unlikely to tolerate interviews longer than six questions.
President
Our president wanted strong protections against AI-assisted answers, including a proposed two-minute response limit and eye-movement tracking.
Each recommendation had a rationale.
But I was concerned about their combined effect.
- Would candidates read lengthy instructions before an already stressful interview?
- Would a short timer measure their ability to answer thoughtfully—or simply how well they performed under pressure?
- Would forcing employers into a narrow question structure discourage organizations with their own interviewing standards?
I spent time discussing those concerns with our I/O psychologist. We agreed on the importance of sound assessment practices, but I raised the usability barriers some proposals could create and explored alternatives with him.
The question wasn't whether structure was valuable. It was where structure helped—and where it got in the way.
04 / What if?
What if we gave people guidance without taking away their choices?
I approached the employer and candidate experiences as two related problems requiring different solutions.
For employers: flexibility with informed guidance.
I designed an interview-building interface that let employers search a question library relevant to the selected job role and choose the questions they wanted to include.
Rather than enforce a six-question maximum, the interface allowed employers to add as many questions as they needed, including their own.
It also displayed a recommendation to keep interviews to six questions or fewer.
The employer retained control. The product provided guidance.
A recommendation, not a roadblock.
For candidates: less pressure, more clarity.
The response timer became one of our biggest points of discussion.
Rather than debate the proposed two-minute limit indefinitely, I built a simple working interview prototype using one of our actual questions.
Then we asked the president to experience it.
That changed the conversation.
We agreed on a ten-second preparation countdown after each question is asked, followed by a ten-minute response window. The remaining time would stay relatively unobtrusive until the final minute, when it became more prominent.
10 sec
Preparation countdown after each question
10 min
Response window, quiet until the final minute
<6 min
Typical response, based on existing product data
Data from our existing product suggested that most responses would take less than six minutes.
The new approach provided a reasonable limit without making the clock the center of the experience.
I also designed the candidate screen to keep both the question and the candidate visible during the response.
We worked to synchronize AI-generated speech with animated kinetic typography, allowing candidates to follow the question visually as they heard it.
The goal was a straightforward experience that communicated clearly and gave people room to think.
Sometimes the best way to challenge a requirement is to let someone experience it.
The Delivery
What happens when the design meets development?
Once the designs and functionality were approved, we worked with an external development team in Korea.
That introduced another challenge: time zones.
When an assumption needed clarification, a single question could delay progress by 24–48 hours.
24–48 hrs
Delay a single unanswered question could cause
~6 weeks
Working and sleeping on the development team’s schedule
For approximately six weeks, I shifted my working and sleeping hours so I could communicate directly with the developers during their workday while also being available for part of the company’s workday.
I clarified requirements, reviewed functionality, identified inconsistencies, and tested the implementation against the intended experience.
I also reviewed issues that had passed through the team's initial QA process.
Apparently, QA sometimes needs QA.
As the application became functional, I worked with our I/O psychologist and data scientists through two rounds of testing and feedback, followed by a company-wide test.
Those reviews helped us refine the experience before completion.
The outcome
A better balance between the requirements and the person.
We completed a working asynchronous interviewing application with both employer-facing interview creation and candidate-facing interviewing experiences.
The final design balanced structured assessment requirements with employer flexibility and a more considered candidate experience.
Instead of forcing a rigid six-question limit,
we provided guidance.
Instead of an aggressive two-minute response window,
we used a more forgiving timer informed by existing response data.
And instead of expecting candidates to work around an awkward presentation of questions,
we considered how the questions were written, spoken, displayed, and answered.
The product went through internal testing and refinement, but the company began winding down shortly after completion. We did not have the opportunity to conduct independent external usability testing or measure longer-term adoption and candidate outcomes.
So I can't provide a neat percentage improvement like I can with other projects.
What I can demonstrate is the process: questioning assumptions, finding common ground, testing ideas, and turning competing priorities into a working product.