The following challenges are meant to be a coding exercise for applicants to software development roles at jusst.engineering.

Infrastructure

The following challenges share a common infrastructure in terms of a network data source, which provides the data that needs to be processed by the applications which are created to solve the challenges.

The data source is provided in the form of a WebSocket server, which sends a stream of state structures. The server is implemented using the dart-lang. It can be built and executed on Linux, macOS and Windows. Alternatively a hosted instance of the service is provided on this server and can be reached at wss://challenge.jusst.engineering/ws.

The server software code is hosted at https://github.com/jusst-engineering/recruitment.

WebSocket data structures

The data sent on the WebSocket is encoded as JSON, so that it is easy to parse in different environments. The underlying data structures are specified in the server code’s model: https://github.com/jusst-engineering/recruitment/blob/master/lib/model/state.dart#L14

Every message that is transmitted on the WebSocket is an instance of the State class, encoded as JSON. No other data is transmitted by the server at any point in time.

The following semantic is important to correctly interpret the received structures. If a field is null or omitted in the encoded JSON, its previous value remains valid. As an example, the metadata field retains all its inner values until a State instance with a new metadata field is received. This could be an empty MetaData instance in case of no active metadata being available. An example of such a State instance could look like:

{
    metadata: {}
}

How to share your solution

If you want to share your solution of a challenge with us, the preferred way is inviting us to view a git repository in which you maintain the implementation.

Ideally you should treat this repository with the same care as you would do on a real life work project.

Embedded developer challenge

Interested in becoming an embedded software developer at jusst.engineering? Then this challenge is for you!

(@mobile developers, please look a bit further below for your challenge.)

You are free to solve the challenge using Rust, C++ or plain C. Pick whatever you prefer.

Task

Implement an application, which listens to state changes coming from the WebSocket described in the Infrastructure section. Out of the incoming state events a virtual status led should be controlled.

The controlled status led supports the following properties:

• Color: red, yellow, blue, white, off
• Luminance: (int) 0 - 100

The status led should implement the following behavior description:

• system:error -> red@100
• system:updating -> off -> yellow@100 (flashing with 1Hz)
• system:booting -> red@10
• playback:volume(changed) -> white@volume for 3s (bonus: fade out to off)
• bluetooth:pairing -> off -> blue@100 (flashing with 2Hz)
• playback:inactive -> off
• playback:playing && bluetooth:connected -> blue@10
• playback:playing -> white@10
• playback:paused -> white@50

Outcome

The resulting application shall connect to the WebSocket and generate output on stdout which describes the LED state. A snippet of it could look like

red@10
off
blue@100
off
blue@100
off

Expectations

While we would love to see complete implementations of the described task, we are happy to receive partly solved solutions as well.

A non-exhaustive list of things you can skip to simplify the challenge:

• Fade-out the volume after volume changes
• Flashing of led states

Mobile developer challenge

Interested in becoming a mobile software developer at jusst.engineering? Then this challenge is for you!

As flutter is the mobile development framework of our choice, we’d love to see you solving the challenge using flutter.

Task

Implement a mobile application, which listens to state changes coming from the WebSocket described in the [Infrastructure][#infrastructure] section. Out of the incoming state events the app shall visualize the following:

Metadata

The received Metadata shall be rendered as the applications main view. The coverArt should be the central element. artist and title fields shall be displayed as well, for example below the cover art. Make sure that they are visible, no matter what the devices display size is.

Volume

Whenever a volume change event is received, an overlay should be shown for 3 seconds, which displays the new volume.

Playback state

The playback state shall be visualized, for example using a play/pause icon, which switches its icon depending on the current state.

Playback position

The current playback position shall be made visible. Ideally a progress bar style indicator is made, using the the duration field from the MetaData combined with the current playbackPosition field from the State.

System state

In case a non-ready system state is received, show an overlay or notification bar, informing the user about the state. Make the overlay disappear as soon as the system field goes back to ready.

Expectations

While we would love to see complete implementations of the described task, we are happy to receive partly solved solutions as well.

Leaving out any of the above sub-tasks is a possibility to reduce the required efforts.