ML Engineer Career Guide: Shipping Models to Production in India

Training a model that looks good in a notebook is the part most courses teach. Keeping it retrained on fresh data, served inside a latency budget, watched for drift, and safe to roll back is the part companies hire ML engineers for. What follows covers the daily work, the tools Indian postings name and why they matter, how interviews probe production judgement, and how to prove it on a resume.

What an ML engineer owns, and where the role stops

An ML engineer owns the path from raw data to a prediction that another system consumes, and gets paged when it breaks. Typical problems: ranking a feed or search page, scoring payments for fraud, forecasting demand, and estimating credit risk. Your neighbours are data scientists who prototype, data engineers who own source pipelines, backend engineers who call your model, and a platform team that runs the clusters.

Here is how a week on a payments risk team might go:

• Monday. The nightly training run failed because an upstream column changed type. You fix it and add a schema check so the next change stops the run early.
• Tuesday and Wednesday. You move a data scientist’s prototype from a notebook into the pipeline, rewriting feature code so training and serving compute each feature identically.
• Thursday. Online precision has dropped while offline metrics look fine. One feature is empty for new users at serving time but was backfilled in the training data.

How it differs from data science. A data scientist’s output is usually a decision: which model, which features, whether an experiment worked. Yours is a system that keeps producing correct predictions after everyone has moved on. Small companies often merge the two jobs, so read a posting’s responsibilities, not its title.

Where AI engineering differs. ML engineers usually train models on the company’s own data, such as transactions or clicks, and own the pipeline that retrains them. AI engineers mostly build product features on models someone else trained, often through an LLM API. The line blurs when an ML team fine-tunes or hosts open-weight language models, which is generative AI engineering territory.

Skills and tools in ML engineer postings, and why each one matters

The baseline is solid software engineering plus enough ML to recognise a result that is too good to be true: production-quality Python (packaging, tests, logging), SQL, Spark or a similar engine, Docker, Git with CI, and one cloud. For modelling, expect classical algorithms, gradient-boosted trees such as XGBoost and LightGBM for tabular data, and a deep learning framework. PyTorch is the usual choice for new work, though TensorFlow still runs many production systems.

Tool or skill	Why it matters in the job
MLflow	Experiment tracking and a model registry, so you can say which code and data produced the model in production.
Kubeflow Pipelines or Airflow	Scheduled retraining with retries, logs, and lineage, instead of someone rerunning a notebook.
SageMaker or Vertex AI	Managed training, endpoints, batch prediction, and pipelines. Many enterprises and GCCs standardise on one.
A feature store such as Feast	Point-in-time correct training data and identical feature values offline and online.
Triton, TorchServe, KServe, or FastAPI	Online serving with versioning, request batching, and health checks.
Evidently, or custom checks in Prometheus and Grafana	Catching input and prediction drift before the business does.

Three ideas come up again and again in interviews:

• Batch versus online serving. Batch scoring runs on a schedule and writes predictions to a table: cheap, easy to debug, and right for churn scores or next-day forecasts. Online serving answers each request in real time, bringing latency budgets, autoscaling, and request-time feature lookups. Panels notice candidates who choose batch when batch is enough.
• Point-in-time correctness. If a training row for a payment on 3 March uses a risk flag set on 10 March, the model learns from the future and disappoints in production. Feature stores exist largely to prevent this, and to serve the same feature definitions online.
• Drift and delayed labels. Data drift is a change in inputs, such as order sizes shifting after a new city launch; concept drift is a change in the relationship you modelled, such as fraudsters changing tactics. Confirmed fraud labels can take weeks, so teams watch score distributions and alert rates meanwhile.

The market snapshots on uHired’s role and location pages show which skills appear most often in current postings.

How expectations grow with experience, and what titles mean

0–2 years. Fresher ML engineer openings exist but are fewer than general software roles, so many people start as software or data engineers on an ML team, or convert an internship. Expect to write clean, tested Python, train and evaluate a model end to end, and work inside an existing pipeline without breaking it.

3–5 years. A model or pipeline becomes yours: retraining cadence, monitoring, on-call, rollouts, and the argument with product about which metric matters. Be ready to describe a past incident and what you changed afterwards.

6+ years. You design for several teams: the shared training and serving platform, managed-versus-open-source choices, release standards, and hiring.

Product companies use ML Engineer, Senior, Staff, and Principal, sometimes as numbered levels or an ML track in the SDE ladder. Services firms tend to use generic designations such as Senior Software Engineer or Consultant, with AI/ML as your practice rather than your title. GCCs usually mirror the parent company’s global ladder, so one title can mean different scope in different centres. The setting matters as much as the title:

• Services companies: client proofs of concept and deployment under each client’s cloud rules; broad exposure, less depth.
• Product companies: one family of models in depth, online experiments, and on-call for what you ship.
• GCCs: platform and governance work; banking and insurance centres often require formal model validation before release.
• Startups: you are also the data engineer and half the backend team.

How ML engineer hiring usually runs

1. Recruiter screen. Notice period, stack, location, and whether your models reached production. “Worked on ML” gets filtered; be specific.
2. Coding. Data-structures problems at many product companies, practical Python elsewhere, or a take-home to train and serve a small model with tests; Take-Home Assignments covers scoping one.
3. ML fundamentals. Trade-offs, not definitions: class imbalance, leakage, regularisation, metric choice, calibration.
4. ML system design. One open problem for 45 to 60 minutes, judged largely on how you frame it before drawing boxes.
5. Project walkthrough. The panel picks a project from your resume and asks until they find the edge of your knowledge. Lead with the one you can defend.
6. Hiring manager. Incidents, metric disagreements with data scientists, and balancing platform work against feature requests.

Interview questions that test production judgement

Before any design question, state four things: the decision the model drives, the latency budget, how and when labels arrive, and what the product does when the model is unavailable. Candidates who skip the last one design systems that take checkout down with them.

1. Your fraud model shows an excellent ROC-AUC offline, yet the risk team says it catches less than the old rules. What do you check first?
2. Design real-time fraud scoring for UPI payments in a payments app, with a tight latency budget and fraud reports that arrive weeks later.
3. Design the “restaurants you might like” row on a food-delivery home screen, including cold start for new users and new restaurants.
4. Score distributions shifted sharply during a Diwali sale. How do you tell seasonal drift from a broken upstream join?
5. Write a time-based train and validation split for transaction data, and explain why a random split would flatter the model.
6. Walk through a safe rollout of a new model version: shadow mode (scoring live traffic without acting on it), canary, and rollback criteria.
7. Why might gradient-boosted trees beat a neural network on a tabular dataset, and when would you still try the network?

On the first, a strong answer notes that ROC-AUC flatters models when fraud is rare, then checks precision and recall at the live threshold, leakage, training-serving skew, and both systems on the same weeks of traffic. On the recommender, panels expect cheap candidate generation before a heavier ranker, and offline metrics such as recall at k kept distinct from online ones such as orders.

Resume bullets that prove a model reached production

Panels skim for production context: data volume or traffic, latency, retraining cadence, what broke, and what you changed. These three made-up examples show the shape; use your own real figures.

• Example: “Replaced manual monthly retraining of a credit-risk model with a weekly Kubeflow pipeline that validates input data and requires sign-off in the MLflow registry; failed runs now alert the team instead of quietly shipping a stale model.”
• Example: “Cut p95 inference latency of a search-ranking model from 140 ms to 45 ms by exporting it from PyTorch to ONNX and serving it with TensorRT on Triton; the higher throughput freed two of six GPU nodes.”
• Example: “Moved fraud features into Feast so training and serving share one definition, fixing a skew bug that had lowered recall for new users after launch.”

Common mistakes:

• Calling a Streamlit demo “deployed”. Call it a demo; interviewers will ask about traffic and on-call.
• Quoting accuracy on an imbalanced problem. Give precision and recall at the operating threshold, against the previous baseline.
• Listing every library you have imported; panels pick one and probe.
• Leading with Kaggle rankings for a production role. Keep them as a supporting line.

Getting into ML engineering, and growing once you are in

The shortest route is usually from software engineering: add ML fundamentals, evaluation, and one pipeline tool, then volunteer for serving or retraining work on your company’s ML team. Data scientists need the reverse: tests, packaging, Docker, CI, and on-call. Data engineers add modelling to pipelines they already know. Good projects show failure handling as well as training:

• A retraining pipeline that fails safely. Take a public dataset with timestamps, such as city taxi or bike-share trips, retrain weekly with Airflow, register models in MLflow, then introduce a schema change and show validation stopping the run.
• A recommender served two ways. Train a matrix factorisation or two-tower model on MovieLens, serve candidates from an approximate nearest-neighbour index behind FastAPI, load-test it, and compare it with a nightly batch version in the README.
• A drift drill. Simulate a distribution shift, show the alert firing, and write a one-page incident note covering cause, impact, and fix.

Growth usually branches into ML platform work, applied ranking and recommendations, or generative models. Read the data scientist guide if modelling appeals more than plumbing, the AI engineer guide for LLM features in products, or the generative AI engineer guide for fine-tuning and hosting open models.

Find openings and plan the next seven days

Current listings: Bengaluru, Hyderabad, Pune, across India, and remote. Then, this week:

1. List the tools five postings name, and mark those you could defend for ten minutes.
2. Rewrite your two strongest bullets so they state production context and a result.
3. Answer one system design question aloud against a timer, opening with the four framing points above.
4. Give one project a README that explains how to run it and what happens when it breaks; What to Put on GitHub and in a Portfolio covers the rest.
5. Plan the following weeks with A Four-Week Technical Interview Preparation Plan.