Practice: verify CSP and XSS boundaries
Turn "verify CSP and XSS boundaries" into a concrete interview exercise. Explain the risk, choose the smallest useful test boundary, and describe how the signal prevents regressions.
Answer Strategy
For verify CSP and XSS boundaries, answer as an interaction contract. Name the role, accessible name, keyboard map, focus behavior, controlled state, and async or empty states before discussing pixels.
Build the behavior as a headless primitive when multiple product surfaces will reuse it. Visual styling can wrap that primitive, but focus and keyboard semantics should not be rewritten per screen.
The reference implementation shows the pattern interviewers look for: controlled value, explicit active index, roving focus or active descendant, pointer handling that does not steal focus, and tests that query the UI like a user.
Reference Implementation: Accessible Interaction Primitive For verify CSP and XSS boundaries
Adapt this listbox-style primitive for comboboxes, command palettes, menus, pickers, and selection-heavy UI questions. The sandbox below lets you run the browser interaction directly.
type Option = { id: string; label: string };
function useListbox(options: Option[], onSelect: (option: Option) => void) {
const [activeIndex, setActiveIndex] = React.useState(0);
function onKeyDown(event: React.KeyboardEvent) {
if (event.key === 'ArrowDown') {
event.preventDefault();
setActiveIndex((index) => Math.min(index + 1, options.length - 1));
}
if (event.key === 'ArrowUp') {
event.preventDefault();
setActiveIndex((index) => Math.max(index - 1, 0));
}
if (event.key === 'Enter') {
event.preventDefault();
const option = options[activeIndex];
if (option) onSelect(option);
}
}
return { activeIndex, onKeyDown };
}Executable UI Sandbox
UI interview practice should behave like component documentation, not a static snippet. This uses the same isolation pattern as Storybook, Sandpack, CodeSandbox, and StackBlitz: editable source on one side, a sandboxed browser preview on the other. Edit the DOM code, run it, and verify focus, keyboard, pointer, and state behavior in the preview.
Testing Strategy
Convert the answer into observable behavior. In a mid-senior interview, say which behaviors are covered by unit tests, interaction tests, accessibility checks, and one browser smoke path.
test('keyboard selection moves and commits active option', async () => {
const user = userEvent.setup();
render(<ExampleListbox />);
await user.keyboard('{ArrowDown}{Enter}');
expect(screen.getByRole('status')).toHaveTextContent('selected option 2');
});Interviewer Signal
Shows whether you can prove frontend behavior instead of relying on screenshots or manual confidence.
Constraints
- Choose unit, integration, E2E, visual, or performance testing deliberately.
- State the failure that the test catches.
- Avoid brittle assertions that lock implementation details.
Model Answer Shape
- Start with the user-impacting behavior.
- Pick the smallest test that sees that behavior.
- Add one higher-level test only when timing, browser behavior, or integration risk requires it.
Tradeoffs
- Unit tests are fast and precise but cannot prove browser wiring.
- E2E tests are realistic but should be reserved for workflows where integration risk matters.
Edge Cases
- Out-of-order async results.
- Environment-specific browser behavior.
- False confidence from mocks that do not match production contracts.
Testing And Proof
- Regression case for the named risk.
- Negative path or error state.
- Cleanup or retry behavior when relevant.
Follow-Ups
- What would make this test flaky?
- What would you monitor after shipping the fix?