element-test-assignment

A simple program I made as an interview assignment for Element, it could a good example of Rust code

Assignment

Offline Coding Test

The test (below) is designed to be comfortably completed within 2 hours (and if you run over just stop and tell us what you would have done with more time). The way the test is assessed is that a member of the team will take a quick look to make sure the code is readable and then run it against a test suite. If the tests pass then fantastic - so the best strategy is to focus on working code over beautiful code.

You can complete the test in your own time as long as it's within the 2 hour timeframe.

You can use any language you like. But, please don't use any existing libraries.

Please reach out to your Talent Partner if you have any questions.

Offline coding test

Important note: config to stdin

“Thank you for taking on our simplified cron parser challenge. The aim of this exercise is to see how well you can take a spec and implement some working software.

We have designed this question to be something that can be completed within two hours and we certainly do not expect you to give up more than two hours of your time. The most is that the core functionality works, feel free to leave notes on what you do if you had more time to complete the task.

We have a set of tasks, each running at least daily, which are scheduled with a simplified cron. We want to find when each of them will next run.

The scheduler config looks like this:

30 1 /bin/run_me_daily
45 * /bin/run_me_hourly
* * /bin/run_me_every_minute
* 19 /bin/run_me_sixty_times

The first field is the minutes past the hour, the second field is the hour of the day and the third is the command to run. For both cases * means that it should run for all values of that field. In the above example run_me_daily has been set to run at 1:30am every day and run_me_hourly at 45 minutes past the hour every hour. The fields are whitespace separated and each entry is on a separate line.

We want you to write a command line program that when fed this config to stdin and the simulated 'current time' in the format HH:MM as command line argument outputs the soonest time at which each of the commands will fire and whether it is today or tomorrow.

When the task should fire at the simulated 'current time' then that is the time you should output, not the next one.

For example given the above examples as input and the simulated 'current time' command-line argument 16:10 the output should be

1:30 tomorrow - /bin/run_me_daily
16:45 today - /bin/run_me_hourly
16:10 today - /bin/run_me_every_minute
19:00 today - /bin/run_me_sixty_times

We will assess your solution as objectively as possible, to this end we run your solution through a test runner, and then take a look at the source for code clarity.

Feel free to use any language you want to complete the task. To run successfully against the test runner, we want to run something like this

cat input.txt | <how to run your solution> <simulated current time>
e.g. cat input.txt | python minicron.py 16:10

Please submit all code as attachments, not in the body of the email, as formatting is often lost or mangled. If you want to attach multiple files please do so as an archive (e.g. zip, tar, git bundle, etc).

Any questions please just get in touch!”

Solution

I had to assume that all the input data is well-formed and valid, and that instead of the actual time we're talking about a simplified version of the time (just a minute counter going from 0 to 59 and an hour counter going from 0 to 23, without any DST changes etc.) Additionally it seems that there is a mistake in the test description: while the text seems to suggest that times are in HH:MM format (at least it claims this for the "current time" argument), the output example seems to use H:MM format. I've assumed that it is a mistake in example, and HH:MM format should be used (so the first line of the sample output is "01:30 tomorrow - /bin/run_me_daily").

I understand that you asked me to not use any existing libraries; I did not use any existing libraries for the solution itself, but there is a dependency on the test library to simplify writing tests. It does not affect the solution itself, only its tests.

Since you said that I can use any language I like, I decided to use Rust, because it's the only language I'm familiar with that offers convenient match syntax; and matches are very useful in this test. I’ve decided to keep all code in a single main.rs file for simplicity.

This code can be run e.g. by cargo run 16:10 <input.txt" (or cat input.txt |cargo run 16:10) Tests can be run by cargo test`.