Wipro Frontend Developer Interview Questions
Frontend work at an IT services company often means improving screens that a client's staff already use all day: call centre forms, claims screens, internal portals. Prepare to talk about replacing old pages one at a time, building for browsers a client's IT policy controls, keeping heavy data entry fast, and testing many screens so a fix in one place does not break another. What to show here: respect for the people who use a client's screens daily. 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 time you rebuilt an old screen and the people who used it every day did not want the new one. What did you do?
- Describe the old screen and why it was rebuilt.
- Explain what users disliked and how you found out.
- Share what you changed and what you kept.
- Give the result.
“I rebuilt an order entry screen that staff had used for years. My version looked cleaner, but users said it was slower. I sat with two of them and saw why: they never used the mouse. The old screen let them tab through fields in a fixed order and press one key to save. Mine had broken that order. I restored the tab order, added the same shortcut keys and kept field positions close to the old layout. After that, your result. I learned that for daily users, speed of habit matters more than a modern look.”
Weak answers say users just needed time to adjust and never watched how they actually worked.
2. Describe a time an accessibility review found problems in screens you had built. How did you respond?
- Describe the review and what it found.
- Explain how you grouped and fixed the findings.
- Share how you tested the fixes.
- Say what you changed in your daily work.
“A review of an internal portal I had worked on found that several forms could not be used with a keyboard alone and that error messages were not read out by screen readers. I was surprised, because the screens looked fine to me. I grouped the findings by cause and found most came from a few shared components, so fixing those fixed many screens at once. I tested each fix with the keyboard only and with a screen reader. Since then I check tab order and labels before I raise any pull request. The outcome was your result.”
Weak answers treat the findings as someone else's checklist or fix each screen by hand without finding the shared cause.
3. You are replacing a client's old internal application one page at a time while the old pages stay live. How do you make old and new pages feel like one application?
- Route each address to the old or the new application from one entry point.
- Share the login session between both.
- Match navigation and styles so users do not feel a jump.
- Switch pages over one by one with an easy way back.
“I would put one entry point in front of both applications that sends each address to the old or the new code. The user signs in once, and both sides read the same session, so moving between pages never asks for a password again. The new pages reuse the same header, menu and colours, even if the old look is not what I would choose, because a sudden change mid-task confuses people. Each page moves over behind a switch, so if the new one has a problem we point the address back to the old page within minutes.”
Weak answers plan one large switch at the end, or let users notice two logins and two different menus.
4. A client's staff must use an older browser that their IT team controls, and you cannot ask them to upgrade. How does that change the way you build?
- Get the exact browser and settings the client uses.
- Configure the build to target it and add only needed polyfills.
- Avoid features with no fallback, or provide one.
- Test on that browser in the pipeline and by hand.
“I would first ask for the exact browser version and any locked settings, then set that as the target in the build tool so the output code runs there. Newer language features get compiled down, and I add polyfills only for what we use, to keep the bundle small. For layout, I check each feature I want and write a simple fallback where the browser lacks it. Most important, that browser goes into our test pipeline and onto at least one real machine, because what works on my laptop proves nothing about the client's desks.”
Weak answers build for the newest browser and hope, or complain that the client should simply upgrade.
5. Call centre agents fill in a long customer form many times a day while talking to the customer. How would you build that form so it is fast and never loses what they typed?
- Make every action possible from the keyboard in a sensible order.
- Validate as they go without blocking typing.
- Save drafts locally and restore them after a refresh or timeout.
- Keep the form responsive by updating only what changed.
“The agent is talking while typing, so the form must never make them wait or look away. I would keep a clear tab order, shortcut keys for common actions and fields that accept pasted values. Validation runs when they leave a field and shows a small message next to it, never a pop-up that steals focus. Every few seconds the form saves a draft in the browser, so a refresh or a session timeout brings the text back. I would also keep each field's state separate, so typing in one box does not redraw the whole long form.”
Weak answers validate only on submit, rely on the mouse, or lose the whole form when the session expires.
6. A client's application has a large number of screens, and fixes in shared components keep breaking screens nobody retested. What would you automate, and what would you leave to people?
- Unit test shared components where most breakages start.
- Add a small set of end-to-end tests for the journeys the business cannot lose.
- Use visual comparison for layout on key screens.
- Leave rare screens and new features to manual checks.
“I would start where the breakages come from, the shared components, and give each one unit tests for its states. Then I would pick the handful of journeys the client cannot afford to lose, such as creating an order, and cover those with end-to-end tests that run on every build. For layout, screenshot comparison on key screens catches a button that moved. I would not try to automate every screen, because tests for rarely used pages cost more to maintain than they save. Those stay on a manual checklist that a tester runs before a release.”
Weak answers want to automate everything through the browser, or rely fully on manual retesting.
7. A user at the client reports that a button does nothing on their screen, but it works on your machine and in the test environment. How do you investigate?
- Collect details: browser, role, data, exact steps, time.
- Look at client-side error logs for that user and time.
- Recreate their conditions, including permissions and data.
- Fix, confirm with the user and add a test.
“I would not close it as cannot reproduce. I would ask for the browser, the user's role, the record they had open and the time it happened, plus a screen recording if they can. Then I would check our client-side error logs for that user and moment. In my experience these cases come from data or permissions: a field that is empty only for that record, or a role that hides something the script expects. I would copy those conditions into the test environment. Once I find the cause, I fix it, confirm with the user and add a test for it.”
Weak answers tell the user to clear their cache and close the ticket without looking at logs or data.
8. Why do you want to build front ends at Wipro, where many of the users are a client's own employees and not the public?
- Say what you like about building for people who use a tool all day.
- Link it to client work across industries.
- Give an example from your own work.
- Say what you want to get better at.
“I like building screens for people who use them for hours every day, because small improvements add up for them. If I save an agent a few seconds on a form, that matters across a whole shift. Wipro delivers IT services to many client companies, so I would work on claims screens, order systems and portals in different industries. The work I enjoyed most so far was making an old form quicker for its users, not building a landing page. I want to get better at modernising old front ends without disturbing the people who depend on them.”
Weak answers only talk about trendy frameworks and see internal business screens as boring.
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.