Fetch Paginated Medical Records and Filter by Field Rules and Historical Average Weight

Write a program that collects medical records from an HTTP endpoint and returns the ones that meet a set of conditions. - You are given a URL. Each request returns one page of 10 records, and there can be many pages. - Each record is a patient's medical record with many fields: some are needed for the conditions, and many are not. - Most conditions are plain comparisons on a record's fields. - The weight condition is different: the record's weight is compared with an average computed from historical weight records, which you must derive from the data. The algorithm is not the hard part. The specification is long, the 45 minutes go quickly, and working code is expected, so pull out the rules you need before you start writing. Until the interviewer says otherwise, you may assume that the endpoint takes a page number and returns JSON containing that page's list of records, and that every record identifies its patient and carries a timestamp. The interviewer supplies the exact conditions, so write the program with the conditions as an input. ### Constraints and Clarifications - The page size is 10; the number of pages is not known in advance. - Records contain fields that no condition uses. Ignore them, but return each matching record in full unless told otherwise. - Values may be missing or arrive in an unexpected type. Decide, and state, what a condition does in that case. ### Clarifying Questions - How does the endpoint signal the last page: an empty page, a short page, a total count, or a link to the next page? - Are records ordered by time within and across pages, and can the same record appear on two pages? - Which records form the history for the weight condition: the same patient's earlier records only, or all of that patient's records? Does the record being tested count toward its own average? - What exactly is compared with the average (greater than, less than, a percentage difference), and what happens to a patient's first record, which has no history? - If a page still fails after retries, should the program stop with an error or return partial results? ### Part 1 — Fetch every page Write the code that retrieves all records from the endpoint, one page of 10 at a time, until there are no more. ```hint Know when to stop Decide which response tells you the previous page was the last one, and protect the loop against an endpoint that never stops returning data. ``` #### What This Part Should Cover - A correct stop condition and a guard against an endless loop - Timeouts, retries for transient failures, and what a permanent failure does to the result - Keeping the network code separate from the filtering logic, so that the logic can be tested on saved pages ### Part 2 — Apply the comparison conditions Turn the conditions from the specification into code and keep the records that satisfy all of them. Most compare one field with a constant. ```hint Rules as data Write the conditions down as a short list before coding them, and decide once what a missing or malformed value means for a comparison. ``` #### What This Part Should Cover - A compact representation of the conditions that is easy to check against the specification - Type handling: numbers that arrive as strings, missing fields, values of the wrong type - Ignoring irrelevant fields without losing the full record for the output ### Part 3 — The historical-average weight condition Implement the weight condition: compare each record's weight with the average of the patient's historical weight records. ```hint Order and scope Ask whether a record can be judged before every page has been read, and whether the average should depend on which records passed the other conditions. ``` #### What This Part Should Cover - A precise, agreed definition of the history used for each record - Computing every average in one pass per patient instead of rescanning the history for each record - Records that arrive out of time order, records with no history, and missing weights - Time and memory cost in terms of records and patients ### What a Strong Answer Covers - Extracts the fields and rules from a long specification quickly, and confirms the ambiguous ones, especially the weight history - Working end-to-end code within the time limit, with fetching, parsing and filtering kept separate - Robust pagination: correct termination, timeouts, retries and an explicit failure policy - A correct and efficient per-patient average that does not depend on page order - A test or dry run on a small hand-made dataset ### Follow-up Questions - The dataset no longer fits in memory. How do you compute the historical averages? - The endpoint is slow and rate-limited. How do you fetch faster without exceeding the limit? - New records are inserted while you page through the results. How do you avoid skipping or repeating records? - How would you test the filtering without calling the real endpoint?