Bolna Data Scientist Interview: Questions, Experience & Prep (2026)

Bolna builds AI voice agents for businesses, running real-time phone conversations powered by LLMs, ASR, and TTS stacked into a single pipeline. With 11 open roles currently listed, the company is in active hiring mode. A Data Scientist here typically works across conversation quality evaluation, intent classification, model monitoring, and analytics on call data, sitting close to the core product rather than in a separate analytics silo.

Candidates report a process of 2-3 rounds: a screening call, a technical round covering ML and NLP fundamentals, and a final round with either a take-home task or a live system design discussion. Interviewers typically value practical judgment over textbook answers: can you ship a model that works under real-time constraints, measure what matters for a voice product, and iterate fast in a startup setting?

Data Scientist roles are active across India right now. Current data tracks 937 such openings, with Bangalore leading at 166 roles, Delhi at 46, Hyderabad at 27, Pune at 18, Mumbai at 17, and Chennai at 8. Bolna's 11 active positions make it one of the more active AI-focused startup hirers for this profile.

These questions reflect the skills Bolna's product demands: real-time inference, conversation quality measurement, and LLM-driven voice agent behavior. Candidates report a mix of conceptual, applied, and behavioral questions across rounds.

1. Walk us through how you would evaluate the quality of a voice AI conversation end to end.
2. How would you measure and reduce latency in a real-time speech-to-text pipeline?
3. Explain how you would fine-tune an LLM for a specific domain like banking or insurance.
4. What metrics would you track to know whether a voice agent is genuinely solving customer problems?
5. How do you handle class imbalance in intent classification for short, spoken utterances?
6. Describe a time you improved a model already running in production. What signals told you it needed attention?
7. How would you design an A/B testing framework to compare two different conversation flows?
8. What is your approach to prompt engineering for a voice agent that must stay on topic and avoid going off-script?
9. How would you detect and handle hallucinations in LLM responses within a live voice call?
10. Walk me through how you would build a data pipeline to collect, transcribe, and label conversational data at scale.
11. What trade-offs do you weigh when choosing between fine-tuning a smaller model versus calling a large foundation model via API?
12. How would you approach anomaly detection on call data to flag unusual patterns in agent behavior?

Q: Walk us through how you would evaluate the quality of a voice AI conversation end to end.

*Situation:* At my previous company, we launched a voice bot for a telecom client and had no quality benchmarks beyond call completion rate.

*Task:* I needed to build an evaluation framework that could catch both technical failures and poor user experiences before they surfaced as complaints.

*Action:* I structured quality into four layers: ASR accuracy measured via word error rate on sampled transcripts, NLU correctness via intent match rate on labelled test sets, response relevance scored by a rotating human review panel, and outcome metrics including task completion rate and escalation-to-human rate. I automated the first two layers with nightly eval runs and set up a weekly human review of a random sample of calls.

*Result:* Within the first month, we caught a consistent ASR degradation on regional accent speech that the completion rate metric had completely masked. Fixing it reduced the escalation rate in that segment meaningfully. The framework became the standard eval process for every subsequent client launch.

---

Q: How do you handle class imbalance in intent classification for short, spoken utterances?

*Situation:* On a voice agent project, we had many intents to classify but a handful of high-frequency ones dominated the training data. Rare intents like 'dispute a charge' had very few labelled examples.

*Task:* I had to make the model reliably handle low-frequency but high-stakes intents without hurting accuracy on the common ones.

*Action:* I combined three approaches: weighted cross-entropy loss to penalise misclassification of rare intents more heavily, paraphrase augmentation to expand training data for tail intents, and a confidence threshold below which the model would ask a clarifying question rather than commit to a low-confidence prediction. I tracked per-intent F1 separately so improvements on tail classes were visible and not masked by overall macro averages.

*Result:* Tail-intent F1 improved substantially in our held-out evaluation. The fallback mechanism also reduced wrong-intent misroutes in production, which the client verified through manual call audits over the following two months.

---

Q: How would you detect and handle hallucinations in LLM responses within a live voice call?

*Situation:* We were building a healthcare information voice bot where a hallucinated drug name or dosage could cause real harm.

*Task:* I needed a practical hallucination guard that worked within the latency budget of a live call.

*Action:* I designed a two-stage approach. First, at prompt design time, I constrained the LLM to answer only from a retrieved context chunk using RAG, instructing it to respond with 'I do not have that information' when the answer was not in the retrieved text. Second, I added a lightweight post-generation classifier trained to flag responses containing high-risk entity types not present in the retrieved chunk. Flagged responses were replaced with a safe fallback script before being sent to TTS. I set up a monitoring dashboard to track the flagging rate across sessions.

*Result:* In staging tests, the guard caught the large majority of out-of-context responses. The client's compliance team approved the design and the product launched on schedule.

For evaluation and metrics questions: Start with the business outcome you want to move (customer satisfaction, task completion, cost per call), then map it to proxy metrics you can measure automatically (error rates, fallback rate, latency), then describe how you would collect ground truth and close the feedback loop. Interviewers want to see that you connect data to product decisions, not just report numbers.

For system design and ML architecture questions: Use a Problem-Approach-Trade-offs-Result structure. State the constraint clearly (latency budget, label scarcity, domain shift), walk through your chosen approach, name one alternative you considered and why you did not pick it, then close with how you would measure success. Naming trade-offs explicitly signals engineering maturity.

For behavioral questions: Use STAR (Situation, Task, Action, Result). Keep the Situation brief, spend most time on your specific Actions, and quantify the Result wherever possible. At a startup like Bolna, results that show speed and personal ownership land better than stories from large teams where your individual contribution is hard to isolate.

For open-ended product questions: Frame your answer as a hypothesis you would test. Say what signal would confirm your approach is working and what would make you change course. This iterative framing fits the startup environment Bolna operates in.

Bolna is an early-stage startup building at the frontier of voice AI, so interviewers typically look for a specific combination of traits rather than just strong textbook ML knowledge.

Comfort with ambiguity. Voice AI products generate noisy, partially labelled data at scale. Candidates who can define their own quality criteria and move forward without waiting for perfect ground truth consistently stand out.

Latency awareness. A model that performs well in a notebook but adds significant delay to a live phone call is a product problem. Showing that you factor inference time, model size, and real-time constraints into your design signals that you understand what you are actually building.

Product sense alongside technical depth. Interviewers want to see that you care whether the voice agent actually helps the end user, not just whether your evaluation metric improved. The ability to connect a technical choice to a user outcome is valued here.

End-to-end ownership. With 11 open roles, Bolna is a small team where you will own full pipelines rather than a single training step. Candidates who have shipped data collection, training, deployment, and monitoring end to end, and can speak to what broke and how they fixed it, are consistently valued.

Clear communication. Voice is the product, so how well you explain complex ideas out loud matters. Practise describing your work to a non-technical listener, not just fellow data scientists.

Week 1: Company context and ML fundamentals

Read Bolna's public documentation, product blog, and any available demos to understand how their voice agent pipeline works: ASR, NLU, LLM, and TTS. For each component, note one or two common failure modes and how you would detect them. Revise core ML concepts: classification, regression, evaluation metrics (precision, recall, F1, AUC), and cross-validation.

Week 2: NLP and voice AI depth

Go deep on the topics most relevant to this role: intent classification, named entity recognition, dialogue state tracking, and LLM prompting techniques. Practise explaining RAG clearly, including when and why you would use it. Spend time on applied topics: evaluating ASR output, fine-tuning a small LLM on domain data, and handling low-resource labelling scenarios.

Week 3: System design and mock interviews

Practise designing end-to-end ML systems. For each prompt, sketch the data pipeline, model choice, evaluation strategy, and monitoring plan. Do at least 3 mock interviews with a peer and review whether your answers were structured, concrete, and tied to outcomes. Focus extra effort on whichever areas feel weakest after those mocks.

Week 4: STAR stories, salary prep, and logistics

Prepare 5-6 strong STAR stories covering: improving a model in production, handling failure or unexpected data quality issues, shipping under time pressure, and working with ambiguous requirements. On compensation: current market data for Data Scientist roles in India shows 8-16 LPA at entry level (0-2 years), 18-30 LPA at mid level (3-5 years), and 30-48 LPA at senior level (6-9 years). Know your target band before you reach the offer stage.

Answering in theory without grounding in product reality. Saying 'I would use a transformer for intent classification' without discussing latency, model size, or how you would handle new intents post-launch signals academic thinking. Always connect your technical choice to the constraints of a live product.

Missing the voice-specific context. Candidates who prepare for generic data science interviews often overlook that Bolna's core challenge is real-time, low-latency AI on voice. Not mentioning ASR noise, spoken language disfluencies, or inference latency constraints makes you look underprepared for this role specifically.

Overcomplicating take-home tasks. Startup interviewers value clean, well-documented work over elaborate architectures. A clear notebook with a simple baseline, honest evaluation, and a thoughtful discussion of next steps beats a half-finished complex pipeline.

Not asking good questions. Bolna is early-stage, so asking about their current eval setup, the data they work with, and the biggest open problems shows genuine product curiosity. Candidates who treat the interview as one-directional often score lower on culture fit even when their technical answers are solid.

Underestimating behavioral rounds. Candidates who prepare only for technical questions are often caught off-guard by questions about ownership, navigating failure, and working through ambiguity. Prepare at least one clear story where something went wrong and you drove the resolution yourself.