What Machine Learning Is - and When a Query Is Enough for Interviews
A product manager opens a food-delivery dashboard and asks, "Which customers ordered biryani last month?" One SQL query answers it in seconds. Then she asks, "Which customers are likely to churn next week unless we intervene?" - and suddenly the old data must teach the system a pattern about the future.
- A query retrieves or summarizes known data; machine learning learns patterns from past data to predict, classify, rank, recommend, or detect anomalies.
- Use a query when the rule is explicit: "sales by city", "customers with no order in 30 days", "average delivery time by hub".
- Use machine learning when the rule is not obvious, the pattern is probabilistic, and the decision must improve from examples.
- Good ML needs labels or feedback, enough representative data, clear business value, and evaluation on unseen data.
- Do not build ML for vanity. If SQL plus business rules solve the problem accurately, ML adds cost, opacity, and monitoring burden.
- The interview-ready test: if the answer is already in the database, query it; if the answer must be inferred, learn it.
The Big Picture
Machine learning is not "advanced SQL". Think of data work as two different jobs: retrieving facts that already exist, and learning patterns that help decide what may happen next.
Core Explanation: Query First, Machine Learning Only When the Problem Deserves It
A query is an explicit request to retrieve, filter, join, or aggregate data from a database. It answers questions like "what happened?", "where did it happen?", and "how much?"
Machine learning uses examples to learn a relationship between inputs and outputs. It answers questions like "what is likely to happen?", "which option should be ranked higher?", "is this unusual?", or "which segment does this resemble?"
The cleanest managerial rule is simple: start with the simplest reliable method. Queries and business rules are transparent, cheap, and easy to audit. ML is justified only when the incremental improvement is worth the data, model, monitoring, fairness, and governance effort.
When a Query Is Enough
A query is enough when the business logic is deterministic: the answer follows directly from stored fields and clear conditions.
An e-commerce category manager asking "Which pin codes had the highest return rate last week?" needs a query, not ML. The strategic so what: the decision is descriptive and operational - the manager needs a ranked list to investigate, not a learned prediction.
When Machine Learning Is Worth It
Machine learning becomes useful when the relationship between inputs and the desired answer is too complex for hand-written rules, but historical examples can teach the pattern.
Definitions You Can Say in One Breath
Arthur Samuel: "Machine learning is the field of study that gives computers the ability to learn without being explicitly programmed."
Query: an explicit instruction to retrieve, filter, join, or summarize data from a database.
Model: a learned mathematical representation that maps input variables to an output, score, ranking, or cluster.
Feature: an input variable used by a model, such as recency of purchase, average order value, or device type.
Label: the known outcome used for training, such as churned or not churned, fraud or genuine, repaid or defaulted.
Training: fitting a model on historical examples so it learns patterns that generalize to new cases.
How to Judge Whether the ML Model Is Actually Good
If ML is used, it must be evaluated. A model that sounds impressive but fails on unseen data is worse than a simple query because it creates false confidence.
Worked example: suppose a model screens 10,000 transactions. It flags 200 as suspicious. Of these, 120 are actually fraud and 80 are genuine. It misses 30 fraud cases.
- Precision = 120 / 200 = 60%. Six in ten flagged cases are truly fraud.
- Recall = 120 / (120 + 30) = 80%. The model catches eight in ten fraud cases.
- False positive rate = 80 / 9,850 = 0.81%. Less than 1% of genuine transactions are wrongly flagged.
The managerial interpretation matters more than the math: if fraud losses are high and manual review capacity exists, this model may be valuable; if every false alarm blocks a loyal customer, precision may need improvement.
Case Study: Razorpay Uses ML Where Rules Alone Are Not Enough
Razorpay shows the query-versus-ML boundary clearly: payment dashboards need queries, but real-time fraud and risk decisions need learned pattern recognition.
Situation: Indian digital payments involve high transaction volume, varied merchants, different payment modes, and constantly changing fraud patterns. A finance or operations team can query failed payments by bank, settlement status by merchant, or refund volume by day. But "is this transaction risky right now?" is harder: fraudsters adapt, and suspicious behaviour may depend on many weak signals combined together.
The move: A modern payment platform such as Razorpay uses a layered approach. Queries and dashboards track known operational facts. Rule engines handle explicit conditions such as velocity checks or blocked patterns. Machine learning models can then score transaction risk using behaviour, device, merchant, and transaction signals. The primary driver is probabilistic pattern detection at transaction speed, supported by clean payment data, rule-based guardrails, monitoring, and human risk operations.
Outcome or lesson: The lesson is not "ML replaces queries". The lesson is that queries run the control tower, rules enforce known policy, and ML handles the hidden, adaptive part of the decision. This is the answer interviewers like because it is practical, not fashionable.
How AI Changes Machine Learning Versus Query Decisions
AI in 2026 does not remove the need to choose between a query and ML; it makes the boundary more important because teams can now build both faster.
- Natural-language BI lowers the query barrier. Tools can translate "show repeat purchase by city for the last 90 days" into SQL-like analysis, so many questions that earlier felt technical can stay in the query layer.
- AutoML speeds up modelling, but not problem framing. Platforms can test algorithms quickly, but they cannot decide the business cost of false positives, label quality, regulatory risk, or whether a simple rule is sufficient.
- LLM copilots help with features and monitoring. Teams use AI to brainstorm features, summarize model drift reports, and inspect anomalies, but production ML still needs validation, governance, and human ownership.
Use ChatGPT or Claude to practise the boundary decision: paste a business problem and ask, "Classify this as query, rule-based analytics, or ML. State the data required, the evaluation metric, and the simplest viable solution." Then challenge the answer with, "What would make ML unnecessary here?"
Interview Relevance
"Our app wants to identify customers likely to stop ordering. Would you solve this with SQL queries or machine learning?"
Say the sentence interviewers remember: "I would not start with ML. I would first prove that a query or simple rule is insufficient, then use ML if it improves decisions on unseen data."
Common Mistake
Calling every data-driven decision machine learning. It costs candidates because it shows weak business judgement and ignores implementation complexity. One-line fix: ask, "Is the answer retrieved from known data, or learned from examples to infer an unknown outcome?"
What to Revise Next
Revise Supervised versus Unsupervised Learning, With Examples next to understand the main types of ML problems. Then revise Train, Validation & Test Splits, and Cross-Validation so you can explain how a model is tested before being trusted.