The initial call was pretty standard stuff... just making sure I had the right background, experience, and interests as well as a description of the product and company. I don't believe that the interviewer had a technical background. When I asked about next steps, he said he'd send me a take-home exercise. The exercise involved a system with 2 pushbuttons for input and a small display for output. They said to "stub out" any of the display hardware calls and assume that the input events came from an external state machine. That doesn't leave very much in between, so I just wrote a simple state machine to handle the button events and produce display events. They also said they wanted to see your approach to unit testing, so I implemented in such a way that all of the stubbed out calls were actually abstract functions that could either be linked with code that actually does something through an RTOS, or alternately with code that is part of a unit test harness. They said that it didn't need to compile, but I figured it would be just as easy to do so. I made sure that the unit test could run and provided a script that anyone could use to build and run the tests on a standard linux desktop environment. I also provided working code that could run on an ESP32 with either Zephyr or FreeRTOS, but made sure to put all of that stuff off in a separate directory since the exercise didn't ask for a working implementation. I tested that it passed my unit tests and worked on real hardware even though that wasn't required by the exercise. I submitted the code to a private GitHub repository and worked with my original contact at the company to get the interviewer access as a GitHub "collaborator". I'd assumed that the next step would be to have a live interview where I discussed the code I'd provided with and could explain some of the trade-offs I'd considered and edge cases that might need to be handled and where I could also clarify any questions that I might have about my design and test philosophy. After about a week, I'd heard nothing, so I wrote them to ask when we'd be able to discuss the submission. They wrote back with a response saying "After reviewing your submission, the team has decided not to move forward to the next stage of the process. While we saw some thoughtful elements in your work, we’re prioritizing candidates whose solutions more closely align with the technical depth and system design approach we’re looking for at this stage." This made no sense to me since the exercise was pretty limited in scope to start with. I suppose they might have wanted me to document a little bit more (even though the exercise asked for C-code, not a document), but otherwise there really wasn't even much room for much "technical depth and system design approach" within the scope of the exercise, and I had assumed that it would just be a starting point for more in-depth discussions about greater system issues that they'd encountered and questions about ones that I had. So they essentially wasted my time because of a poorly specified take-home exercise that evidently had implicit expectations that I hadn't guessed correctly. When I went to Glassboard and read the reviews from employees of Hatch, I realized I'd probably just dodged a bullet anyway. Since you're already here reading this, you probably already know that, but if you don't, take time to read some of the other reviews. The perks of the company sound enticing and the product is kind of interesting, but the reviews (including my $.02 that I've added here) make it that it's not worth investing the time and effort.