(Pre-interview read) Context document -
Warner Music Group distributes music to partners like Spotify via the concept of an Order, which represents an individual song. These Orders are delivered to partners in the form of Metadata (XML) and Assets (audio WAV, coverart TIFF, etc) files.
What You Need to Do: You will build an “Artifact Generation” client that ingests Orders from a queue, orchestrates the production of Metadata and Assets, along with their respective AssetDetails, and publishes the results for further processing. This happens via a series of JSON APIs, implemented in a testserver binary that you have been / will be provided. These APIs may not always reliable, and your client must handle failure correctly.
Generally speaking, for each Order, you will:
- take an Order from the queue
- queue Asset generation
- wait till it finishes, and then get Asset and AssetDetail data
- queue Metadata generation
- wait till it finishes, and then get Metadata data
- bundle all the data together and submit it as a ShippableOrder
Data Model: The relationship between Orders, Assets, AssetDetails and Metadata is as follows:
- An Order has 1:many Assets => An Asset belongs to a single Order
- An Order has 1 Metadata => A Metadata belongs to a single Order
- An Asset has 1 AssetDetail => An AssetDetail belongs to a single Asset
Orchestration Requirements
Specifically, there are some rules you must follow while processing each Order, as listed below:
1. You must "take" an Order from the queue before doing anything else with it
2. You must finish Asset generation before triggering any Metadata generation
3. You must not trigger Metadata generation if Asset generation failed
4. If Asset generation fails:
● You must submit a FailedOrder without Asset/AssetDetail or Metadata
data
5. If Metadata generation fails:
● You must submit a FailedOrder with Asset/AssetDetail data but without
Metadata data
6. If both Asset and Metadata generation succeed:
● You must submit a ShippableOrder with both the Asset/AssetDetail data
and Metadata data
Tips
1. There are no dependencies between Orders; the status/processing of one Order does
not impact any other Order
2. If you break the state machine by failing to follow the above orchestration rules, you
cannot recover it
3. If you submit an Order incorrectly (incorrect data/status), you cannot recover it
[Actual Interview] -
As per the above, you will have code/flow where the client will talk to SDK which will in turn talk to the test server.
The client code has caller functions to:
- peek into the queue and see the first order,
- take/select this order (for processing),
- queue the asset generation for this order,
- get asset for this order,
- get asset details for this order,
- queue the metadata generation for this order,
- get metadata status for this order,
- get metadata for this order,
- submit shippable order with the asset and the metadata objects.
Each of the above functions are defined in the SDK file. It also contains different Class definitions. You have to make changes both in the client & the SDK files to accurately submit Failed and Shippable orders for each order. Based on the above pre-read document, you will get a bare skeleton code with all the above implemented. You will have to add/handle such edge cases & implement/validate the whole state machine.
- if the get asset API call fails or if an empty asset value is found, submit failed order with order details
- if either the get metadata API call fails or the metadata value is empty, submit failed order with order details with the asset object. There are 3 challenges which your code will be evaluated against. You can make changes to the code & execute it as many times as you want. Whenever you execute your code, it is evaluated on the 100 order values in background. The terminal prints the output and your current score as the code is being tested on all the orders.
