Tara AI Interviews

At a Glance

• Product: Tara, an AI-powered first-round interviewer by iMocha

• Role: Sole UX Designer, end-to-end ownership

• Team: 2 Product Managers, CTO, Head of Product, Lead designer, engineering

• Timeline: 3 weeks

• Status: Shipped as V2. A tasks-based version is queued for the next release.

• Research: 4 to 5 qualitative interviews with recruiters, plus analytics on the original flow

• Result: Interview creation adoption 25% → 60%. Time on task 10 → 9 minutes. Task completion held at 80%.

What is Tara?

Tara interviews candidates over voice in the first round. A recruiter gives it a job role and skills, Tara asks questions and adapts to the answers, then produces a skill-based report the recruiter takes back to their ATS.

The Problem

The first version was a simple form. The recruiter typed a role name, added up to 5 skills by hand, and hit create. Tara generated questions on the fly.

It was fast. It took about 10 minutes end to end with 80% task completion. But only 25% of accounts were creating interviews, and the customers who did told us it wasn’t giving them enough value.

I had assumed manual skill entry was the pain. The analytics said otherwise. The flow was quick and people finished it. They just didn’t come back.

What recruiters told us

I ran 4 to 5 qualitative interviews with recruiters to map how they work end to end, and the PMs pulled adoption and task analytics alongside. Three things came back:

Interviews couldn’t be edited. Once created, the recruiter was locked out. The flow had traded control for speed.
No way to fine-tune. Teams with their own interviewing standards had nowhere to apply them.
The output was generic. Questions were shallow and didn’t reflect the role.

These are the same complaint in three forms. The product was fast at doing the wrong amount of work. The redesign had to add control without spending the speed.

The Constraints

These shaped every decision in the design.

A 20 to 25 minute interview cap. Longer interviews degrade candidate answers, and the voice model costs money per minute. Skill count and question count both sit downstream of this.

The recruiter is not a power user. A mid-level recruiter juggling 5 to 12 roles lives in Greenhouse, Workday or Lever. They come to iMocha to set up a filter and leave. Every extra decision is friction.

Platform consistency. AI Skills Match had already established a 3-step, JD-first pattern. I inherited it, because consistency across the platform mattered more than novelty in one product.

The Solution

Three steps, with the job description as the entry point.

Step 1: Job details.

Role name, experience range, and the JD pasted in. A manual path covers recruiters who don’t have a JD ready.

Step 2: Review Skills

Tara’s AI extracts the top 5 from the JD. The recruiter adjusts proficiency, removes, or adds their own.

Step 3: Configure Interview Questions

Two modes: let Tara ask its own questions, or write up to 5 per skill. An optional field adds company context Tara weaves into the conversation.

Key Decisions and Tradeoffs

These are the decisions which shaped tara.

Why 5 skills, and why AI picks them

Leadership and the CTO wanted 15 to 25 skills shown for the recruiter to pick from. I pushed back: 5 skills × 5 questions already fills the 25-minute cap, and scanning 20 options adds decision load for someone who wants to be in and out. We landed on AI picking the top 5 by relevance, with the recruiter free to adjust. The filtering happens in the model, not in the recruiter’s head.

Skills-first hierarchy, not questions-first

The CTO’s instinct was one question assessing several skills. The Head of Product pointed out that real interviews rarely work that way, and those questions get long and unnatural. We went skills-first, with questions grouped under each skill. It maps cleanly to the report structure.

No AI question generation in Step 3

Step 2 has “Generate Skills with AI”, so mirroring it in Step 3 was the obvious move. I argued against it. Filling all 25 slots means the recruiter has to delete before they can write, and manual mode exists precisely for recruiters who already have their questions from the hiring manager. Auto-filling would have re-created the control problem we were fixing.

Additional info field moved to Step 3

Usage data showed recruiters treating it as instructions for Tara: “ask tough questions”, “focus on leadership”. It only feeds company context. I moved it next to question configuration and rewrote the helper text to say what it does and doesn’t influence. Placement fixed it without validation rules.

Step 2 also loads empty with a generate button rather than auto-populating, matching the pattern recruiters already know from AI Skills Match. My call.

Results

Adoption was the goal and it more than doubled. The number worth looking at is the other two: we added a JD layer, manual and AI modes, a skill architecture and manual question creation, and the flow still got slightly faster with completion holding at 80%.

That told us the original problem was correctly diagnosed. It wasn’t speed. It was value, and recruiters would spend the same time for a flow that gave them control.

Analytics came from the product managers, measured on the same events before and after.

What I'd Do Differently

• I’d ship the tasks-based approach first. My research showed recruiters evaluate on “can this person do the job?” rather than “does this person have skill X?”. The tasks layer needed backend work that wasn’t ready in 3 weeks, so we shipped skills-based V2 and queued tasks for the next version. Right call for the timeline, but I shipped knowing the better answer was one version ahead.

• The UI. Platform frontend limitations capped how far I could push it visually. Given room, I’d make it feel like a guided experience rather than a form.

• Watch the new friction. Completion held, but the new steps are new places to hesitate, particularly the JD layer and the switch between manual and AI modes. That’s the first thing I’d instrument next.