EVA · AI Screening & Interview Platform · Emversity · 2024–25
EVA is a two-part AI assessment — an MCQ test and a live AI voice interview — that screens applicants before they're admitted into Emversity's healthcare and allied programs. It replaced an admissions process with no structured way to check whether someone was actually ready for the course.
Emversity admitted students into healthcare programs with no structured way to check readiness, so some dropped out mid-course.
I owned EVA end to end — designing a two-part MCQ plus AI voice interview and its proctoring flow.
EVA now runs live at eva.emversity.com, screening applicants at scale with zero human interviewers needed.
The problem
Emversity was admitting students into professional healthcare programs — BVoc Medical Laboratory Technology, psychology courses, and similar — with no structured way to assess baseline knowledge or aptitude first. Students joined, struggled with the curriculum, and some dropped out mid-course, dragging down completion rates and program reputation.
The existing process was either no screening at all, or informal checks that were inconsistent and easy to game. There was no scalable way to screen hundreds of applicants across multiple programs without hiring a human interviewer for every one of them.
The question: could an AI system screen students the way a human interviewer would — asking the right questions, adapting to the program, and giving admissions a reliable signal on readiness?
MCQ test (20 questions, 30 min) + AI interview (20 questions, 30–60 min)
Camera, microphone, and screen share active throughout both parts
The interviewer is fully AI-driven — voice-based, no person on the other side
My role
I owned EVA end to end — from understanding why the admissions problem existed, to designing the product flow, to working with engineering to ship the proctoring system, the AI interview engine, and the assessment experience. I wasn't the developer here. I owned every product decision: what the two-part structure should look like, how proctoring should work, what the AI interviewer should do, and how results feed back into admissions decisions. [NEEDS INPUT: 2-3 sentences on the actual day-to-day texture of owning the AI engine — did you write/review the question bank? set the scenario-question rubric? review model output samples with engineering?]
The product
Part 1 is a subject-specific MCQ test mapped to the program applied for. Part 2 is the core of the product — a live, voice-based AI interview that asks scenario-based questions and adapts to the program, evaluating applied thinking rather than recall.
The dashboard — each applicant sees their assigned test, split into its two parts, with time estimates upfront
Getting proctoring right
Students needed to grant camera, microphone, and screen share access before starting — if any of it failed mid-test, the test's integrity was compromised. The first version had a single "grant permissions" screen, and students kept getting into the test with a broken camera or mic, then raising a support ticket. I redesigned it as four sequential steps, each one verified and shown back to the student before they could move to the next.
Instructions
Rules stated plainly — camera monitoring active, tab switching ends the test, face must stay visible. A red warning reinforces the stakes before the student can proceed.
Step 1 — Instructions, with duration and question count stated upfront
Camera setup
The student sees their own live feed and confirms it's working before moving on.
Caught a real problem here: students pointing cameras at the ceiling. The live preview surfaced it before the test ever started.
Step 2 — Camera Setup · live feed replaced here with a placeholder for privacy
Microphone setup
A pulsing "Microphone Active" indicator — required, since Part 2 depends entirely on captured speech.
Step 3 — Microphone Setup
Screen share
Entire screen, not just a window — so tab switching and external activity can actually be detected. Only after all four steps confirm does "Launch Assessment Now" activate.
Step 4 — Screen Share, all four steps confirmed
The MCQ experience
Inside the test, the layout is deliberate: a question navigator on the left, one question at a time in the centre, and the student's own camera feed — visibly labelled "Monitoring" — always present on the right. Seeing your own feed with that badge reduces the temptation to look away or reach for a second device, without needing any aggressive intervention.
MCQ in session — question navigator, timer, live progress · camera feed replaced with a placeholder for privacy
The AI interview
This is the centrepiece. The AI speaks with a live audio waveform on the left; the student's camera sits on the right. No person is listening on the other end — the AI asks scenario-based questions calibrated to the program, evaluates the response, and moves on. For BVoc Medical Laboratory Technology, that means clinical, practical scenarios — not textbook recall.
The AI interview — live waveform, live transcript prompt below · camera feed replaced with a placeholder for privacy
Completion — results generate automatically, and the next step is surfaced immediately
Key decisions
Four steps, not one screen
Instead of: a single "grant permissions" screenThe single-screen version let students start with a broken camera or mic and then raise a support ticket. Verifying each permission sequentially — and showing it back to the student — caught failures before the test began instead of after. Support tickets on proctoring failures dropped noticeably.
Voice interview, not typed
Instead of: a typed Q&A formatA typed interview simulates a written test, not a real conversation. The point of Part 2 was to assess how someone thinks and communicates under realistic conditions — harder to build, but it's the only version that actually tests what the product claims to test.
Show the student their own camera feed
Small decision, real effectStudents who see their own feed with a "Monitoring" badge are less likely to look away — not because they're scared, but because the visual reminder keeps them anchored. Behavioural design, not surveillance theatre.
Scenario questions, not factual recall
"What should be checked before using reagents?" vs. "A patient's sample shows unexpected results — walk me through your diagnosis"EVA is trying to predict course performance, not whether someone read the textbook. The interview question bank was pushed toward applied thinking specifically because that's the signal admissions actually needs.
Calibrating the AI interviewer
[NEEDS INPUT: describe any process for reviewing AI interview transcripts, comparing AI scoring against what a human interviewer would conclude, or catching bad/biased/irrelevant questions before they reached applicants. If no formal process existed, say so directly — e.g. "I didn't build a formal review loop for this in v1 — a gap the reflection below addresses directly."]
Outcome
EVA is live at eva.emversity.com, handling full proctoring, AI-driven interviews, and automated result generation end to end. It let Emversity screen students at scale without hiring a human interviewer for every program.
Richer signal
Knowledge (MCQ) and applied thinking (AI interview) together give admissions a fuller picture than either test alone could.
Scalable by design
No human interviewer bottleneck — the AI interview scales to as many applicants as apply, across any program EVA is configured for.
Directional, not measured yet
[NEEDS INPUT: number of applicants screened to date, or hours of human-interviewer time replaced per cycle]. Students who pass both parts show meaningfully higher engagement once inside the program — directional, not measured yet.
What I'd do differently
Build the analytics layer from day one
EVA generates interview responses and MCQ results, but the admissions team was reading them manually in the early version. A structured dashboard — score distributions, where students drop off in the setup flow, which MCQ questions fail most often — would have made every cohort's screening smarter than the last, instead of starting from scratch each time.
Calibrate interview difficulty by cohort
Early on, the question bank was one-size-fits-all — students from different backgrounds got identical questions regardless of stated experience. I'd build difficulty tiers and let the AI adapt based on early answers, so someone who aces the first two questions gets progressively harder follow-ups instead of staying flat.
Set up a formal AI-evaluation loop from day one
I'd compare AI interview scores against admissions-team overrides systematically from the start, instead of relying on directional signal after the fact.