Starts with a phone interviewe with the recruiter, then a call with the hiring manager. Both of these were good and the people I spoke to sounded engaged and interested, which I appreciated.
After these, you get the take-home assessment, which is easily the most grueling I've ever seen in my career. You're prompted to create an app using Google Maps and Google Places to display places near the user, which they can view by list or on the map, and they can decide if it's just by proximity or by text search. You must also prompt the user for permissions and while not required, dependency injection and unit tests are indicated as a "plus" for the submission. You're not allowed to use the Google Places Android SDK and must use the web service.
This is what's the really bizarre part. Google's own documentation doesn't recommend this type of use case and says to use the SDK, and the documentation for the web service is very convoluted and difficult to navigate. There's a ton of trial and error just to get it up and running in the first place, much less get it behaving the way the instructions indicate. I can't stress enough how poor of a decision I think this is, it doesn't make sense when there's an Android SDK available. If they want to see you use a REST API, I'd recommend one that is designed to be used in this fashion. There's also a reference to making database calls, so while not explicitly mentioned as a requirement, there's clearly an expectation of setting up a database and showing a caching strategy. The requirements also include Figma designs for half of the UI, with the other half being intentionally left to the candidate, and there are assets in Figma to export and bring into your project. Not the biggest deal in the world, I appreciate design files, but I'm not sure what they're trying to evaluate by having an engineer essentially design the UI for another screen.
All in all, while I wouldn't say any individual task is extremely difficult, the raw time commitment to combine all of these things feels pretty unreasonable. You're given one week to complete the assessment with a rough estimation of 10-12 hours of work (you're allowed to use AI so that helps speed things up). I would strongly, strongly recommend reevaluating the scope of this assessment. I've never seen an assessment that asks for more than four hours of a candidate's time, and certainly nothing to this level of complexity, and I'm not sure there's really a fair way to evaluate something so large in scope since some engineers will stay within the 10 hour approximation, and some will assuredly far exceed it, and when managing so many expectations, it's difficult to know where the focus should be. In every interview I've done as a candidate and the many I've conducted as a technical interviewer, I've never seen even Senior and Staff level assessments this demanding. I'll give them points for making it Android focused rather than a generic LeetCode assessment. I'll also add from a denial perspective, I was very pleased to get such detailed feedback from the people that reviewed my submission, but I'd again recommend some detail given about how the assessment will be evaluated. Overall I straddle between neutral and maybe slightly negative, since I think the people I talked to were great, I appreciated the Android focus and detailed feedback, but very much did not appreciate how vaguely disrespectful of a candidate's time this assessment is.
