The hard part of a Bangla interview engine was the speech
Everyone assumes the difficult part of an AI interviewer is the reasoning. Building VivaBoard in Bangla, it was the four seconds before the reasoning.
Describing VivaBoard to another developer produces a predictable question. An AI that conducts a mock interview - how do you get the model to ask good follow-up questions?
It is the wrong thing to worry about. Follow-up questions were roughly a week of prompt design and evaluation work. The part that consumed months was getting the candidate's Bangla answer into the system accurately enough that a follow-up question was worth generating at all.
What a viva actually is
VivaBoard exists because of a specific gap. A BCS candidate in Bangladesh can buy a hundred books of model questions and cannot rehearse the one part of the process that decides the outcome. The written exam has infinite practice material. The viva has none, because a viva requires another person in the room who will ask a second question - the one that follows from what you actually just said, rather than the one printed next in the list.
That is the product. An examiner that speaks its question aloud, listens, and responds to the specific answer it received. Everything else in the app - the learning centre, the question banks, the job circular feed, the streaks - exists around that loop.
Which means the loop has one requirement above all others: it must hear you correctly. An examiner that mishears an answer and then asks a confident follow-up about something you did not say is worse than no examiner, because the candidate cannot tell which part went wrong. They walk away having practised a conversation that never happened.
English is a solved commodity. Bangla is not.
If VivaBoard were English-only this post would not exist. English speech-to-text is essentially a utility now. Accuracy is high, latency is low, providers are interchangeable, and the price per minute is a rounding error.
Bangla is a different situation, and the gap is wider than the headline benchmarks suggest, for reasons that show up specifically in this use case:
- Code-switching. Bangladeshi candidates do not answer in pure Bangla. They answer in Bangla with English terms embedded - job titles, technical words, degree names, whole clauses. A recogniser tuned for one language treats the other as noise.
- Register. An exam answer is formal, closer to written Bangla than to how anyone speaks at home. Much conversational training data is not.
- Stress. This is the one I had not anticipated. Under interview pressure people speak faster, restart sentences, trail off and repeat themselves. The recogniser is being asked to work on its worst input at exactly the moment accuracy matters most.
- Nerves plus a cheap microphone plus a ceiling fan. Which is the actual recording environment for most of our users, and no benchmark measures it.
What we did about it
The stack ended up split across vendors, which was not the plan. Sarvam handles Bangla speech-to-text and text-to-speech; OpenAI handles reasoning and evaluation. The split exists because nothing was good enough at both ends, and pretending otherwise would have meant shipping a product that fails at the only thing it does.
Two decisions made more difference than the vendor choice.
The transcript is visible while you speak. The candidate watches the live transcription as they answer. This started as a nicety and turned out to be load-bearing. When the system mishears, the user sees it happen, and the failure becomes a visible glitch instead of an invisible corruption of everything downstream. It also gives them a reason to speak more clearly, which improves the input. Showing your work is a legitimate engineering strategy when the work is imperfect.
The full transcript is reviewable afterwards, line by line. The report gives dimension-wise scores, filler-word analysis, confidence signals, strengths and weaknesses. All of that is derived. If a candidate disagrees with a score, they can go to the transcript and see what the system thought it heard. A scoring system nobody can audit is a scoring system nobody should believe.
The configuration decision
Related, and worth stating because it is the decision I would defend hardest.
Nearly every business rule in VivaBoard lives in the admin panel rather than in the code. Pricing, credit costs, the scoring dimensions and their weights, the number of questions in a session, ad placements. All configuration.
This is more work up front and it is obviously correct for a product that has not launched. I do not yet know what the right scoring rubric is. Nobody does - that is what closed testing is for. If finding out costs a release cycle every time, we will run the experiment perhaps five times. If it costs an afternoon, we will run it fifty times, and the fiftieth rubric will be much better than the fifth.
Hire, and the line I will not cross
The same engine points at employers. VivaBoard Hire lets companies build interview campaigns, set their own questions and rubrics, invite candidates to asynchronous AI-conducted interviews, and receive transcripts, competency scores, integrity signals and a ranked pipeline.
It ranks. It does not reject.
An AI that scores a candidate and an AI that filters a candidate out are the same model with different consequences, and the second one is a system I do not want to have built - particularly in a market where a single job posting draws thousands of applicants and the temptation to automate the cut is enormous. Recruiters get the evidence. A person makes the call.
If someone eventually uses the API to build the filter anyway, I will have lost that argument. But the product will not ship the button.
What I would tell someone building for a non-English market
The hard part is almost never where the demo is. Demos happen in English, in a quiet room, on a good connection, with someone who knows what the product expects them to say.
Find the layer between your user and your model - speech, script, input method, network - and assume that layer is where your product will actually fail. In our case it was four seconds of audio from a nervous person in a room with a ceiling fan, and every impressive thing downstream depended entirely on getting it right.