Ground delivery drones are making great strides. They're not uncommon in larger restaurants where I live, and they're also being used in the hotel industry for making deliveries from the front desk to someone's room. I expect we'll be seeing street delivery drones like this soon as well in very high density urban areas.
Aerial drone delivery however ends up requiring additional infrastructure and is far too expensive for what it's trying to accomplish, particularly because of the small payload requirements. Maybe that will change in the near future, but I still think we're a long way away.
I am a staff engineer with 10 years of experience who has recently gone through the hiring gauntlet and dealt with something similar.
I interviewed for a company in May that gave me a takehome that was very vague and probably would have taken my entire weekend to do it. So I declined and moved on.
My rule of thumb though is to spend no more than 2-3 hours on a takehome challenge. If you think it will take any longer, don't do it. And lack of any feedback from the company pass or fail is ridiculous to me.
As for your submission it LGTM. I'd bring you in and probably ask about how you'd want to improve it if you had more time, expecting the usual best practices and scalability things. I'm not sure your Python experience, but given the context of the problem space, I'd ask why you wouldn't consider other approaches like adding the url metric logic in a decorator or some other modularization that could be reused to "performance test" future API calls. I'd ask about your submission's lack of tests (getting at unit tests here) and how you could refactor your solution to facilitate better test coverage if you had more time. Deepdive about the tradeoffs of using Python coroutines as opposed to other concurrency methods.
Unfortunately there's always going to be a desperate developer out there who will spend every waking second overengineering a solution that will set a high standard for everyone else to be compared against.
>I'd ask about your submission's lack of tests (getting at unit tests here)
Every commenter hit on this. I have my reasons. But it's so common that next time I'll be for sure doing it.
Lesson for me and everybody: for take homes write tests.
>I'd ask why you wouldn't consider other approaches like adding the url metric logic in a decorator or some other modularization that could be reused to "performance test" future API calls.
I would consider it. I just didn't do it lol. You can already use that test route to run integration tests, but the logic in that route is easily placed in its own undecorated function for usage outside of flask .
>Unfortunately there's always going to be a desperate developer out there who will spend every waking second overengineering a solution that will set a high standard for everyone else to be compared against.
I actually could've spared the time for more hours on this. But they specifically requested I spend no more than 4 hours on this. I think they've gotten things that obviously took much longer then 4 hours and they didn't like it. I think maybe I should've done it anyway just for adding unit tests. They can maybe tell that something took more then 4 hours if a project took 16 hours but likely not one that took maybe 6 to 8.
Happy to see a new edition! Great book, really helped remove a lot of the "well it's just dark magic" parts of how a computer works for me. Really can't recommend this enough to anyone who wants to truly understand how computer hardware and software works from bottom to top.
