Data Analyst
How to Reduce Operational Costs Without Cutting Headcount — And Why Data Analysts Are Now at the Center of This Conversation
Swiggy reportedly reduced its delivery cost per order by over 18% in FY2024 — not by firing delivery partners, but by rerouting logic, renegotiating micro-cluster contracts, and optimising idle time windows. The people who built the dashboards that made those decisions possible were data analysts. In 2026, cost optimisation without headcount reduction has become the defining mandate for CFOs and COOs across India’s startup and enterprise ecosystem. If you are preparing for a data analyst role at any company that cares about unit economics — and they all do now — this topic is not optional. It is the interview.
What “Cost Reduction Without Cutting Headcount” Actually Means in 2026
For the last decade, when companies talked about cost reduction, the conversation quickly turned to layoffs. It was blunt. It was fast. And it created a lot of collateral damage — losing institutional knowledge, rebuilding after six months, and paying severance that often wiped out whatever savings were projected. By 2025, a different school of thought had taken hold, partly driven by the wave of high-profile layoffs that damaged employer brands badly enough to hurt hiring for years afterward.
The new approach is built on a simple premise: you already have the people. Can your data tell you where the waste is? This means looking hard at process inefficiencies, redundant vendor contracts, underutilised infrastructure, poor inventory forecasting, unnecessary re-work cycles, and bloated customer acquisition spend that does not convert. It means building models that identify where every rupee is going and whether it is producing a return. It means measuring the cost of inaction — what does it cost to not fix a leaky funnel? What does poor demand forecasting cost in overstock and spoilage?
For data analysts, this shift is enormously consequential. You are no longer being asked to produce weekly reports that sit in email inboxes. You are being asked to find money that the business does not know it is losing. That is a fundamentally different job description, and companies are interviewing for it with entirely different questions.
Most freshers prepare for cost-related questions as if they are accounting problems. They are not. They are prioritisation problems. An interviewer asking “how would you identify areas to reduce operational costs” is testing whether you know how to frame a business problem into a measurable analytical question — not whether you can list expense categories. Start with the metric, then trace it to a root cause. That framing alone separates you from 70% of candidates.
How This Trend Is Affecting Data Analyst Hiring in India Right Now
The job descriptions coming out of Zepto, PhonePe, Juspay, CRED, and Meesho in early 2026 carry a pattern worth noticing. Roles that would previously have been labelled “growth analyst” or “product analyst” are now showing language like “cost efficiency analytics”, “unit economics analyst”, and “operational intelligence”. This is not cosmetic. The scope has changed.
At Zepto, the pressure on dark store economics is immense — each store operates on a thin margin window and the difference between a profitable and loss-making store often comes down to whether inventory replenishment, staffing rosters, and order batching are optimised. Data analysts working on those problems are directly accountable to P&L outcomes. At PhonePe, merchant acquisition cost and support cost-per-ticket are the metrics that analysts are building systems around. At CRED, where the customer base is premium but the reward redemption economics are complex, analysts are tracking cost-per-engagement across every campaign type.
What this means for hiring is that companies want analysts who think in terms of cost drivers, not just data points. A candidate who can say “I would decompose the total cost into its variable and fixed components and then identify which variable cost has the highest elasticity to operational decisions” will get the callback. A candidate who says “I would make a dashboard” will not. The salary range for analysts who demonstrate this kind of business fluency now sits between 12 and 22 lakhs per annum at Series B and above companies, compared to 8 to 14 lakhs for more reporting-focused roles. That gap is widening.
Interview Questions This Topic Is Generating at Top Companies
Hiring managers at product-led and operations-heavy companies have shifted their case study rounds to focus heavily on cost leakage, unit economics, and efficiency measurement. These are not hypothetical questions anymore. They reflect actual problems the team is working on. The five questions below are drawn from reported interview experiences at companies including Flipkart, Razorpay, Swiggy, and Zepto in the last six months. Understanding the intent behind each question matters more than memorising an answer.
Start by decomposing the Rs 45 into its components — rider idle time, distance per order, re-attempt rate, failed delivery cost, and hub-to-customer routing efficiency. Each component has a different lever. The interviewer wants to see whether you can isolate the variable that is most controllable and has the highest cost impact. Do not jump to “optimise routes” as your first answer — that is what everyone says. Ask whether failed delivery attempts are tracked separately, because re-attempts are often the most expensive and most fixable cost in last-mile logistics.
This requires a query that joins a cost table with an order volume table, groups by vendor category and quarter, calculates percentage change using LAG() window functions, and then filters on both conditions simultaneously. The trap most candidates fall into is writing two separate queries and presenting them side by side instead of using a single CTE chain that computes both metrics in one pass. Interviewers at Razorpay and Flipkart have specifically noted that candidates who cannot combine conditions in one analytical query struggle with real data pipelines.
Use a two-by-two decomposition: volume effect versus cost-per-unit effect, and within cost-per-unit, break it into handle time, escalation rate, and resolution method (automated versus human). The 30% cost growth outpacing 10% volume growth means the cost-per-ticket itself rose, which narrows your investigation immediately. A strong answer will mention cohort analysis — are newer customers generating more complex tickets? — and channel mix shift — are more tickets being routed to expensive phone support versus chat?
The interviewer is testing whether you panic under pushback or hold your ground with evidence. The right answer involves three things: acknowledging their domain knowledge genuinely, walking through your methodology transparently so they can point to a specific flaw if one exists, and proposing a joint data validation session rather than a debate. If your analysis is correct, this approach will prove it. If there is a data issue — a misattributed cost code, a seasonal factor you missed — you want to find that before it reaches the CFO. Intellectual humility combined with methodological confidence is the answer.
Never impute or drop null vendor records without understanding where they come from. The first question is whether the nulls are random or systematic — if all nulls belong to one fulfilment channel or one date range, that is a data pipeline issue, not a data quality issue you can patch around. Present a two-step approach: audit the null pattern first, then decide whether to exclude, flag, or create a synthetic “unknown vendor” category. Dropping 8% of records without investigation can silently skew cost efficiency metrics for entire product lines.
When answering cost-related case study questions, always quantify the business impact of your recommendation before the interviewer asks. If you say “this would reduce re-attempt rate by 12%”, immediately follow it with what that means in rupees at their scale. Interviewers at operationally mature companies like Swiggy and Zepto are used to thinking in cost-per-unit terms, and candidates who speak that language fluently clear rounds much faster than those who stay at the level of percentages and trends.
SQL You Need to Know for Cost Optimisation Analytics
The most common SQL pattern in cost efficiency work involves comparing actual costs against a benchmark or historical baseline, identifying outliers, and surfacing which categories or time periods are driving the divergence. Companies like Juspay, Meesho, and Flipkart often give candidates a dataset of operational transactions in their SQL rounds and ask them to identify where costs are inefficient. The query below simulates a realistic scenario: you have a table of warehouse operations and you want to identify which warehouses are operating above the rolling average cost-per-unit dispatched over the last three months.
-- Identify warehouses where cost per unit dispatched exceeds the 3-month rolling average
-- This is a common pattern in operational cost review analysis
WITH monthly_costs AS (
SELECT
warehouse_id,
DATE_TRUNC('month', operation_date) AS operation_month,
SUM(total_operating_cost) AS monthly_cost,
SUM(units_dispatched) AS monthly_units,
ROUND(SUM(total_operating_cost) * 1.0 / NULLIF(SUM(units_dispatched), 0), 2) AS cost_per_unit
FROM warehouse_operations
WHERE operation_date >= DATEADD('month', -6, CURRENT_DATE)
GROUP BY warehouse_id, DATE_TRUNC('month', operation_date)
),
rolling_avg AS (
SELECT
warehouse_id,
operation_month,
cost_per_unit,
ROUND(
AVG(cost_per_unit) OVER (
PARTITION BY warehouse_id
ORDER BY operation_month
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
), 2
) AS rolling_3m_avg_cost_per_unit
FROM monthly_costs
),
flagged_warehouses AS (
SELECT
warehouse_id,
operation_month,
cost_per_unit,
rolling_3m_avg_cost_per_unit,
ROUND((cost_per_unit - rolling_3m_avg_cost_per_unit) * 100.0
/ NULLIF(rolling_3m_avg_cost_per_unit, 0), 1) AS pct_above_rolling_avg,
CASE
WHEN cost_per_unit > rolling_3m_avg_cost_per_unit * 1.15 THEN 'High Cost Alert'
WHEN cost_per_unit > rolling_3m_avg_cost_per_unit * 1.05 THEN 'Moderate Concern'
ELSE 'Within Range'
END AS cost_flag
FROM rolling_avg
)
SELECT *
FROM flagged_warehouses
WHERE operation_month = DATE_TRUNC('month', CURRENT_DATE)
AND cost_flag != 'Within Range'
ORDER BY pct_above_rolling_avg DESC;
The output of this query gives you a ranked list of warehouses that are most significantly above their own historical baseline — not just above a company-wide average. This matters because a warehouse in a metro will always cost more than one in a tier-2 city. Comparing each warehouse to its own trend removes that structural noise. When presenting this to a non-technical operations head, frame it as: “These three warehouses have become more expensive relative to themselves — something changed operationally in the last month that we need to investigate.”
Candidates often divide total cost by total units without guarding against zero-unit months using NULLIF, which causes a division-by-zero error that silently returns NULL or crashes the query depending on the database. In a cost analytics context, a zero-unit month is itself a signal worth flagging — it may indicate a warehouse shutdown or a data pipeline failure. Write NULLIF(units_dispatched, 0) every time you build a cost-per-unit metric, and add a separate flag for months where units are zero or suspiciously low.
Python for Cost Optimisation: What Analysts Actually Do
Beyond SQL, data analysts at companies like CRED and PhonePe use Python to build cost efficiency models that go beyond simple aggregation. A common task is decomposing the change in total cost between two periods into volume effect and rate effect — a technique called cost variance decomposition. This tells you whether a cost increase happened because you did more things (volume) or because each thing got more expensive (rate). The distinction completely changes what action you recommend. The scenario below uses a hypothetical support operations dataset from a fintech company.
# Cost Variance Decomposition Analysis
# Scenario: PhonePe-style support ops cost increase between Q3 and Q4
# Question: Did cost rise because of more tickets or more expensive resolution?
import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
# Simulated quarterly support cost data by ticket category
data = {
'ticket_category': ['Payment Failure', 'KYC Issue', 'Refund Request', 'Account Lock', 'General Inquiry'],
'q3_volume': [12000, 8500, 6200, 4100, 9800],
'q4_volume': [14500, 9200, 5800, 5300, 10200],
'q3_cost_per_ticket': [85, 120, 95, 140, 40],
'q4_cost_per_ticket': [92, 135, 95, 155, 42]
}
df = pd.DataFrame(data)
# Total cost per quarter per category
df['q3_total_cost'] = df['q3_volume'] * df['q3_cost_per_ticket']
df['q4_total_cost'] = df['q4_volume'] * df['q4_cost_per_ticket']
df['total_cost_change'] = df['q4_total_cost'] - df['q3_total_cost']
# Decomposition: volume effect uses Q3 rate, rate effect uses Q4 volume
df['volume_effect'] = (df['q4_volume'] - df['q3_volume']) * df['q3_cost_per_ticket']
df['rate_effect'] = (df['q4_cost_per_ticket'] - df['q3_cost_per_ticket']) * df['q4_volume']
# Sanity check: volume + rate effects should sum to total change
