1. Prompt and context
You own an enterprise admin console with bulk deletion, deactivation, and migration. A customer worries that a wrong filter could affect tens of thousands of records and asks to see “what will change.” The product decision is whether a preview can reduce irreversible loss without turning every action into an expensive full scan.
2. What the interviewer is testing
- A strong answer separates reversible, delayed, and permanent actions before choosing preview depth.
- It combines user value, engineering cost, permissions, and uncertainty in one decision framework.
- It does not treat one number as proof of safety; it names snapshot time, cascades, asynchronous jobs, and authorization.
- It proposes a narrow experiment and guardrails instead of promising a platform-wide feature immediately.
3. Questions to clarify first
- Which actions are truly unrecoverable? If a recycle bin or backup exists, start with permanent deletion.
- Does the preview use the viewer’s visibility or the execution identity’s final reach? The answer changes the authorization model.
- Does the customer need an exact list, counts by resource, or only a risk tier? Exact lists increase query and privacy costs.
- Is execution immediate or queued? An asynchronous job can freeze an impact snapshot and require a second confirmation.
4. Thirty-second answer framework
“I would tier actions by reversibility and blast radius. I would require previews for permanent deletion and cross-object cascades, while keeping clear confirmation for low-risk reversible actions. The MVP would show the execution identity, filter summary, counts by resource, snapshot time, and dependencies that may not be covered, then bind the preview to the job. I would pilot it with administrators and high-value accounts, measuring harmful mistakes, preview-to-execution conversion, latency, and cancellations. If exact computation is too expensive, I would label an estimate and default to delayed execution rather than display false precision.”
5. Step-by-step reasoning
First define a risk matrix. Permanent deletion, cross-tenant impact, cascades, and very large jobs are high risk; reversible field updates are medium risk; a single low-privilege change is low risk. Only high-risk actions should require a preview, so users do not bypass a flow that makes every button slow.
Second define the preview contract. Return the execution identity, filter summary, match count, counts by resource, cascade impact, query time, and data version. If dependencies cannot be fully computed, say which dependencies may be missing and never present an estimate as an exact guarantee. ServiceNow’s deletion preview shows cascade counts while warning that related attachments may not appear, which is the right level of uncertainty disclosure.
Third bind preview to execution. Create a previewId, condition hash, and expiry. Confirmation may execute only the same condition or explicitly request a new preview. Record the preview snapshot and actual result; if the difference exceeds a threshold, pause and ask for confirmation again.
Fourth design permissions and privacy. Return only aggregates visible to the execution identity; do not let counts reveal another tenant’s data. Require step-up authentication or dual approval for privileged permanent deletion. Microsoft Power Platform separates permanent deletion and warns that the data cannot be restored; the product should use the same risk distinction.
Fifth control cost. Compute small scopes synchronously. Queue large jobs and return an estimate or staged counts first. Reuse a read-only snapshot briefly for identical conditions, but show its timestamp so stale results cannot hide changes.
6. High-quality sample answer
“I would offer previews, but not as a universal step for every bulk action. I would classify permanent deletion, cross-object cascades, and cross-tenant jobs as high risk and require the execution identity, filter summary, counts by resource, cascade scope, snapshot time, and uncertainty notes. The preview would create an expiring previewId; confirmation would validate the condition hash. If data changed beyond a threshold, the job would pause for a new preview. The MVP would cover the administrator’s most common deletion job, compute large queries asynchronously, and measure harmful mistakes, preview latency, cancellation, and preview-versus-actual variance. If exact computation is too costly, I would ship bounded estimates plus delayed execution and make the uncertainty explicit.”
7. Common mistakes
- Mistake → Require a full preview for every action → low-risk changes become slow and users bypass the flow → tier by reversibility and blast radius.
- Mistake → Show only one total → cascades, permissions, and attachments stay hidden → show resource-level scope and possible omissions.
- Mistake → Keep a preview valid forever → data changes before confirmation → use a snapshot, expiry, and condition hash.
- Mistake → Wait for 100% exactness before launch → large queries overload the console → ship bounded estimates and asynchronous jobs, then measure variance.
- Mistake → Optimize only for preview clicks → users may cancel from fear or never use it → track harmful mistakes, cancellation, latency, and variance together.
8. Follow-up questions
What if the customer demands a complete record list?
Ask what decision the list supports. Aggregated counts are enough for scope confirmation; an audit need can use a paginated, permissioned snapshot or export. Redact sensitive fields, expire access, and log access so the preview does not become a data-exfiltration path.
The preview says 10,000 records, but execution finds 12,000. What now?
Put a threshold in the execution contract. Pause when the difference exceeds it, explain the new source, and require confirmation. A low-risk action may continue, but the preview and actual difference must remain in the audit record.
How do you decide whether the MVP worked?
Set guardrails: lower harmful-mistake rate, preview-to-actual variance, P95 preview latency, cancellation rate, and backend resource cost. Expand to more resources only when mistakes fall and latency remains acceptable; rising preview usage alone does not prove value.