I agree with your motion of creating simple software, but removing learning complex approaches and complex software don't help with this.
Creating simple software requires understanding of what is complex and how to make it simple. There is no way that you can do this without learning. You either learn this by craft or learn through the practise.
Learn to talk to people and maintain connections. It is most invaluable skillet that will help you both carreer wise and professionally. The more people you know the better it is for your carreer. Learn to present yourself. Visibility matters very much, so it also good to "sell yourself" sometimes. There is really fine balance between making a sell and just bragging, people don't like second, but okay with first. Learn to teach other people and help them. Most troubleshooting experience I get now is from helping other people. They have a completely different way of doing code that I am (as a whole) and I am just getting this free xp by helping them and also adding one more trouble to my personal solution cupboard.
As for technology, pick what you like and master it, but also make a peeks at what is currently "in vogue". For example I really have no depth knowledge in the current frontend space, but I did take a passing looks (and build simple tutorial projects) with react, angular and dart. It didn't really required a much effort from me, but this helped in the long run to be aware.
Just a note by setting up a 30 hours home project you effectively removing "people with lives" from your hiring pool. People who can do a 30 hours either have a lot of freetime currently, or code after the job. And if you really want those people in the team then go ahead, but you are missing on 8 to 5 crowd and that is a very good and diverse talent pool. From my experience 8 to 5 minded people are very good in solving tasks in sustainable manner. They just don't have time to fuck with the system and doing effective "dont-call-me-at-night" solutions.
if you are doing a lot of interviews you need a common set of questions and measures and this take a lot of time and effort to setup.
Personally I would suggest to setup interview as a two parter first ask some theoretical questions and then ask to create a simple code with simple problem related to the questions. This helps to find out if people are really understand what they talking about. This again require a lot of thought to setup an to have small practical tasks relevant to the questions.
For example in most recent interview I asked candidate about algorithm complexity, data structures, garbage collection and then asked them create a simple dictionary to store a hierarchical structure. This helped to see if candidate knows what he is talking about and can use his knowledge in practise. I have seen a lot of people without good theoretical knowledge, but they create a code that is good and working despite their gaps and other way is also correct people have a good theoretical knowledge but fails to apply it in practice.
So figure out who you are searching for. Create an ideal checking solution for their skills and start combing the desert. There is no shortcuts in hiring, sadly.
I learned this lesson through one of my optimization tasks. Speeding up programm by just reducing input data by 80% solved multiple problems. And real eye openner was an "article" about grep: https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html
Basically if you have less work you will do it faster. Since then my first question is always: Can we do less work?