The interview process took about 7-8 hours in total: an initial interview with the CTO, a lengthy take home assignment, then an in person presentation at their office. The biggest takeaway? Never accept a take home assignment unless the expectations are made clear. The take home assignment was to develop a small application related to their business. When you open the repo the README states: "The purpose of this demo is to give us insight into how you approach building a complete feature across the stack—from data modeling and API design to user interface implementation and usability...even in areas you may not fully complete due to time constraints... This project is designed to take a few hours (3–4)... You are not expected to deliver a production-grade system—but we do want to see your best effort at solving the problem thoroughly."
Reasonable right? I interpreted the instructions as an opportunity to demonstrate how I approach system design and architecture broadly. To deliver a thoughtful, though unpolished app with considerations for scalability, UX, and mobile users (especially given that they mentioned having a mobile app).
What they didn't say is that buried in a folder called docs is a file named "inventory.md". This file contains an overview of 38 specific requirements for the application. Apparently the real expectation was to build the app exactly to those specs, this was only made clear after the fact when I was told I failed the assignment for not building the app "to specification". This is a huge red flag, so was the goal a broad realistic demo that wouldn't be production ready or an app made exactly to specification? You can't have it both ways.
At the in-person presentation, even the engineer who created the assignment seemed unaware that the fake data they provided was inconsistent, or that a mobile context might reasonably influence design decisions. It was clear that the team wasn’t aligned on what they were looking for, or how to fairly evaluate candidates. Nor did they spend much time crafting the assignment that you are expected to spend quite a bit of time on.
Between the take-home, prep, travel, and interview time, I spent around 8 hours on this process and only got the impression that Cumulus struggles to communicate clearly and respect engineers' time.
If you're a developer considering interviewing here, I'd strongly recommend thinking twice before committing to their process. Vague instructions, inconsistent expectations, and a lack of internal alignment made this process frustrating and ultimately an avoidable waste of time.
