Katkat
Back

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

PinterestSite Reliability Engineer · Technical Screen
EasySite Reliability EngineerTechnical ScreenSoftware Engineering Fundamentals

Last updated

A practical scripting exercise for a site reliability role: send GET requests with a required header to two URLs, pull a text field from each response, extract every valid IP address, and rank the addresses by how often they appear. It tests HTTP error handling, strict IPv4 validation, code reuse and deterministic sorting.

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.

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.

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.

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.

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

Hints

Hint 1

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.

Hint 2

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.

Hint 3

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.

Hint 4

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.

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?