Debug Metrics Computed Before Filtering
Company: Instacart
Role: Backend Engineer
Category: Software Engineering Fundamentals
Difficulty: medium
Interview Round: Take-home Project
# Debug Metrics Computed Before Filtering
A metrics page accepts filters and returns both matching rows and summary metrics. Users report that the rows are filtered correctly but the summary value still describes the unfiltered data.
The endpoint has this simplified flow:
```python
rows = repository.load_rows()
metrics = summarize(rows)
rows = apply_filters(rows, request.filters)
return {"rows": rows, "metrics": metrics}
```
Diagnose the defect, propose a minimal safe fix, and design tests that prevent the ordering bug from returning. Discuss how you would investigate the real code when the frontend is JavaScript but the endpoint is implemented in an unfamiliar Python web framework.
### Constraints & Assumptions
- `summarize` is correct for the rows it receives.
- Filters affect which rows should contribute to the displayed metrics.
- The response contract itself should not change.
- The real endpoint may apply pagination after filtering; metrics are intended to describe all matching rows, not only the page.
### Clarifying Questions to Ask
- Should every summary use the filtered population, or are some values intentionally global?
- Are authorization and tenant scoping represented as filters or enforced earlier?
- Do metrics describe all matched rows or only the displayed page?
- Can filtering be pushed into storage, and what consistency is expected between rows and metrics?
### Solving Hints
- Trace the data lineage of the incorrect number rather than assuming the visible frontend owns the bug.
- Write a fixture where filtered and unfiltered summaries are necessarily different.
### What a Strong Answer Covers
- Identification of the ordering/data-lineage defect.
- A fix that applies authorization and semantic filters before aggregation while keeping pagination in the correct place.
- Regression tests at unit and endpoint levels.
- Consideration of duplicated filter logic, query efficiency, and consistency between rows and metrics.
- A disciplined debugging approach in an unfamiliar framework.
### Follow-up Questions
1. How would you avoid loading every matching row merely to calculate the metrics?
2. What if the table and summary are produced by separate queries?
3. Which filters must be applied before any data leaves the repository for security reasons?
4. How would you detect this regression in production?
Quick Answer: Debug a metrics endpoint whose summary is calculated before user filters are applied even though its rows are filtered correctly. Trace the data lineage, aggregate over the full matched population before pagination, preserve security scoping, and add unit and endpoint regression tests.