markhibberd / interview

Ambiata Take Home Exercises.

Ambiata Take-Home Coding Exercise

This is a take-home coding exercise used to help evaluate and work with candidates looking to join the team at Ambiata. The general idea is for candidates to complete one of the options below before the engineering interview. During the interview we will use the code as a discussion point and may ask you to make changes and re-submit for a second interview.

What you should expect?

We expect that the amount of effort to do any of these exercises is in the range of about 4-6 hours of actual work. We also understand that your time is valuable, and in anyone's busy schedule that constitutes a fairly substantial chunk of time, so we really appreciate any effort you put in to helping us building a solid team - and if you really can't invest that much time, check out the F.A.Q. below for some alternatives.

The requirements for each of the exercises form a reasonably formal set of specifications for the component we’re expecting you to develop. While they certainly have some holes in them and some ambiguities, they are reasonably similar to the set of system requirements programmers are often given.

After you submit your code, we will contact you to discuss and potentially arrange an in-person interview with some of the team.

The interview will cover a wide range of technical and social aspects relevant to working at Ambiata, but importantly for this exercise we we will also take the opportunity to step through your submitted code with you, offer feedback and we may ask you to re-submit your code for a second time based on the feedback.

What we are looking for?

Keep it simple. Really. 4-6 hours isn't a lot of time and we really don't want you spending too much more time on it than that.

Treat it like production code. That is, develop your software in the same way that you would for any code that is intended to be deployed to production. These may be toy exercises, but we really would like to get an idea of how you build code on a day-to-day basis.

You can use any language, tools or solutions as you see fit. We do however recommend you use something you a familiar with. We would prefer to see something done well in an older technology, or one we may not use, than to see a poor one in the cool new programming language.

You can submit the code in any way that is convenient for you - you can email us a tarball, a pointer to download your code from somewhere or just a pointer to a source control repository. In your submission, you should include:

• The code and what ever is required to run it. You can assume that this will run on some *nix like operating system and will have a fairly standard set of command line tools. If you require something specific, either include it inline, or document it in a way that it would be trivial for us to get and run your code.

• A small README documenting the problem you are undertaking; documentation of any assumptions or simplifications you have made; and a short description of how to run your code.

Option 1: Battleship

Build an API for simulating a game of "Battleship".

The complete specification of this option can be found in battleship.md.

Option 2: Weather Observations

Build a tool to mine the logs of a weather balloon for important observation details.

The complete specification of this option can be found in weather.md.

Option 3: Substitute Your Own Project

Guidelines:

• The project should be of at least 4 hours worth of effort.

• It should be something we can compile / run.

• It should be something you are comfortable discussing.

• It should have a reasonably obvious purpose / use. At least something that you could explain to us in a couple of paragraphs of text (with the assumption you are explaining to experienced engineers).

• It is something that has primarily been worked on by you.

To submit:

• Your code.

• If it is a larger project, a pointer to the most interesting parts that we can review and run.

• A couple of paragraph description of what the code is/does.

F.A.Q.

1. Is it OK to share your solutions publicly?

• Yes, the questions are not prescriptive, the process and discussion around the code is the valuable part.

• You do the work, you own the code. Given we are asking you to give up your time, it is entirely reasonable for you to keep and use your solution as you see fit.

2. How should I submit?

• However you see fit - you can email us a tarball, a pointer to download your code from somewhere or just a pointer to a source control repository.

3. Should I do X?

• For any value of X, it is up to you, we intentionally leave the problems a little open-ended and will leave it up to you to provide us with what you see as important. Just remember the rough time-frame of the project, if it is going to take you a couple of days, it isn't essential.

4. I really don't have the time to spend on this project, but I would still like to apply.

We really don't want this to introduce a bias against people that genuinely don't have time - and there are lots of reasons this may be the case. All we ask is that you make some effort to participate, a few options may be:

• Take Option 3 and show us something you already have.

• Ask for more time to complete the exercise - we understand - just let us know.

• Shrink the problem statement yourself. We would be more than happy to see a smaller (even tiny) solution where you have explicitly shrunk the problem to a scale that they can work with.

• Just let us know, and we will see what we can do in terms of alternatives that will be less time-consuming.

5. Something is ambiguous, and I don't know what to do?

The first thing is: don't get stuck. We really don't want to trip you up unintentionally, we are just attempting to see how you approach problems. That said, there are intentional ambiguities in the specification, partly to see how you fill in those gaps, and partly because the specification is written in English.

If you really feel stuck, our first preference is for you to make a decision and document it with your submission - in this case there is really no wrong answer. If you feel it is not possible to do this, just send us an email and we will try to clarify or correct the question for you.