The interview process consists of multiple stages. First, there’s a screening interview with a recruiter or hiring manager, where they assess your background, experience, and alignment with the role. If successful, you move on to the Android coding interview, where you’ll solve technical problems related to Android development, such as UI, concurrency, performance optimizations, or system design. Finally, there’s the bar raiser interview, which evaluates your problem-solving skills, leadership qualities, and cultural fit. This stage is often conducted by a senior engineer or someone outside the immediate team to ensure high hiring standards.

I applied online for the Senior Android Engineer role in May-June 2017 in San Francisco, CA. I had a pleasant phone chat with the recruiter at Instacart and a follow up interview with a lead engineer on the Instacart Android team. I was asked to implement a simple Android app for the take-home challenge. While I will not reveal the nature of the app out of respect for Instacart, the challenge is required to be finished within ~4 hours and is expected to be of production level quality app. While this should not be challenging under normal situations, the hard time requirements made it very difficult to plan, design, implement, and test the app within the allotted time. Had not for the hard ~4 hour requirement, I would have gladly spent the additional hours to implement a proper mobile architecture (MVP/MVVM), as well as unit tests, things that would be expected of a production-ready app. Some suggestions to the Instacart for improving the take home challenge experience: * Don't set a hard time requirement, allow candidates some time flexibility to polish their submission. While the core functionality of the challenge can be finished within a few hours, making it a production-ready quality app requires additional time, especially for proper architecture, design, and creating proper tests. Implementing MVP/MVVM/etc. architectures take a decent amount of time to implement the boiler-plate code and should be considered, especially if seeing candidates have experience in implementing mobile architectures. * Provide UX design documents with the challenge. While many experienced Android developers are able to come up with their own design, coming up with a custom design and implementing it properly does still take time. * Establish minimum Android API requirements and device expectations. As the challenge did not specify or mention these parameters, it made it somewhat ambiguous about what which specific Android API range and device densities to design for and test against. Please remember, there are thousands of different Android devices with differing Android API versions and candidates don't have resources to test against many different device profiles. Not everyone has access to a Nexus 6 or a Samsung Galaxy S3 Mini sitting around to test against. This will increase the quality of submissions and minimize confusions over expectations of this take-home challenge, a win-win for both Instacart and candidates.