Fetch a Field from Two URLs, Extract Valid IP Addresses, and Rank Them by Count

This phone screen for a senior site reliability engineering role is a short, hands-on scripting exercise in four steps, each building on the previous one. Use whichever language you are most comfortable with. 1. You are given a URL and a request header. Send an HTTP GET request to the URL with that header and extract the value of a specified field from the response. 2. From the extracted text, find all valid IP addresses. 3. You are given a second URL. Extract the same field from its response. 4. Count every valid IP address across the extracted text and output the addresses sorted by count. ### Constraints and Clarifications - The interviewer supplies the URLs, the header's name and value, and the name of the field. The source does not say what the header carries; an API key or an authorization token is a common case. - Assume the response body is JSON and that the field holds free text in which IP addresses appear among other words and numbers. The source does not show the response format, so confirm it before parsing. ### Clarifying Questions - Does "valid IP address" mean IPv4 only, or IPv6 as well? - Is an octet with a leading zero, such as the `010` in `010.1.1.1`, valid? Some parsers read such octets as octal. - How should a dotted run of more than four numbers, such as `1.2.3.4.5`, be treated: as no address, or as containing one? - Is the field one string or a list of strings, and can it be missing or null? - Does the second URL take the same header? - In step 4, is the sort by count descending, and how are addresses with equal counts ordered? - May I use a third-party HTTP library, or only the standard library? ### Part 1 — Fetch the field Send the GET request with the given header and return the value of the requested field. ```hint What can go wrong first Before you touch the field, decide what your function does when the request hangs, the status code is not a success, or the body is not the JSON you expected. ``` #### What This Part Should Cover - Sending the header correctly and bounding the request with a timeout - Checking the status code and parsing the body defensively - A clear outcome when the field is missing, null or of an unexpected type ### Part 2 — Extract valid IP addresses From the extracted text, return every valid IP address it contains, in the order the addresses appear and including repeats, since step 4 counts them. ```hint Find, then validate A single pattern that both locates and fully validates addresses becomes hard to read. Consider separating the two jobs, and decide where an address may start and end inside longer text. ``` #### What This Part Should Cover - A precise definition of a valid address: exactly four parts, each in range, and the agreed leading-zero rule - Boundaries that keep part of a longer dotted or numeric run from being reported as an address - Test inputs at the edges: `255` versus `256`, `0.0.0.0`, trailing punctuation, too many parts ### Part 3 — A second URL Given a second URL, extract the same field from its response. ```hint Reuse, do not copy If step 1 is a function parameterized by the URL, this step is one more call. If it is not, this is the moment to refactor it. ``` #### What This Part Should Cover - Reusing the fetch and extraction code instead of duplicating it - What happens when one URL fails and the other succeeds ### Part 4 — Count and sort Count every valid IP address found in the text from both URLs, and output each distinct address with its count, sorted by count. ```hint Make the order unique Settle the direction of the sort and the tie-breaker before you write the sort key, so the same input always gives the same output. ``` #### What This Part Should Cover - Counting with a hash map across both sources - A sort key with an explicit direction and a tie-breaker - A clear output format and the cost of the whole pipeline ### What a Strong Answer Covers - Small functions for fetching, extracting and counting, each testable without the network - Defensive network handling that fits a reliability role: timeouts, status checks and clear error messages - Strict, explained IP validation with correct boundaries - Deterministic output - Trade-offs narrated while coding, such as failing fast versus returning partial results ### Follow-up Questions - The endpoint sometimes returns 429 or 503. How would you add retries without overloading it? - How would you fetch hundreds of URLs, and how would you bound the concurrency? - How would you extend the extraction to IPv6, or exclude private and reserved ranges? - A response body is several gigabytes. What changes?