>you don't over-engineer but you keep it as simple as possible It should also mean you don't under engineer, but that is extremely hard to test for because tha

>you don't over-engineer but you keep it as simple as possible It should also mean you don't under engineer, but that is extremely hard to test for because that involves knowing the business and your customers and having a reasonable estimate of where future needs will be. I'm not sure how you would test for lack of under engineering, especially since any interview task would be a perfect case where you practically can't under engineer since it is guaranteed throw away work. Maybe asking during code review for how you would've done the solution different if you knew that in the next quarter you would likely have to implement either feature A and B or C and D (but you didn't know which yet).