Same. I interviewed with Amazon twice and it's like a 10-hour meat grinder. No offer either time and I have no idea what I did wrong.
I absolutely don't get those wide open questions like "How would you design 1-hour delivery?" (real question btw). As someone who has done a lot of consulting work, my instincts are never, ever try to answer such a ridiculously broad question on your own with no context. The answer to me is to budget for several weeks of planning with a broad range of stakeholders to prioritize features and come up with an initial technical approach that we can refine after an MVP launch, but I don't think that's what they wanted to hear.
>I absolutely don't get those wide open questions like "How would you design 1-hour delivery?"
Quick tip: interviewers often design that kind of question to be intentionally vague. If you get a question like that, they probably want a bunch of questions before you start on an answer. Like, "which part of the process are we designing? The software stack, interfacing with logistics companies, customer service?"
It seems frustrating, but they're looking for people who will drill down and make sure they fully understand a task before they run off to solve it. Asking for clarification is usually a good thing in an interview, especially since the interviewers don't always think the problems through completely.
The lack of feedback seems like a liability thing. A very small number of people will sue because they don't like the reason they were given, so the company decides not to give detailed feedback.
Your interviewers rarely have real world consulting experience, meeting with clients and solving real problems tied to real money. What they mean by that "1 hour delivery" is a system design question that must be answered along the standard system design template, which is completely detached from reality. You should lookup up those system design interviews on youtube, ala "design a tinyurl service".
There is no stock right or wrong answer for those kinds of questions.
You should ask questions to understand which area the interviewer wants you to concentrate on (if any). Some interviewers are happy if you choose an area where you can showcase your experience, others expect you to answer an area they have in mind. If you cover enough, with enough detail, they will be happy. Ask questions.
There is a correct answer actually, one which can be studied for. That question is a system design question, they wanted you to come up with some architecture for it, that you will know once you study system design. To do so, just search up "system design questions site:GitHub.com".
It sounds like a super fun question. I'm almost tempted to start thinking about it even though I'm not interviewing for anything.
Given how many features AWS alone ships every year, I'm sure Amazon is very familiar with prioritizing features and building MVPs. But you're interviewing for a software engineering position (I assume) and the question is explicitly about design, so project planning is off topic here. It's fine to mention it in passing, but the meat of the answer should be about the "initial technical approach" that you mention.
Your comment suggests that, due to your consulting experience, you flat out refused to draft an initial technical approach on the spot. That may be wise is other situations, but you aren't here as a consultant. Amazon isn't going to start implementing 1-hour delivery based on your plans. They're asking this question to see you think and work your way through a complex problem.
Additionally, your answer is so vague that it could apply to almost any question ("How to do X?" "Gather stakeholders and come up with an initial technical approach").
I absolutely don't get those wide open questions like "How would you design 1-hour delivery?" (real question btw). As someone who has done a lot of consulting work, my instincts are never, ever try to answer such a ridiculously broad question on your own with no context. The answer to me is to budget for several weeks of planning with a broad range of stakeholders to prioritize features and come up with an initial technical approach that we can refine after an MVP launch, but I don't think that's what they wanted to hear.