You often needs to fail to learn some lessons. I even encourage trying to fail if possible 
Listening a great talk or reading a great book - they are also essential eventually, but without tackling an actual problem they would remain an advice, not become your knowledge.
I agree with this. The question then becomes what kind of projects should one tackle in order to grow?
For CRUD application there are countless examples beginner developers can create in order to learn: To do list, blog website, restaurant and etc… There aren’t too many project examples for intermediate developers to practice on.
The first thing I tried to write in Elixir was an auction application for my fantasy football league. I built it such that it could support multiple auctions going on in different leagues concurrently. That felt like an intermediate introduction to Elixir and especially OTP. Since then I have worked on a charting library and a little toy Phoenix app that demonstrates that library.
From all of that, the advice I would give for a learning project order would be:
I think not starting with Phoenix made Phoenix much easier to understand at an intermediate (as opposed to “I know who to write a CRUD app with it”) level once I got to it.
You may do toy projects (such as elevator example from the interview), or try to do different approaches at work even you already know “some” pros/cons already.
Of course it may be a little bit difficult to find right sized project ideas. You may explore them by tech (e.g. OTP) or by domain (e.g. real-time game) if you don’t have enough opportunities for experiments at work.
Typically you can learn a lot even at work by doing under/over-engineering 
The answer very much varies from company to company. Just keep trying and get feedback from the interviewers. Learn what they where looking for and why did they think you wouldn’t provide it instead of focusing on specific questions and answers.
Discuss with other people in team. Such decisions shouldn’t be done authoritatively by anyone (doesn’t matter how much “seniority” they have). So if you want to have “real influence” on architecture, then discuss with the people who are making these decisions right now. At the beginning questions like “why?”, without any additional input, are good as well for 2 reasons:
Some project ideas:
I agree with this approach.
It’s funny, when learning elixir and backend I went the opposite direction of your recommendation. Which I think is okay. But now if I want a more solid understanding of OTP I agree with your ordering. With your response, @chulkilee and @JEG2 I believe I have the example projects to tackle.
My personal strategy for growing quickly was to always pick the hardest problems/tickets that were available. Always jump into the deep end, but have a lifeguard around i.e. a more senior developer who can help you if you get stuck. It’s hard to grow if every problem is familiar to you.
I’ve been listening to some Elixir podcasts (and other software podcasts, too) in my free time and I’ve noticed that the topics, while related to the language, are usually about software engineering in general. The Elixir community has a lot of smart people in it and hearing some of their experiences really exposes you to new topics that you’d otherwise only hear about further in your career.
This doesn’t replace actual experience, of course, but I feel like it’s a nice addition to my efforts.