polyai Machine Learning Engineer Interview: Questions, Experience & Prep (2026)

PolyAI builds enterprise voice AI agents that handle real inbound phone calls for industries like banking, hospitality, and retail. As an ML Engineer there, you own parts of the full pipeline: automatic speech recognition (ASR), natural language understanding (NLU), dialogue management, large language model (LLM) integration, and text-to-speech (TTS). The interview process typically runs 3-4 rounds covering a recruiter or hiring manager screen, a technical coding round, an ML system design discussion, and a final team or values interview. Candidates report strong emphasis on production ML experience, particularly around latency-sensitive speech and NLP systems, rather than pure academic knowledge.

PolyAI currently has 12 open Machine Learning Engineer roles. Across all companies in India, knok jobradar tracked 803 active ML Engineer listings as of July 2026, with Bangalore leading at 165 openings, followed by Delhi (50) and Hyderabad (27).

Candidates report these questions coming up most often in PolyAI ML Engineer interviews:

1. Walk us through how you would design an end-to-end voice AI pipeline for a contact centre use case.
2. How do you handle ASR errors in a downstream NLU or dialogue system?
3. Describe how you would fine-tune an LLM for a specific enterprise domain with limited labelled data.
4. What metrics would you use to evaluate the quality of a conversational voice agent in production?
5. How do you reduce latency in a real-time speech processing pipeline without sacrificing accuracy?
6. Explain the tradeoff between rule-based dialogue management and LLM-driven dialogue management.
7. How would you detect user frustration or intent to escalate during a call, and what would you do with that signal?
8. Describe a time you improved an ML model's performance after it was already deployed to production.
9. How do you approach data collection and annotation for training a domain-specific ASR or NLU model?
10. How would you handle out-of-vocabulary words or heavy regional accents in a speech recognition system?
11. What is your approach to A/B testing changes to a live voice agent without degrading the caller experience?
12. How would you build a system that handles multi-turn conversations where the user's intent shifts mid-call?

Q: Describe a time you improved an ML model's performance after deployment.

*Situation:* At my previous company, our intent classification model for a customer service chatbot was consistently failing on billing-related queries. The failure rate had grown noticeable enough that the product team escalated it to engineering.

*Task:* I was asked to diagnose and fix the problem without a full model retrain, since we had a release freeze in place.

*Action:* I ran error analysis on a sample of recent failed conversations and found that billing terminology had shifted after a product pricing change. I added a lightweight keyword-boosting post-processing layer and worked with the annotation team to label a targeted batch of new examples for a fine-tune during the freeze window. I also set up a daily dashboard tracking per-intent accuracy so the team could catch drift earlier in future.

*Result:* Misclassification on billing queries dropped meaningfully within a week, confirmed by both automated metrics and a manual review pass. The monitoring dashboard became a standard part of the team's weekly review process.

---

Q: How do you handle ASR errors in a downstream NLU pipeline?

*Situation:* On a voice bot project, our ASR output had significant errors on product names that were company-specific jargon not present in the base model's vocabulary.

*Task:* I needed to make the NLU layer robust to these errors without waiting for an ASR model update, which was on a longer release cycle.

*Action:* I introduced a normalisation step before NLU that used a custom vocabulary list with fuzzy matching to map common ASR confusions to the correct terms. I also experimented with feeding ASR N-best lists (multiple hypotheses) instead of just the top-1 transcript as input to the NLU model, giving the model more signal to work with under uncertainty.

*Result:* Entity recognition accuracy on product names improved noticeably on our held-out test set. The N-best approach also opened up a research direction the team explored in a follow-up sprint.

---

Q: How would you reduce latency in a real-time speech processing pipeline?

*Situation:* Our voice agent had a response delay that the product team described as 'too long to feel natural' during live demos, which was hurting stakeholder confidence before a key client presentation.

*Task:* I was asked to bring end-to-end latency below a threshold agreed with the product team.

*Action:* I profiled the pipeline and found two main bottlenecks: the ASR model running on CPU, and a blocking call to an external LLM service. I moved ASR inference to GPU with request batching, and restructured the LLM call to stream tokens and begin TTS synthesis before the full response was generated, so audio started playing sooner.

*Result:* Perceived response latency dropped significantly in internal testing. The streaming TTS change in particular made the agent feel far more conversational, which stakeholders noticed immediately in the next demo.

For system design questions (pipeline or architecture): Start by clarifying constraints: latency budget, supported languages, expected call volume, and failure tolerance. Then walk through each component in sequence (ASR, NLU, dialogue management, TTS), explaining your choice and the tradeoff you made at each step. PolyAI interviewers typically want to see that you understand where failures propagate in production, not just that you can name the right components.

For 'explain the tradeoff' questions: Use a simple structure: state what each option handles well, state where it breaks down, then give your recommendation for a specific context. Avoid naming a winner without context. PolyAI works across many enterprise verticals and interviewers value nuance over confident generalisations.

For ML improvement or debugging questions: Lead with how you would diagnose before proposing a fix. Interviewers want to see systematic thinking: look at the data first, run error analysis, form a hypothesis, test it cheaply, then scale. Jumping straight to 'I would retrain the model' signals shallow thinking and is a very common trap.

For product-sense or metrics questions: Name the metric, explain what it captures, then explain what it misses. For a voice agent, task completion rate tells you whether the call resolved correctly but says nothing about whether the experience felt natural. Showing awareness of metric limitations signals production maturity.

Based on what candidates report, PolyAI ML Engineer interviewers look for a few things beyond standard ML knowledge.

Production mindset: Can you ship and maintain ML systems in a live environment? Candidates who have only worked on offline experiments or notebook-based projects tend to struggle with PolyAI's emphasis on real-time, latency-sensitive systems. Come prepared to discuss monitoring, error propagation, and rollback strategies.

Depth in speech or dialogue ML: You do not need prior voice AI experience, but you should be able to reason about ASR, NLU, and dialogue systems at a technical level. Study these components even if your background is in a different ML domain, because interviewers will probe here directly.

Comfort with open-ended problems: Enterprise voice AI involves messy, accented, interrupted speech and unpredictable user behaviour. Interviewers want to see that you can structure your thinking around ambiguous problems without needing every constraint defined upfront.

Collaborative attitude: PolyAI is a smaller, fast-moving company. Candidates who come across as siloed or resistant to feedback tend not to fit. Show that you have worked across teams, shared findings openly, and iterated based on input from non-ML colleagues like product managers or QA engineers.

Week 1: Foundations and gap assessment
Review ASR fundamentals (CTC loss, attention-based encoder-decoder models, language model rescoring), NLU basics (intent classification, entity extraction, slot filling), and dialogue management approaches (state machines, end-to-end neural models, LLM-driven systems). If any of these areas are unfamiliar, spend the bulk of your time here before moving on.

Week 2: Production ML and system design
Practise designing ML pipelines end-to-end on paper. Focus on latency budgets, error propagation between pipeline components, and evaluation strategies for conversational systems. Reading public engineering blogs from conversational AI companies will expose you to real-world tradeoffs that textbooks skip over.

Week 3: Coding and applied ML problem solving
Practise Python coding questions covering sequence modelling, text preprocessing, and standard ML tasks. Brush up on PyTorch or whichever deep learning framework you have used most. PolyAI coding rounds typically focus on practical ML tasks rather than pure algorithm puzzles, based on what candidates report.

Week 4: Mock interviews and polish
Run at least two full mock interviews covering system design and behavioural rounds. Prepare 4-5 STAR stories from your own experience covering debugging, model improvement, and cross-team collaboration. Research PolyAI's published work and recent product news so you can speak specifically to why the role interests you.

Treating voice AI as just NLP: Candidates who skip ASR and TTS preparation and only study text-based NLP often get caught out. PolyAI's core product is voice, and interviewers expect you to engage with the specific challenges of speech, including latency, transcription noise, and real-time processing constraints.

Memorising theory without production context: Knowing how transformers work at a high level is not enough. Interviewers want to hear how you applied these concepts in real systems and, importantly, what went wrong and how you fixed it.

Skipping the reasoning in system design: Candidates who list components without explaining their choices come across as pattern-matchers rather than engineers. Always pair each design decision with the reasoning behind it, including what you considered and rejected.

Generic behavioural answers: Saying 'I improved model accuracy' without concrete context or a clear description of your specific contribution is a very common gap. Use specific details about the problem, your role, and the outcome, even if you cannot share exact metrics for confidentiality reasons.

Not asking questions at the end: PolyAI interviewers typically invite questions. Candidates who have nothing to ask signal low engagement. Prepare two or three specific questions about the team's current technical challenges, the deployment setup, or what success looks like in the first few months.