I applied online. The process took 2 weeks.

Entire process took approx. 16 days which isn't too bad. Standard sequence of interviews. The technical interview is a bit of a rorschach test. You are given vague requirements for writing a diagram for a distributed system. The problem you are trying to solve for is how to give commands and receive telemetry data from a 3rd party API. Not particularly challenging, and has the potential to be fun if you enjoy this sort of thing. Afterwards, you present your solution to a panel of engineers. The people who work here are affable and intelligent. Unfortunately, interviewing is its own skill set and I think there is room for improvement here.

They asked me a lot of questions on how the system would handle X or perform Y. Which is exactly what you would expect in this kind of interview. But I could tell that they were not getting the answers that they wanted to hear. I strongly suggest for anyone undertaking this assignment to use RabbitMQ between your tt&c server and the 3rd party API. Based on my reading of the assignment I didn't see a clear need for a queue between the tt&c server and the API, at least not on an MVP. But, based on my experience talking to my interviewers it was extremely obvious that they felt there should have been a job queue between the two components.

I think that the idea behind the interview process is rock solid, but the execution of it was rocky. You guys should really consider rewriting your assignment and making it more like a product spec and less like a rorschach test. Instead of a bunch of opaque sentence fragments at the bottom of the page you should write affirmative statements about problems that need to be solved by the system. So instead of this:

• What protocol or protocols would be used?

You could try:

• The tt&c server should be capable of confirming issued commands and recording any that fail.

In my opinion no one in their professional capacity would ever attempt to build anything based off of that assignment prompt. I would have immediately scheduled a meeting with the stakeholders and peppered them with questions. It was fun, but you're not going to hurt the interview process by giving better prompts.

I think you guys should also consider changing the domain of the problem you want the candidate to solve away from anything even remotely close to what you do at the company. There is an insistence that you don't need to know anything about space to work there, but the entire line of questioning was just based off stuff related to your jobs, which does require space knowledge. If you change the domain away from what you do on a day-to-day basis you'll find yourselves better able to meet the candidate in the middle ground and less likely to spend the interview comparing the candidate's proposal to the real thing, which is pretty much what I felt like was going on.

FWIW I wish I would have gotten an offer, and was disappointed I didn't. Also for anyone interested in working at this company if they decline your initial application reapply. I think they do hiring rounds where they only take X people through a round, and any extras get a decline. So if you don't make it in your first round, try again.

Design a system that can issue commands and receive telemetry from a 3rd party API.