sarvam Product Designer Interview: Questions, Experience & Prep (2026)

Sarvam AI is building India's own foundational AI stack, from speech recognition across multiple Indian languages to large language models trained on Indic data. The company is growing fast: as of July 2026, Sarvam has 68 open Product Designer roles, making it one of the most active AI startup hirers for designers right now.

Designing at Sarvam means working on problems most designers have never faced. Your users may switch between Hindi and English mid-sentence. They may rely on voice because reading small text is difficult. The product surface could be entirely conversational, with no traditional buttons or menus. If that excites you, this is a genuinely rare opportunity.

The interview process typically runs 3-4 rounds, candidates report. Expect a portfolio walkthrough, a design challenge (take-home or live) based on real Indian user scenarios, and at least one conversation about your design thinking and how you work within technical constraints. Sarvam interviewers are known to push into your reasoning, not just admire your visual output.

Across India right now, there are 393 open Product Designer roles, with Bangalore at 62 openings, Delhi at 33, and Mumbai at 13.

These are the questions candidates most commonly report facing in Sarvam Product Designer interviews. Prepare a concrete example or a clear point of view for each.

1. Walk us through a project where you designed for a user who was not comfortable reading text.
2. How would you design a voice-first onboarding flow for a new Sarvam product aimed at rural users?
3. Sarvam's AI models sometimes make mistakes. How do you design for graceful error recovery in a voice or conversational interface?
4. Tell us about a time you worked closely with an ML or engineering team. How did their constraints shape your design decisions?
5. How do you approach user research when your target users speak a language you do not speak fluently?
6. How would you measure whether a voice AI feature is actually useful for a Hindi-speaking user in a Tier-2 city?
7. Describe a situation where you had to simplify a complex multi-step flow. What did you cut, and why?
8. How do you think about trust and transparency when designing AI-powered features? How do you communicate to users that the AI is speaking?
9. You have two weeks to design a proof-of-concept for a new Indic-language product. Walk us through your process.
10. What does 'AI-native design' mean to you, and how is it different from designing a traditional mobile app?
11. Tell us about a design decision you made that was later proven wrong by data. What did you do next?
12. How would you design for users who switch between two languages mid-conversation (code-switching)?

Q: Tell us about a time you worked closely with an ML or engineering team to shape a product feature.

*Situation:* At my previous company, we were building an auto-reply feature for a customer support tool. The ML team had trained a model that suggested replies, but the suggestions were sometimes awkward or off-tone.

*Task:* My job was to design the interface through which support agents would review and use these suggestions, while also helping capture feedback to improve the model over time.

*Action:* I spent two weeks working alongside the ML team, learning what confidence scores meant and what made the model uncertain. I designed a UI that surfaced suggestions differently based on confidence level: high-confidence replies appeared inline and ready to send, while low-confidence ones appeared as a starting point to edit. I also added a simple thumbs-up and thumbs-down on each suggestion to create a feedback loop for future model training.

*Result:* Agent adoption went from near zero in early testing to a clear majority using the feature daily within the first month, based on internal analytics. The ML team said the feedback data helped them improve the model noticeably in the next training cycle.

---

Q: How would you design for a user who is not comfortable reading text?

*Situation:* During research at my previous company, we found that many rural users were navigating our app through someone else reading it aloud to them.

*Task:* I was asked to redesign the core flow to be more accessible to low-literacy users, without disrupting the experience for the existing user base.

*Action:* I ran contextual research with users in two Tier-2 towns, watching how they moved through the app. I replaced text-heavy screens with icon-led flows, added audio cues for key actions, and reduced the total number of steps by merging related screens. I built three prototypes and tested each with the same users, keeping only the icons they could identify without being prompted.

*Result:* Task completion improved measurably in usability testing across all three scenarios we covered. We also saw a drop in navigation-related support calls from those geographies, based on call center data tracked over the following quarter.

---

Q: Tell us about a design decision that was later proven wrong by data.

*Situation:* I designed a home screen for a financial app with a summary dashboard at the top, assuming users wanted an overview when they opened the app.

*Task:* After launch, I was responsible for monitoring engagement and iterating on what we observed.

*Action:* Analytics showed that most users scrolled past the dashboard immediately to reach the transaction list. I ran five user interviews to understand why. Users told me they opened the app to check a specific recent transaction, not to see a summary. I redesigned the home screen to lead with a searchable transaction list, moving the dashboard to a separate tab.

*Result:* Time-to-task for finding a specific transaction dropped measurably after the redesign, based on session recording data. It reinforced for me that a designer's assumptions are hypotheses, not facts.

Use these frameworks to structure your thinking during Sarvam interviews.

For design challenge questions, use the 'Problem, User, Constraint, Solution, Trade-off' structure. Start by restating the problem in your own words, name the specific user you are designing for, surface the constraints (technology, literacy, language, device), propose a solution, and then proactively name what you had to trade off or leave out. Sarvam interviewers reward honest trade-offs over polished but shallow answers.

For 'tell me about a time' questions, use STAR: Situation (brief context), Task (what you were responsible for), Action (what you specifically did, not 'we'), Result (what changed and how you know). Keep Situation and Task brief. Spend most of your time on Action and Result.

For AI and voice design questions, anchor on three states: what does the user say or do, what does the AI do in response, what does the user see or hear next. Walking interviewers through these three states, and what happens when the AI is uncertain or wrong, shows you understand this medium.

For 'how would you measure success' questions, name a user behavior metric (task completion, time-to-task, return rate) before any business metric. Sarvam cares that you think about whether the product actually worked for the user, not just whether a dashboard number moved.

Sarvam interviewers look for a specific set of qualities, based on what candidates report.

Deep empathy for Bharat users. Not just knowing that Bharat users exist, but having spent time with them, researched them, or designed for them. If you have only designed for urban, English-fluent users, be honest and show you understand the gap.

Comfort with AI-native constraints. Voice AI is not a form with a submit button. Its output is probabilistic. Designers who try to make it feel like a traditional app are fighting the medium. Interviewers want to see that you embrace the unique logic of conversational and voice interfaces.

Strong reasoning behind every decision. Sarvam interviewers will push back on your choices. They are not trying to trip you up. They want to see how you reason under pressure. Have a clear rationale for every design decision you present.

Collaboration instinct. At an AI startup, design and engineering are deeply intertwined. Interviewers look for evidence that you have worked with ML or backend teams, understood their constraints, and built better products as a result.

Communication clarity. You may be presenting directly to the founding team. Being able to explain a design decision simply and confidently, without jargon, matters as much as the decision itself.

Start your prep at least two weeks before your first round.

Week 1: Research and portfolio prep. Study Sarvam's public products carefully. Use the apps, notice where the design is strong and where it falls short, and form your own opinions. Revisit 2-3 portfolio projects that show your process, not just your final screens. For each project, prepare to walk through your research, your trade-offs, and what you would change today.

Week 2: Practice and challenge prep. Practice answering 'tell me about a time' questions out loud using STAR. Record yourself if it helps. Learn how voice AI and conversational design work at a conceptual level. You do not need to train models, but you should understand intent detection, fallback handling, and what happens when the AI is uncertain. Set yourself one or two self-paced design challenges: pick an Indian user scenario, give yourself a fixed time, sketch a flow, and present it to yourself or a friend.

On the day. Bring a portfolio you can walk through in a focused, unhurried way. Prepare two or three questions for the interviewer that show you have thought about Sarvam's product direction. Asking how the design team works with ML engineers signals that you care about the right things.

While you are preparing, it helps to keep an eye on the broader market too. knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so you can stay focused on interview prep rather than manual job hunting.

Showing only visual polish. If your portfolio is mostly final screens with no process, research, or reasoning, Sarvam interviewers will struggle to evaluate you. Add a section for each project that explains the user problem, what you tried, and what did not work.

Designing for yourself. A common trap in voice and AI design challenges is designing for an urban, English-fluent, tech-savvy user because that is who you are. Actively name your target user, challenge your assumptions, and design for someone who may be very different from you.

Skipping the error state. In AI products, things go wrong regularly. If your design challenge solution does not address what happens when the AI misunderstands or fails, interviewers will notice. Always design the failure path alongside the happy path.

Speaking in vague jargon. Saying 'I optimized the UX of the onboarding funnel' tells an interviewer nothing. Say 'I redesigned the first three screens new users see so they could complete setup without reading long instructions.' Specificity builds credibility.

Not asking questions during a live challenge. If you receive a design problem in the interview, ask clarifying questions before you start. Who is the user? What platform are they on? What is the one thing that must work? Jumping straight into solutions signals that you skip discovery in real work too.

Underselling collaboration. If you worked with researchers, engineers, or PMs on your portfolio projects, say so and be specific about your role. 'We built this' tells the interviewer nothing. 'I worked with an ML engineer to understand confidence thresholds, then designed the feedback interface' tells them a great deal.