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

VegaPay builds credit card infrastructure and embedded finance products for Indian banks, NBFCs, and fintechs. Their engineering team works on real-time credit decisioning, fraud detection, and transaction intelligence at scale. As of July 2026, VegaPay has 26 open roles tracked by knok, with ML engineering at the core of their product stack.

The broader market context: 803 ML Engineer roles are open across India as of July 2026. Bangalore leads with 165 openings, followed by Delhi (50), Hyderabad (27), Mumbai (15), Pune (14), and Chennai (14).

Candidates report a process that typically spans multiple rounds: an initial screening call, one or two technical rounds covering coding and ML concepts, and a final round with a senior team member or hiring manager. Rounds and their sequence can vary by team and seniority, so confirm the format with your recruiter after the screening call.

1. How would you build a real-time fraud detection system for credit card transactions?
2. Explain how you handle class imbalance in a credit default prediction dataset.
3. How do you approach feature engineering for financial transaction data?
4. Walk us through how you would monitor a deployed credit risk model for performance degradation.
5. What is your approach to building an explainable credit scoring model?
6. How would you design ML infrastructure to handle high-throughput transaction processing at scale?
7. Describe your experience with gradient boosting frameworks like XGBoost or LightGBM.
8. How do you calibrate a probability score from a risk model for business use?
9. What techniques do you use to detect and handle data drift in a production environment?
10. How would you A/B test two competing credit risk models in a live system?
11. How would you build a customer spend categorisation model across many merchant categories?
12. How do you balance model complexity with inference latency in a real-time decisioning pipeline?

Q: How did you handle class imbalance in a credit default prediction problem?

*Situation:* At my previous role, our training dataset for a default prediction model had a heavily skewed label distribution, which is typical in credit datasets per industry surveys, and standard accuracy metrics were giving a misleading picture of true performance.

*Task:* I needed to improve the model's ability to correctly identify actual defaults without flooding the operations team with unworkable volumes of false positives.

*Action:* I combined three approaches. First, I applied SMOTE on the training fold only, never the validation set, to oversample the minority class without inflating validation metrics. Second, I tuned the 'scale_pos_weight' parameter in XGBoost to reflect the actual class ratio. Third, I switched the primary evaluation metric to F1 on the minority class and plotted precision-recall curves to find a threshold the business team could act on.

*Result:* Minority-class recall improved compared to the baseline model, and the operations team confirmed false positive volume stayed within their review capacity. The approach was documented and reused for a later model in the same pipeline.

---

Q: Walk us through how you monitored a deployed ML model for drift.

*Situation:* A transaction risk model I deployed at a fintech started showing a slow rise in false negatives over several weeks after launch, and the issue was not caught until a manual audit flagged it.

*Task:* I needed a monitoring setup that would catch degradation automatically, without relying on periodic manual checks.

*Action:* I built a monitoring pipeline that tracked input feature distributions using Population Stability Index (PSI) on a rolling window, model output score distributions compared to a training baseline, and downstream business metrics like chargeback rates linked back to the model's decisions. Alerts fired automatically when PSI crossed a predefined threshold.

*Result:* The pipeline caught a seasonal shift in spending patterns before it materially hurt model performance. The team retrained on updated data and the alert resolved within the next evaluation cycle.

---

Q: How do you approach feature engineering for financial transaction data?

*Situation:* For a spend categorisation model, the raw transaction data consisted of merchant names, amounts, timestamps, and MCC codes, with inconsistent formatting across multiple data sources.

*Task:* I needed to extract signal from noisy text fields and build behavioural features that would generalise to merchants the model had not seen in training.

*Action:* I used TF-IDF and character-level embeddings on merchant name strings to handle spelling variants, combined with one-hot encoded MCC codes. For behavioural features, I computed rolling aggregates per customer over short and medium-term windows: spend velocity, category frequency, and deviation from each customer's personal baseline. All window aggregates were computed on the training period only to prevent data leakage.

*Result:* Categorisation accuracy on a held-out test set exceeded the previous rule-based system, and the feature pipeline ran within the latency budget for the batch scoring job.

STAR (Situation, Task, Action, Result): Use this for any behavioural or experience-based question. Keep Situation and Task brief (two to three sentences combined), spend the bulk of your answer on Action (specific tools, decisions, and reasoning), and close with a concrete Result tied to a business or technical outcome.

Problem, Approach, Trade-offs (PAT): For system design questions like 'design a fraud detection system', structure your answer as: (1) define the problem and constraints (latency, scale, label availability), (2) walk through your chosen approach and why, (3) name the trade-offs you considered and alternatives you rejected. This shows you think beyond a single solution.

'I would' anchored to 'I did': Interviewers at product fintechs like VegaPay typically value candidates who connect past experience to the specific problem at hand. When answering a hypothetical design question, briefly anchor it in something you have actually built: 'I would approach this like the pipeline I built at my last company, with one key change for the real-time latency requirement.'

Show calibration, not just metrics: When asked about model metrics or thresholds, show you understand the business context. Saying 'the right threshold depends on the cost of a false positive versus a false negative in this specific product' demonstrates the applied ML thinking that resonates with VegaPay's team.

VegaPay's ML team works in a domain where model outputs directly affect credit decisions and fraud losses. Candidates report that interviewers look for specific things beyond textbook ML knowledge.

Applied fintech intuition. Interviewers want to see that you understand why class imbalance, data leakage, and model calibration matter more in credit and fraud contexts than in many other ML domains. Generic ML knowledge without domain grounding typically does not go far.

System thinking. ML at a fintech like VegaPay does not stop at model training. Candidates who can discuss feature stores, real-time inference pipelines, model versioning, and monitoring tend to stand out in system design rounds.

Communication of trade-offs. Interviewers commonly ask follow-up questions to test whether you can explain why you chose one approach over another. Saying 'I used XGBoost because it handles missing values natively and is fast to iterate on' is stronger than just naming the algorithm.

Personal ownership. Candidates report that interviewers are interested in what you personally built and decided, not what the team did collectively. Be ready to speak in the first person about your specific contributions and the decisions you made.

Week one: domain and fundamentals. Review credit risk modelling concepts (probability of default, scorecard development), fraud detection system design, and class imbalance handling techniques (SMOTE, cost-sensitive learning, threshold tuning). Revisit gradient boosting internals (XGBoost, LightGBM) and be ready to explain key hyperparameters without looking them up.

Week two: system design and production ML. Practise designing an end-to-end ML pipeline for a fintech use case: data ingestion, feature engineering, training, serving, and monitoring. Be ready to discuss latency versus accuracy trade-offs in real-time inference, and study how feature stores work and when you would use batch versus online feature computation.

Week three: coding and project stories. Practise ML coding questions in Python (Pandas, NumPy, Scikit-learn). For each project on your resume, prepare a STAR story that covers what you built, what went wrong, and what you changed as a result.

Before each round. Read VegaPay's product pages to understand their core offering (credit card infrastructure for banks and NBFCs). Map the ML work you have done to their specific use cases: fraud detection, credit risk, and spend intelligence.

knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR on your behalf, so you can spend your prep time on the interview itself rather than the search.

1. Treating it as a pure research interview. VegaPay is a product company. Answers focused only on model accuracy without mentioning latency, data pipelines, or business impact typically miss what interviewers are looking for.

1. Vague ownership. Saying 'we built a model' without explaining your specific role is a common pattern. Interviewers follow up with 'what did you personally do?' and vague answers lower confidence quickly.

1. Ignoring data leakage. In fintech datasets, leakage is a real concern. Candidates who do not proactively mention time-based splits for temporal data and leakage checks in feature engineering raise red flags with experienced ML interviewers.

1. Over-engineering design answers. Some candidates propose unnecessarily complex architectures in system design rounds. Start with a simple design, state your constraints clearly, then add complexity only when the interviewer's follow-up questions call for it.

1. Not asking clarifying questions. For open-ended design questions, jumping straight into an answer without clarifying scale, latency budget, or label availability is a missed opportunity to show structured thinking.