Real engineers must be able to recognize an impossible design spec, and respond appropriately. (Where 'appropriate' depends on the circumstance.)
In the Electrical Engineering finals papers at Imperial College Professor Eric Laithwaite used to set one question that could not be answered in the available time. He expected his students to recognise and avoid that question.
I wonder if you could get away with that nowadays?
Probably not.
Someone would likely get up in arms about it and challenge the validity of the test on the basis that the discernment necessary was not a core part of the subject being tested and that valiant efforts to answer such a question simply wasted time.
The fact that such decisions need to be faced frequently in the real world would not be considered relevant.
That is, until you get out there.
This reminds me of the recent thread about a Leftist lady professor of Elec Eng proposing that 'engineering rigor' was some kind of white male entitlement rubbish.
The story about prof. Laithwaite's 'impossible to answer in the time available' exam question is nice. Every engineering exam should include one; feelings of those who fail it be damned. That's the whole point - anyone who argues such a question was unfair should not be an engineer. I wonder how the designers of that tensioned concrete foot-bridge that collapsed would have handled Laithwaite's question?
Engineering courses should include a section on recognizing situations where going along with perceived expectations will lead to disaster. Cutting costs and time with bridges, attempting to solve impossible questions in exams, allowing a Shuttle launch at temperatures below the design safety window, or whatever.
Edit to add:
@eecook. Other desirable engineering attributes, are openness, honesty, and not over-thinking problems.
OK, so you are geographically isolated. I can empathize with this. Australia is similar, though not as severe. In any case my own circle of friends now includes not one other ee-engineer, or even any kind of engineer. (Since a good friend died last year.)
So you are 'limited' to what you can gain from the Internet. Be thankful you do have that vast resource, unlike earlier generations (me & my friend) who had no such thing for most of our lives.
Anyway, you've learned something from this. When you have a problem to solve (for eg finding ways to improve your own skills) to get assistance from the international community, best to ask the exact question. Not construct some convoluted scenario that you hope may lead to something relevant to your needs. One thing to _never_ do on the Net, is let yourself be perceived to be devious and misleading.
By the way. As others have pointed out, there is NO WAY any engineer is going to do a whole, complex design (eg your solar power supply in a small box) just as an exercise for some skills evaluation. They _might_ be prepared to show details of past designs done - but probably not, as those will likely be proprietary to previous companies they worked for. If they did give you such details, you wouldn't hire them anyway, since they just demonstrated they can't be trusted to keep commercial secrets.
Letting you briefly view documentation, or showing actual PCBs and proving they designed them (and they worked)... that's workable.
Another way to find out a lot about what someone knows, is to hand them some random consumer electronics product, or tech instrument, and have them take it apart and give you commentary on how they think it works, what each component does, functional areas of boards, etc. Maybe you could suggest it has various kinds of faults, and ask where they would start looking for the problem. Or ask how they would improve it. Focused casual conversation can be very revealing of general tech knowledge. If you want to see their practical skills, get them to replace some part you specify, using your equipment.
Even small things can be significant, like whether they handle PCBs/parts in a static-safe way, and whether they know which kinds of boards and components would be static sensitive, and which are not.