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

Sanas is a US-based AI startup that builds real-time accent softening technology for call-centre and customer-support teams. Its product runs during live calls, helping agents sound clearer to customers, sitting at the crossroads of speech AI, enterprise SaaS, and workforce tools. As of mid-2026, Sanas has 10 open Product Designer roles, signalling active product growth.

The interview process typically runs three to five rounds. Candidates report a portfolio review as the first substantive step, followed by a design challenge or take-home task, then cross-functional discussions with product managers, engineers, or leadership. Sanas interviewers tend to probe how you think about designing for real users under real constraints, including latency, imperfect AI outputs, and the emotional weight of a tool that touches how someone sounds.

Salary context from the broader Product Designer market, based on knok jobradar data across 393 open roles nationally as of July 2026: entry-level (0-2 years) typically falls in the 6-12 LPA range, mid-level (3-5 years) in the 14-24 LPA range, and senior roles (6-9 years) in the 26-40 LPA range. For Sanas specifically, check Glassdoor or levels.fyi for self-reported figures.

Based on what candidates report and the nature of Sanas's product, here are the questions most likely to come up:

1. Walk us through a project in your portfolio where you solved a complex problem for a non-technical or first-time user.
2. How would you design the onboarding experience for a call-centre agent using Sanas for the very first time?
3. Describe a time you designed for a sensitive or identity-adjacent experience. How did you handle user dignity and trust?
4. How do you approach designing features when the AI output is probabilistic, meaning it can sometimes be wrong or inconsistent?
5. Tell us about a time you collaborated closely with engineers to ship a feature under tight technical or time constraints.
6. How would you define and measure the success of a design change in Sanas's core real-time product?
7. Describe a situation where a stakeholder or PM pushed back on your design recommendation. What did you do?
8. How do you design for accessibility and inclusivity in an enterprise SaaS context?
9. Walk us through your end-to-end design process, from initial discovery to shipping.
10. If you had to redesign the in-call feedback UI for an agent, where would you start and why?
11. Tell us about a time you used user research or data to change the direction of a design mid-project.
12. What do you see as the biggest UX challenges when building AI-powered voice products?

Q: Describe a time you designed for a sensitive or identity-adjacent experience.

*Situation:* I was working on a profile-creation flow for a B2B HR platform where users were asked to share their language background and communication style for team-matching.

*Task:* My job was to make the flow feel empowering rather than labelling. Early internal testing showed that users found the questions intrusive, almost like being categorised without consent.

*Action:* I ran a round of contextual interviews with a small group of users. I rewrote the copy using first-person framing ('I prefer to communicate in Hindi') instead of third-person labels, added a clear explanation of why each field existed, and made every field optional with a visible skip path. I also worked with the PM to sequence the sensitive fields after users had already gotten value from the product, so they had a reason to trust us before sharing.

*Result:* Completion rate on that section rose meaningfully. Qualitative feedback shifted from 'this feels invasive' to 'this actually helps me feel understood.' The pattern became a reference design for subsequent onboarding flows in the product.

---

Q: How do you approach designing features when the AI output can sometimes be wrong?

*Situation:* At a previous role, I was designing a smart-reply suggestion feature inside a customer-support chat tool. The NLP model occasionally surfaced suggestions that were off-tone or factually incorrect.

*Task:* I needed a UI that kept agents productive without making them over-trust or under-trust the AI suggestions.

*Action:* I introduced a confidence-signal pattern: suggestions with lower model confidence were displayed with lighter visual weight and a small 'review before sending' nudge. I added a one-click feedback button so agents could flag bad suggestions, feeding directly into the ML team's retraining pipeline. I then ran two rounds of testing with separate agent cohorts to validate the pattern before shipping.

*Result:* Agent complaints about 'bad AI suggestions' dropped significantly based on support ticket data. The feedback loop gave the ML team a cleaner training signal, and the confidence-signal pattern was adopted into the shared design system.

---

Q: Tell us about a time a stakeholder pushed back on your design.

*Situation:* I had designed a simplified dashboard for a SaaS analytics product. The VP of Sales wanted to add a long list of additional data widgets that the sales team felt were important for prospect demos.

*Task:* I had to push back without losing the stakeholder's trust, and find a path that served both the real users (analysts using the dashboard daily) and the business goal (impressive demos for prospects).

*Action:* I prepared a short usability brief showing that first-time users consistently missed the core action in the cluttered version. I proposed a 'demo mode' toggle that surfaced the additional widgets only when activated, keeping the default view clean. I walked the VP through the brief in a focused session and let the data lead the conversation rather than leading with my opinion.

*Result:* The VP agreed to the toggle approach. It shipped that quarter. Analysts kept their clean default, the sales team got their showcase mode, and the VP later cited the collaboration as a model for how design and sales could work together.

STAR for behavioural questions. Start with the Situation (one or two sentences of context), the Task (your specific responsibility), the Action (what you personally did, step by step), and the Result (a concrete outcome). Keep the Situation brief. Interviewers want to spend most of the time hearing your Action.

Design Walkthrough for portfolio or case-study questions. Cover: the problem you were solving and for whom, the constraints you were working within (time, tech, org), the process you followed (research, ideation, iteration), the decision you made and why, and what happened after it shipped. Sanas interviewers typically want to hear how you handle ambiguity and tradeoffs, not just the final screens.

'How would you design X' for product thinking questions. State your assumptions out loud before jumping to solutions. Define the user and their goal, identify the key friction points, sketch two or three directional approaches, and explain which one you would prototype first and why. At Sanas, ground your answer in the specific constraints of a real-time voice product: latency, cognitive load during a live call, and the emotional stakes for the agent.

Disagreement questions. Lead with what you understood the stakeholder's goal to be, then explain what your data or reasoning showed, and describe how you found a path forward that respected both perspectives. Avoid framing the story as 'I was right and they were wrong.'

Sanas interviewers are typically looking for four things, based on what candidates report and the nature of the product.

Deep user empathy, especially for non-mainstream users. Sanas's core users are call-centre agents, many working in a second language under high-pressure conditions. Interviewers want to see that you can design with genuine respect for users whose daily context is very different from a typical tech worker in Bangalore or Mumbai.

Comfort with AI product constraints. Unlike a pure-UI product, Sanas's features involve real-time ML outputs that can vary or fail. They want designers who understand probabilistic systems well enough to design for graceful degradation, clear error states, and earned trust over time.

Cross-functional collaboration skills. Candidates report that Sanas values designers who work fluidly with engineers and PMs, defend decisions with evidence, and know when to advocate and when to adapt. Stories about navigating disagreement respectfully tend to land well in interviews.

Clarity of thought under ambiguity. The company is in a growth phase, which means open-ended problems are common. Interviewers give deliberately broad prompts to see how you structure your thinking. Talking through your reasoning out loud matters more than arriving at the 'right' answer.

Week 1: Know the product.
Watch Sanas product demos and read available coverage about how the technology works. Try to understand what the agent experience looks and feels like during a live call. Write down three UX friction points you notice in any demo or walkthrough you can find. This is live, specific material you can reference in your interviews.

Week 2: Prepare your portfolio stories.
Pick a few projects that map to the question themes above: sensitivity and trust, AI-assisted features, stakeholder collaboration, and measurable impact. Write out the STAR structure for each before you walk in. If you do not have a project in every category, prepare a thoughtful 'how would you approach it' answer for the gaps.

Week 3: Practice design challenges.
Do one timed design exercise regularly. Pick a real enterprise SaaS onboarding or settings flow and redesign it within a fixed window. Focus on articulating your tradeoffs out loud as you work, not just producing screens. Sanas interviewers want to hear your thinking, not just see your output.

Before each round: Prepare your questions.
Sanas interviewers typically leave time for your questions. Come with two or three that show you have thought about the product: roadmap priorities, how design and ML teams collaborate, or how user research is currently done. Generic questions signal low interest.

If you are actively applying to other Product Designer roles while you prep, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR on your behalf, so you do not lose ground while focusing on interview preparation.

Treating the portfolio review as a presentation, not a conversation. Many candidates recite a scripted walkthrough without pausing. Interviewers want to ask questions and dig into decisions. Invite interruptions and be ready to go deeper on any part of your work.

Ignoring the emotional context of the product. Sanas's tool touches something personal: how someone sounds. Candidates who treat it as a pure UX-efficiency problem without acknowledging the identity and dignity dimensions typically do not perform well in the interview.

Overloading on visual polish. Sanas is an enterprise B2B product. Interviewers care about usability, flow logic, and edge-case thinking more than aesthetics. Do not spend most of a design challenge on colour and typography.

Being vague about impact. Saying 'users loved it' is not enough. Even without hard metrics, describe what changed in user behaviour, what qualitative feedback you received, or what the team did differently because of your work.

Not asking for constraints. Jumping straight to solutions when given an open-ended design prompt signals weak product thinking. Surface your assumptions first, then design.

Under-preparing for cross-functional questions. Many candidates prepare for design craft questions but not for 'how do you work with engineers' or 'how do you handle conflicting priorities.' These come up consistently at product-stage startups like Sanas and can make or break your final rounds.