A few months ago I was given a pre-interview assignment for a company. The task was simple, read some data from a file and put them in a database.
Many areas of the design had a varying degree of complexity: From the simple solution, to my preferred belt-and-suspenders style, to fully-blown over-engineered superstructures, with me going out of my way to use every language feature I know how to. I decided to go for midway between the latter two, to show that I know how to do stuff. Accompanying documentation provided some justification over some decisions, as well as clarifying sections of the code, to save whoever was going to read it some time.
At the interview I was questioned about everything in my code, apart from the standard basic round of questions. To clarify, I wasn't asked about design decisions, but rather "I see you used an Abstract class here. What does Abstract mean in [this programming language]?" I didn't get an offer, but I strongly suspect it was due to other factors, because the technical part went pretty well.
So, that level of complexity (light over-engineering) got me an interview this time. Is this a viable strategy long-term, or should I go for simpler designs which are potentially easier to read?