"If I take a letter, lock it in a safe, hide the safe somewhere in New York, and then tell you to read the letter, that’s not security. That’s obscurity. On the other hand, if I take a letter and lock it in a safe, and then give you the safe along with the design specifications of the safe and a hundred identical safes with their combinations so that you and the world’s best safecrackers can study the locking mechanism — and you still can’t open the safe and read the letter, that’s security." --
Applied Cryptography, Bruce Schneier
If you distribute a program with broken security, it needs testing and fixing. If this was a real program, as opposed to an exercise, it would have gotten a security advisory.
So, the only failed "test" here would be writing a reverse-engineering-resistant program and expecting that to provide "security", and that's less a test of morals and more a test of competence. But as an exercise, written to be intentionally buggy, this was quite good.
Now, a good question to ask before this exercise would have been to ask the inverviewee to discuss the idea and implications of prompting for a password in a client-side application; look for them to explain public/private key cryptography and security versus obscurity.