Harden query string parser
Build query string parser. The interviewer expects a small, reusable utility with clear behavior under repeated calls and invalid inputs.
Answer Strategy
For query string parser, start by stating the public contract before writing code: argument shape, return shape, mutation rules, error behavior, and whether work is synchronous, timed, cached, or cancellable.
A senior solution uses boring names for hidden state. If the function stores a timer, cache entry, listener, or in-flight promise, say who owns that state and how it is cleaned up.
After the baseline passes, harden the edge cases: empty input, repeated calls, invalid values, thrown callbacks, stable ordering, and memory lifetime. The reference below is written to be narrated line by line.
Reference Implementation: Query String Parser
A robust parser handles decoding, repeated keys, blank values, and leading question marks without ad hoc slicing bugs.
function parseQueryString(query: string): Record<string, string | string[]> {
const params = new URLSearchParams(query.startsWith('?') ? query.slice(1) : query);
const result: Record<string, string | string[]> = {};
for (const [key, value] of params.entries()) {
const existing = result[key];
if (existing === undefined) {
result[key] = value;
} else if (Array.isArray(existing)) {
existing.push(value);
} else {
result[key] = [existing, value];
}
}
return result;
}Runnable Playground
Edit the implementation and run the tests directly in the browser. For system design questions, the playground focuses on the core state/data logic that the UI would call.
function parseQueryString(query: string): Record<string, string | string[]> {
const params = new URLSearchParams(query.startsWith('?') ? query.slice(1) : query);
const result: Record<string, string | string[]> = {};
for (const [key, value] of params.entries()) {
const existing = result[key];
if (existing === undefined) {
result[key] = value;
} else if (Array.isArray(existing)) {
existing.push(value);
} else {
result[key] = [existing, value];
}
}
return result;
}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('parseQueryString handles repeated keys and blank values', () => {
expect(parseQueryString('?tag=react&tag=ui&q=&page=2')).toEqual({
tag: ['react', 'ui'],
q: '',
page: '2',
});
});Interviewer Signal
Tests whether you can turn a familiar utility into a precise contract instead of coding only the happy path.
Constraints
- Define the function signature before coding.
- Do not rely on global mutable state unless it is part of the returned closure.
- Explain time and space cost for the common path.
Model Answer Shape
- Write the smallest public contract first.
- Cover empty input, repeated calls, thrown errors, and cleanup behavior.
- Keep implementation readable enough to narrate under interview pressure.
Tradeoffs
- A compact implementation is attractive, but explicit state names are easier to debug live.
- Supporting every possible input can distract from the core contract; state the scope before coding.
Edge Cases
- No arguments or undefined callbacks.
- Synchronous throw inside the wrapped function.
- Repeated calls before the previous result settles.
Testing And Proof
- Happy path with representative inputs.
- Boundary input and repeated invocation.
- Cleanup or cancellation if timers or promises are involved.
Follow-Ups
- How would you expose cancellation?
- How would the API change for React usage?