Salesforce AI UX & Human-in-the-Loop interview questions

A shared vocabulary for one of the biggest decisions in AI product design: how much the AI does on its own. The interviewer wants the levels, and the rule for choosing among them.

Accuracy and trust are different things. The feature saves no time if people double-check everything, and the fix starts with finding out why experts are cautious.

Approval screens fail in a predictable way: people click 'approve all'. The interviewer wants a design that focuses attention on the changes that matter and makes careful review fast.

Trust is easy to survey and hard to measure. The interviewer wants a composite built from behaviour, interpreted carefully, and validated against outcomes the business cares about.

Licences are not adoption. The interviewer wants the real reasons people don't use the tool, and a plan that embeds AI into specific workflows with champions, measurement and honest pruning.

Delegation is the highest autonomy level and the hardest to design. Principal answers cover the brief, budgets and boundaries, checkpoints, reporting, and what happens when the agent hits something it should not decide.

Inconsistent AI behaviour across products confuses users about what to trust. Principal answers create shared patterns and principles that teams adopt because they are useful, with room for product-specific needs.

The central AI UX question. The interviewer wants patterns that make errors cheap to spot and cheap to fix, sized to what an error costs.

Citations are the main trust device in AI answers, and published audits of shipped search engines find many that do not support the sentence they sit on. The interviewer wants citations at the right granularity, checkable in seconds, and honest about what they support.

Users let an assistant act when they can see what it did and take it back. The interviewer wants an activity log, real undo, and clear handling of actions that cannot be undone.

A deceptively simple design question. Numbers feel transparent, but most users cannot act on them, and the numbers are often less meaningful than they look.

Users either expect too much from AI features and churn after the first failure, or too little and never try the useful parts. Onboarding sets the mental model that decides which happens.

Trust that outruns accuracy is as dangerous as distrust. The interviewer wants design that keeps experts engaged where it matters, without making the tool tedious.

Explicit ratings are rare, biased and vague. The strongest feedback signals are things users already do. The interviewer wants a design that captures them and turns a few explicit reports into labelled examples.

How an assistant fails shapes trust as much as how it succeeds. The interviewer wants different responses for different reasons, each giving users a way forward.

'Creepy' means the system knows more than users expected; 'random' means they cannot see the logic. Both are fixed with honest explanations and real controls, not marketing copy.

Health assistants are useful exactly where they are risky. The interviewer wants clear tiers of what the assistant answers, how it handles emergencies and personal medical advice, and an experience that stays helpful instead of hiding behind disclaimers.

Most AI writing value comes after the first draft. The interviewer wants a design that makes partial acceptance, targeted rewrites and comparison easy, and keeps the user in control of their document.

Streaming is the cheapest latency improvement in AI products. The interviewer wants the reason, the trade-offs, and the cases where showing partial output is a mistake.

Translation is the smallest part of multilingual AI UX. The interviewer wants script choice, code-mixing, voice, cultural norms, and honest handling of languages where quality is weaker.

Personality can make an assistant pleasant or manipulative, memorable or annoying. The interviewer wants a personality that serves users' goals, stays honest about being an AI, and adapts when the moment is serious.

A principal-level question about recovering from failure in public. Apologies are necessary and not sufficient; users come back when the product visibly changes and the company keeps its promises.