Infosys Data Analyst Interview Questions
Data analysts at Infosys often work inside a client's digital business, such as a retailer's online store or a telecom operator's customer base, where the questions are about shoppers who come back, customers who leave, promotions and experiments. Prepare to explain a finding that changed a plan, definitions that differ between systems, cohort queries, churn signals, experiment results and a spike that was not real. What to show here: clear answers about customers, built from data you have checked. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Infosys hires, in its own words, and its questions for every job →
1. Tell me about an analysis that changed a client's plan for a promotion or a campaign. How did you make the finding convincing?
- Describe the plan and the question you were asked.
- Explain what the data showed.
- Share how you presented it and handled doubts.
- Give the result.
“A retail client planned to send a discount to all customers who had not bought in six months. I looked at past campaigns of that kind and found that most of the orders came from customers who would have bought anyway that month, judging by their past pattern, while the truly lapsed customers rarely responded. I showed this with a simple chart of response by months since last purchase, and suggested a smaller group and a holdout so we could measure it properly. The marketing lead was doubtful, so we ran it that way once. The result was your result.”
Weak answers describe a report that was sent and never acted on, or cannot say what decision changed.
2. Describe a time two of a client's systems defined the same thing differently, such as an active customer, and your numbers were challenged because of it.
- Describe the two definitions and where they came from.
- Explain how you discovered the difference.
- Share how you got agreement on one definition.
- Say how you documented it.
“At a telecom client, the billing system counted a customer as active if they had a valid plan, while the app team counted anyone who had opened the app in the last month. My churn figure was challenged because it did not match the app team's dashboard. I traced both numbers to their queries and laid the definitions side by side with the size of the difference. We agreed that the billing definition would be used for churn and the app definition renamed to engaged users. I wrote both into a shared glossary with the query for each. The result was your result.”
Weak answers defend their own number without checking the other, or leave two definitions living side by side unnamed.
3. A retailer wants to know how many customers who bought during the festival sale have bought again since. Describe how you would write that query.
- Select the distinct customers with an order in the sale window as the cohort.
- Join their later orders after the window ended.
- Count distinct customers with at least one later order.
- Consider returns, cancelled orders and multiple orders per customer.
“First I would build the cohort: distinct customer ids with a completed order between the sale start and end dates. Then I join the orders table again for orders by those customers with a date after the sale ended. I count distinct customers in that second set and divide by the cohort size to get the share who came back. Cancelled and fully returned orders should be excluded from both steps, or the numbers flatter the sale. Using COUNT(DISTINCT customer_id) matters, because one customer with five later orders is still one returning customer. I would also break the result down by weeks since the sale.”
Weak answers count orders instead of customers, or include the sale orders themselves as returns.
4. A telecom client wants an early warning of customers likely to leave. Which signals would you look at, and what mistakes would you guard against?
- Define what leaving means for prepaid and postpaid customers.
- List signals: falling usage, complaints, failed recharges, plan changes.
- Guard against leakage: signals that only appear after the decision.
- Check base rates and what action the client can take.
“First I would define leaving separately for prepaid and postpaid customers, because a prepaid customer simply stops recharging while a postpaid one cancels. Then I would look at signals in the weeks before: usage dropping compared with the customer's own past, repeated complaints, failed recharges, and checking competitor offers where that is known. I would be careful with signals that appear only after the decision, such as a port-out request, because they predict nothing useful. I would also check how rare leaving is, so a warning list is not mostly false alarms, and ask what the client can actually offer a flagged customer.”
Weak answers jump to a machine learning model, or use signals that occur after the customer has already decided.
5. An experiment on a client's product page shows a clear lift in the first three days, then the lift fades. How do you interpret this, and what do you tell the client?
- Explain novelty and weekday effects as possible causes.
- Insist on running through full weekly cycles.
- Look at new versus returning visitors separately.
- Report the overall result with its uncertainty, not the best days.
“An early lift that fades often means novelty: returning visitors notice something new and click, then stop. It can also be a weekday effect if the test started on a strong day. I would not report the first three days. I would run the test through at least two full weeks so every weekday appears in both versions, and look at new and returning visitors separately, since new visitors do not feel novelty. Then I report the full period result with its uncertainty. If the lift is real only for new visitors, that is still useful and I would say so plainly.”
Weak answers stop the test early on the good days, or report the peak lift as the expected gain.
6. You have an events table with page views, add-to-cart and order events, each with a session id and time. Describe how you would build the funnel from product view to order, and what could distort it.
- Reduce events to one row per session and step, keeping the first time of each step.
- Require the steps to happen in order within the session.
- Count sessions reaching each step.
- Remove duplicate events, bot traffic and internal testers.
“For each session I would find the earliest time of each step: first product view, first add to cart, first order, using GROUP BY session and a MIN on time for each event type. Then a session counts as reaching a step only if that step happened after the previous one. Counting sessions at each step gives the funnel. Distortions are common. Duplicate events from double clicks or retries inflate early steps, bot traffic adds views with no orders, and the client's own testers place orders. I would filter those first and check that the order count matches the orders table.”
Weak answers count raw events per step without tying them to sessions, or ignore duplicates and bots.
7. A sales dashboard for a client shows a huge spike in orders yesterday, and their leadership is excited. Before anyone celebrates, what do you check?
- Check for duplicate loads or a feed that ran twice.
- Look at the orders themselves: values, customers, products, times.
- Check for test orders or a system change.
- Tell the client what you found quickly and plainly.
“A spike that nobody planned is usually a data problem, so I would check the pipeline first: did the order feed load twice, or did a late batch from earlier days land in yesterday. Then I would look at the orders themselves. If many have the same tiny value, the same few customers, or arrived in one minute, they may be test orders from a release or a bot. I would compare against the order system directly, not the warehouse. If the spike is real, I would look for a cause such as a promotion. Either way I would tell the client within the hour what I know and what I am still checking.”
Weak answers forward the good news first and check later, or dismiss the spike without looking at the orders.
8. Why do you want to work as a data analyst at Infosys, on the customer data of client companies?
- Say what you enjoy in analysis.
- Tie it to client businesses such as retail and telecom.
- Link to your experience.
- Say what you want to learn.
“I enjoy questions about customers: who comes back, who leaves, and whether a change actually made a difference. At Infosys I would answer those questions for client companies such as retailers and telecom operators, sitting close to the people who decide on promotions and products. I like that the answer has to be usable by a marketing lead, not only correct. I have worked on cohort and funnel analysis for an online store and learned how easily a definition or a duplicate feed can mislead. I want to learn how different industries ask the same questions differently.”
Weak answers talk about tools and dashboards only, or show no curiosity about the client's customers.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.