I was given a 3-day take-home project.

I was asked to ignore several critical issues:

• Misspellings in the prompt.
• The project was purely backend, despite the role being acknowledged as frontend.
• To make the code functional, I would have had to reveal my GitHub security credentials.
• Using the referenced v3 of the heavily rate-limited public GitHub API would have saturated my account's allocated bandwidth, preventing me from using it for anything other than applying to Splunk.
• I already knew from past experience that the GitHub API has, shall we say, quirks in how it handles throttling API calls.

My approach was to write the code, but let them supply the credentials and register the app with GitHub if they wanted to run it against the live API. For testing, I created a mock API with optional enforced rate-limiting that returned data as if from GitHub itself. This fed a cache, so the fictional client of this project could get potentially stale (lazily updated) data without waiting for the approximately 6 minutes it would take the GitHub API to fetch all the data.

After about 5 hours of coding, I documented how this could be scaled by using a distributed key-value store and a serverless function instead of the in-line classes created for the take-home project.

Crickets. Then, a week later, a no-reply, no-explanation rejection.

Going by the interview process, I highly doubt whether Splunk is a good place to work. Seriously, as a frontend engineer, do I really want my team to be judged and chosen on how well they can implement the backend interface to a rather idiosyncratic API (v.4 is much better)?

As a user of your software, I want to be able to get a list of all public Splunk repos (with pagination support) sorted by:

• Last updated time
• Number of stars
• Number of contributors

The output list of repos should contain only the following properties:

• ID
• Name
• Number of stars
• Number of contributors
• The ID of the person who committed last