## Implement a Paginated Medical-Record Filter Without Guessing an Ambiguous Rule You are given a paginated HTTP endpoint that returns medical records. Each response contains `page`, `per_page`, `total`, `total_pages`, and `data`. A record includes an integer `id`, a UTC millisecond `timestamp`, a date of birth `userDob` in `DD-MM-YYYY` format, and vital readings including systolic and diastolic blood pressure. Fetch every page, retain records whose user's age at the record timestamp is inclusively between `ageStart` and `ageEnd`, apply a blood-pressure-difference threshold, and return the retained record IDs in ascending order. Return `[-1]` when no record qualifies. The supplied specification is internally inconsistent: one statement requires `diastolic - systolic > bpDiff`, while another says the difference between systolic and diastolic pressure must be less than `bpDiff`. Do not silently choose one interpretation. ### Constraints & Assumptions - `0 <= ageStart, ageEnd, bpDiff <= 102`. - The endpoint may contain more than one page, including an empty final data array. - A birthday is determined from the calendar date represented by the UTC record timestamp; subtracting milliseconds and dividing by a fixed year length is not acceptable. - Records can be returned in any order and IDs are sorted only after filtering. - The endpoint URL and exact HTTP client are supplied by the interviewer or host environment. ### Part 1 — Resolve the Contract Explain the ambiguity in the pressure rule, ask for one exact signed expression and comparison operator, and write the clarified predicate down before coding. Also clarify malformed dates, missing vital fields, failed pages, and whether the source can change while pagination is in progress. #### What This Part Should Cover - A concrete input on which the two written pressure rules disagree. - One interviewer-approved expression with defined equality behavior. - Explicit policies for invalid records, page failure, and source mutation. ```hint Test the words as algebra Translate each sentence into a signed expression. If two translations accept different records, the implementation needs clarification rather than intuition. ``` ### Part 2 — Fetch and Normalize All Pages Describe or implement pagination that reads the first response, follows the declared page count, checks each response, and avoids losing or duplicating records. Parse each timestamp and date of birth under one documented UTC convention. #### What This Part Should Cover - Checked status, JSON shape, and coherent pagination metadata. - Bounded retries or a clear failure result rather than silent partial success. - Locale-independent date parsing and UTC calendar conversion. ```hint Let the response drive pagination The first page tells you how many pages exist; do not stop merely because one page has fewer records than `per_page`. ``` ### Part 3 — Compute Age, Filter, and Return IDs Compute completed years at each record's timestamp, apply the inclusive age interval and the clarified pressure predicate, then sort the matching IDs. Discuss how you would test birthday boundaries, page failures, missing fields, and both possible pressure interpretations. #### What This Part Should Cover - Completed-year age with a month-and-day birthday adjustment. - Inclusive age checks and exact threshold-boundary handling. - Numeric ID sorting and the `[-1]` empty-result sentinel. ```hint Compare month and day after subtracting years Age in completed years needs a birthday adjustment; elapsed milliseconds alone mishandles leap years and boundary dates. ``` ### What a Strong Answer Covers - Refuses to encode a contradictory pressure rule without an explicit decision. - Uses bounded, checked pagination and makes partial-response behavior explicit. - Computes age from calendar components at the record time in UTC. - Separates retrieval, parsing, predicates, and output ordering so each can be tested independently. - Returns `[-1]` only after all successfully required pages have been evaluated and no record qualifies. ### Follow-up Questions 1. How would you prevent duplicate processing if the API repeats a record across pages? 2. How should retries and timeouts avoid returning a silently incomplete result? 3. What changes if the API offers cursor pagination instead of page numbers? 4. How would you make the result reproducible if records can be inserted while pages are fetched?