Plan cache parameter sensitivity
SQL Server. A stored procedure that powers a tenant dashboard is usually ~50 ms but several times a day spikes to 20+ s for some tenants and is instantly fine again after you free the plan cache. The proc filters by `@tenantId`. Most tenants have a few thousand rows; three mega-tenants have tens of millions. Query Store shows the SAME query hash flipping between a fast index-seek plan and a slow scan-heavy plan. No deploy correlates. Triage and give both an immediate and a durable fix.
What a strong answer looks like
Stop the bleeding first (mitigate), then form hypotheses from real signals. Separate root cause from symptom, communicate status as you go, and close with what prevents a repeat.
0:00 of about 35 min
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.
Run or narrate your approach, then ask the coach.