[plughs]

I had a 2 hour coding project in a language I'm familiar with - entirely based around a sub module that I've never used before.

Maybe 2 hours should have been enough? I don't know - with the stress of writing under time pressure ( I had a new sympathy for contestants in cooking shows ) and complete unfamiliarity with the module, I was pretty impressed that I submitted something that passed the unit tests.

Then I got rejected with the implication that I wasn't using good OOP principles. OK, my decision to store JSON data as a byte array was unorthodox - but it worked without a lot of coding overhead. I thought it was pretty clever frankly.

[brigandish]

I'd be more impressed if they had a mock code review as a discussion afterwards where you could explain your decisions and they could question/challenge parts of it. Not only would that give you time to settle, it'd give both parties some real insights into expectations, skills and work practices.

Something like: "Why did you store it as a byte array?" and then "How can you reconcile it with OOP principles?" as follow up questions would be far more productive.

"Which principles do you mean? If I write an object then it only matters to the caller what the API is, not the underlying storage, right?" and before you know it you're in an interesting conversation where you both have the opportunity to learn something.

It'd probably be quite enjoyable, regardless of whether you got the job in the end.

[mixmastamyk]

Yeah bullshit, in the real world you’d refactor.

[hvidgaard]

There is three types of developers in this scenario. Those who "do it right from the start", they are slow. Those that do the quick and dirty, and create an issue in the issue tracker about what to change and why. Then there is those that do the quick and dirty with mental note about what to change, and never return to it.

I do not want the latter.