Cresta Machine Learning Engineer Interview: Questions & Prep (2026)

Cresta builds real-time AI for contact centers, helping sales and support agents with live conversation guidance, automated coaching, and workflow automation. Their ML team works on natural language processing, large language models, and low-latency inference systems that surface recommendations mid-conversation. With 111 open roles currently tracked, Cresta is in an active hiring phase across engineering functions.

The broader Machine Learning Engineer market in India shows 803 active listings tracked by knok jobradar as of July 2026, with Bangalore leading at 165 openings, followed by Delhi at 50. This signals strong national demand for ML talent right now.

The ML Engineer role at Cresta sits at the intersection of applied research and production engineering. You are expected to own the full model lifecycle: from data exploration and experimentation through serving models to enterprise clients at scale. Candidates report the process typically includes a recruiter screen, a technical phone screen, a take-home assignment or live coding session, and a final loop covering system design and behavioural questions.

Preparation should focus on conversational AI, real-time ML serving, LLM fine-tuning, and the practical challenges of running ML in a B2B SaaS environment where reliability matters as much as accuracy.

These questions come up frequently based on what candidates report about the Cresta ML interview process.

1. How would you design a low-latency NLP pipeline that processes live agent-customer conversations in real time?
2. Cresta's product surfaces AI suggestions during active calls. How do you choose the right trade-off between model accuracy and inference speed?
3. Walk us through how you have fine-tuned or adapted a large language model for a specific domain or task.
4. How would you evaluate whether an AI coaching suggestion is actually helpful to a contact centre agent?
5. Describe how you would build a system to detect and classify customer intent during a streaming conversation.
6. How do you handle label noise and class imbalance in datasets where certain conversation patterns appear rarely?
7. Enterprise clients have strict uptime requirements. How would you ensure model reliability and graceful degradation in production?
8. Describe a time your model performed well on offline metrics but degraded after deployment. What happened and what did you fix?
9. How would you design a feedback loop that continuously improves model quality using signals from both agents and customers?
10. What is your approach to debugging a sudden drop in model performance after a code or data change?
11. Describe your experience with streaming inference or real-time model serving. What frameworks or patterns did you use?
12. How do you communicate model limitations and prediction confidence to a non-technical stakeholder or client team?

Use the STAR format for every behavioural question. Here are three worked examples.

Q: Describe a time your model worked well offline but degraded in production.

*Situation:* At my previous role, our intent classification model was hitting strong accuracy numbers on our held-out test set but started misclassifying a growing share of live customer queries within weeks of deployment.

*Task:* I was responsible for diagnosing the root cause and restoring production performance without a full retraining cycle.

*Action:* I added detailed logging to capture the raw input distribution in production versus training data. I found that a recent product launch had shifted the vocabulary customers were using, and that shift was not reflected in our training corpus. I curated a small set of representative new examples, ran targeted fine-tuning on a lightweight adapter layer, and set up a data drift monitor so future shifts would be caught early.

*Result:* Production accuracy recovered within a week. The drift monitor became a standing part of our ML ops checklist and caught two smaller vocabulary shifts in the following quarter before they became noticeable to users.

---

Q: Tell me about a time you balanced model quality with strict latency requirements.

*Situation:* We were building a real-time suggestion feature for a live chat product. The initial prototype used a full transformer model that delivered strong relevance scores but had end-to-end latency that made suggestions arrive after the agent had already moved on in the conversation.

*Task:* My task was to bring latency to an acceptable level without making suggestions noticeably less relevant for users.

*Action:* I ran a systematic ablation comparing the full model against distilled and quantised variants. I also profiled the serving stack and found that a synchronous database call in the inference path was adding unnecessary delay. I moved to an async cache lookup, switched to a quantised model variant, and set up an A/B test to measure whether relevance held up for real users.

*Result:* Latency dropped to a level users did not perceive as delayed, and relevance scores in the A/B test stayed within an acceptable margin. The approach became the template for two later features on the same team.

---

Q: Describe a time you designed a feedback loop to improve a model continuously.

*Situation:* Our conversation summarisation model produced good first-pass summaries but had no way to learn from the edits agents made before saving a summary to the CRM.

*Task:* I was asked to design a lightweight system that captured those edits and fed them back into the training pipeline on an ongoing basis.

*Action:* I built a diff-capture service that logged agent edits alongside the original model output and the conversation context. I added a quality filter to remove trivial edits and a deduplication step to prevent any single correction from dominating future batches. I then set up a weekly retraining job that mixed the new signal with the existing dataset using weighted sampling.

*Result:* After several retraining cycles, the share of summaries requiring no agent edits increased noticeably, which reduced average handle time and improved agent satisfaction scores on internal surveys.

For system design questions (pipeline design, inference architecture, feedback loops): start by clarifying the latency and throughput requirements, then describe data flow end to end before diving into individual components. Cresta operates in a real-time B2B context, so show that reliability and observability are first-class concerns from the start.

For ML depth questions (fine-tuning, evaluation, class imbalance): lead with your chosen approach and the reason for it, then walk through the trade-offs you considered. Interviewers want to see that you make deliberate decisions, not that you memorise a single correct answer.

For behavioural questions: use STAR strictly. Keep the Situation and Task brief (a couple of sentences each) and spend most of your time on Action and Result. Quantify results where you genuinely have numbers; if you do not, describe the directional outcome clearly.

For trade-off questions (accuracy vs speed, model size vs cost): present the trade-off space first, state the constraint that drives your choice, then commit to a recommendation. Interviewers at product-focused AI companies value engineers who can make a call over those who endlessly list options.

Production mindset over research polish. Cresta ships ML to enterprise clients with real SLAs. Interviewers look for candidates who think about monitoring, failure modes, and graceful degradation from the start, not as an afterthought.

Comfort with real-time and streaming systems. The core product works mid-conversation, so experience with streaming inference, low-latency serving, or online learning is a strong differentiating signal.

LLM pragmatism. You should be able to discuss fine-tuning, retrieval-augmented generation, and prompt engineering clearly, and know when each approach is the right tool. Candidates who only cite benchmark numbers without discussing deployment challenges tend not to advance past the technical round.

Cross-functional communication. Cresta's ML engineers work closely with product and customer success teams. Interviewers typically probe whether you can explain a model's limitations to a non-technical audience without being evasive or overly technical.

Ownership. Look for opportunities in your answers to show that you did not just contribute a component but drove a project or a decision end to end. Cresta candidates report that this ownership signal matters at every level.

Week 1: Foundations and company context
Read Cresta's published blog posts and any available writing on conversation intelligence and real-time NLP. Revisit transformer architectures, attention mechanisms, and how they are adapted for low-latency serving. Practice explaining your past ML projects out loud as STAR stories, with a clear result in each.

Week 2: System design and applied ML
Practice designing real-time ML pipelines on paper: start from raw audio or text, walk through feature extraction, model serving, and feedback loops. Review common approaches to LLM fine-tuning (LoRA, adapter layers, full fine-tuning) and when to use each. Prepare crisp answers to questions about evaluation metrics for conversational AI tasks such as intent detection and summarisation.

Week 3: Mock interviews and gap closing
Do at least a couple of full mock interviews covering one system design and one behavioural session. Record yourself if possible and review for vagueness or missing results in STAR answers. Revisit any technical areas where you felt uncertain and prepare concrete examples from your own experience for each question category listed above.

Candidates report that Cresta interviewers appreciate specific, grounded answers over theoretical ones, so tie every framework back to something you have actually built or debugged.

1. Skipping production considerations in system design. Many candidates design a strong model architecture but say nothing about monitoring, rollback, or serving infrastructure. At Cresta, production reliability is core to the product value proposition.

2. Over-indexing on benchmark accuracy. Talking about state-of-the-art results without discussing latency, cost, or real-user impact signals a research mindset that may not fit a product-focused ML team.

3. Vague STAR answers. Saying 'the model improved' without describing what changed for users or the business leaves interviewers with nothing concrete to evaluate. Even directional results ('agents spent less time editing summaries') are better than no result at all.

4. Not asking clarifying questions in system design. Jumping straight into an architecture without confirming scale, latency budget, and team constraints is a red flag. A good ML engineer scopes the problem before solving it.

5. Treating LLMs as a black box. Candidates who cannot explain how fine-tuning, retrieval, or prompt structure affects a model's production behaviour tend to struggle with Cresta's technical depth bar.

6. Ignoring the enterprise client angle. Cresta sells to large companies with data privacy requirements and SLA commitments. If you have experience in a B2B or regulated environment, bring it up explicitly.