Wipro Backend Developer Interview Questions
Backend work at an IT services company is often about a client's systems that already exist: batch jobs that run every night, old databases full of business rules, and services taken over from another team. Prepare to talk about making jobs safe to run again, moving logic out of old code in small steps, and fixing production problems inside a client's change rules. What to show here: safe changes to systems a client already depends on. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Wipro hires, in its own words, and its questions for every job →
1. Tell me about a ticket that kept coming back, where the quick fix worked each time but the problem returned. How did you get to the real cause?
- Describe the repeating problem and the usual quick fix.
- Explain how you noticed the pattern.
- Walk through how you found the root cause.
- Share the permanent fix and what happened to the ticket count.
“On a support project, a job that sent order files to a partner failed about once a week. The usual fix was to restart it, and the ticket was closed. I looked at the past tickets together and saw it always failed when the file was larger than normal. I traced it to a connection timeout that was too short for big files. I raised a change to send the file in parts and to retry only the failed part. After the change went in, we had your result. I now read old tickets as a group before I fix a new one.”
Weak answers are proud of how fast they restart things and never ask why the failure repeats.
2. Describe a time you took over a service from another team or vendor with only a short knowledge transfer. What did you do to be ready to support it alone?
- Set the scene: the service and the time you had.
- Explain what you asked for and recorded.
- Describe how you tested your understanding while help was still there.
- Share what happened in the first weeks alone.
“I once took over a billing service from a team that was moving to other work, with only a few sessions planned. I asked them to skip the slides and walk me through the last ten incidents instead, because those showed where the service really breaks. I recorded each session and wrote a runbook from it. Then I asked to handle live tickets myself while they watched, so gaps showed up early. I found two jobs nobody had mentioned. In the first weeks alone, your result. I learned that reverse shadowing teaches more than any document.”
Weak answers accept the documents as given and discover the gaps only after the old team has gone.
3. A nightly job loads a bank client's transaction file into a database and fails halfway. How do you design it so the support team can simply run it again?
- Give each file and each record a unique identity.
- Load in chunks and record a checkpoint after each.
- Make each insert safe to repeat.
- Reconcile counts and totals against the file at the end.
“I would make the job safe to repeat. Each file gets an id, and each record has a key from the source, so loading the same record twice updates it instead of adding a copy. The job works in chunks and saves a checkpoint after every chunk commits, so a rerun starts from the last good point. Bad records go to a reject table with a reason, and the rest continue. At the end, the job compares the row count and the total amount with the control line in the file. The support team then only needs one command: run again.”
Weak answers ask support to delete the loaded rows by hand before a rerun, or ignore duplicates.
4. A client's old application keeps most of its business rules in stored procedures. You are asked to move it to services in steps. How do you decide what moves first?
- Map the procedures, who calls them and how often they change.
- Pick a slice with clear edges and real value.
- Run old and new side by side and compare results.
- Switch callers over and retire the old piece.
“I would first list the procedures, what calls each one and how often each has changed recently. Rules that change often and cause the most tickets give the most value when moved. I would pick one with clear inputs and outputs, such as a fee calculation, and write it as a service with tests built from real past cases. For a while both run, and I log any case where the answers differ. Once they match, callers switch to the service and the old procedure is removed. Rules that never change can stay where they are for now.”
Weak answers propose rewriting everything at once or move code without comparing results against the old system.
5. A client's core system can only export files once a day, but their partners now want to ask for order status through an API. How would you design the layer in between?
- Load the daily export into a read store built for lookups.
- Expose an API over that store with clear freshness information.
- Handle late or missing files.
- Plan how to get fresher data later without changing the API.
“I would not let partners touch the old system. A loader takes each daily export, checks it and writes it into a read database shaped for lookups by order id and partner. The API reads from there and returns the status along with the time the data was last refreshed, so partners know how old it is. If a file is late, the API keeps serving the last good data and flags it as stale. Each partner sees only its own orders. Later, if the client adds change events, the loader can use them and the API stays the same.”
Weak answers pretend the data is live, or make the API query the old system directly on each call.
6. A query in a client's reporting database has become slow, and you are not allowed to change the schema without a long approval. What can you still do?
- Measure the query and read its plan.
- Rewrite the query itself: filters, joins, only needed columns.
- Check statistics and data growth.
- Prepare the schema change request with evidence in parallel.
“I would start with the plan to see where the time goes. Often the query itself can improve without touching the schema: filtering earlier, removing a function wrapped around an indexed column, or selecting only the columns the report shows. I would check that table statistics are current, because a stale picture leads to a bad plan. If old data is rarely read, I might ask the report to default to a shorter period. In parallel I would prepare the request for the index I really want, with before and after timings from a test copy, so approval is easier.”
Weak answers either make an unapproved change in production or say nothing can be done until approval comes.
7. Your fix for a defect is ready and tested, but the client's next change window is days away and users are affected now. What do you do?
- Measure who is affected and how badly.
- Offer a workaround that needs no release.
- Raise an emergency change through the proper path if the harm justifies it.
- Keep users and the client informed until the fix is live.
“I would first put facts together: how many users are hit, what they cannot do, and whether data is at risk. Then I would look for a workaround that needs no release, such as a manual step or a setting, and share it with the service desk. If the harm is serious, I would ask my lead to raise an emergency change with the client, with the test evidence and a rollback plan attached. The client decides, not me. If they prefer to wait, I respect that and keep the workaround supported. I would never slip the fix in quietly.”
Weak answers deploy outside the window without approval, or shrug and wait without offering a workaround.
8. Why do you want to do backend work at Wipro, where much of the code you touch was written by others for a client?
- Say what you find satisfying about improving existing systems.
- Connect it to client work across industries.
- Give one example from your own experience.
- Say what you want to learn next.
“I enjoy the kind of backend work where a system already carries real business and my job is to make it safer and faster without stopping it. Wipro delivers IT services to clients in many industries, so I would see banking jobs, supply systems and more, each with its own rules. In my current role, the change I am most proud of is not a new feature but a batch job that stopped failing at night. I want to get better at modernising old systems in steps, and client projects like these are where that skill is built.”
Weak answers say they only want to build new things from scratch, which does not match much of the work.
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.