[austincheney]

> When I do technical interviews I assume the candidates code works (and it often doesn't, but that's not the point).

Why is that beside the point? For me, as the candidate, if the evaluation is only subjective nonsense then the more important objective qualities aren’t valued in the exercise and probably in the office. That is a huge turn off to me.

[onion2k]

Why is that beside the point?

Outside of interview conditions I expect people to be part of a team, which means they don't have to be able to solve the entire problem on their own. They can (and absolutely should) ask for help and advice from the other team members.

There is never a point in real work where it's all on one person. So the same should be true for candidates doing technical tests. If you demonstrate you can approach a problem well, you can write good code to implement the parts you could solve, but the end result isn't a working test then that's fine. In the real world you'd have had other people around to help with the bit you couldn't do.

[austincheney]

But this isn’t outside of interview conditions. In a production environment I would write production quality code.

At any rate now I know for next time precise questions to ask to ensure we aren’t wasting each other’s time. Had I known this before the code test I would have politely excused myself from consideration.

[onion2k]

Not sure I understand your point here. You're saying that in a production environment you'll write production quality code, but if you ask about the code style before the technical interview and are told to write production quality code you'll excuse yourself?

That just implies you can't, or can't be bothered, to write high quality code in a technical test. Why would you imagine an employer is going to overlook that and think you'll write better code if you get the job? That makes no sense.

[austincheney]

But, I was never asked about code style. I was asked to solve a well defined problem and only graded on unspecified code style.

Code style is subjective nonsense. If it’s that important provide a Schema or lint rules. High quality code solves a problem against a variety of objective measures: performance, complexity, instruction count, portability, and so forth. Things that can be measured with numbers.

The inability to differentiate subjective criteria from objective criteria is extremely immature. You wouldn’t write a contract like this or treat a business partner like this so why would a company treat a candidate for employment like that?

[onion2k]

Code style is subjective nonsense.

Some aspects of it are. I don't give a damn about tabs versus spaces, semicolons, etc. A decent code formatter fixes that sort of thing so it doesn't matter.

I absolutely do give a damn about things like breaking code up in to easy-to-grok modules, writing testable blocks, etc. In your response a few posts back you said "The feedback was only that the code was disorganized because all 750 lines were in one file and there was no test automation." That demonstrates to me that you can't write unit testable code, because you didn't write any tests and your code isn't broken up in to units. I can't write tests for a monolithic file like that without importing all of it and potentially getting side effects like prototype poisoning or globally scoped variables. That is a good reason to reject you as a candidate, and why you shouldn't write code that way.

[austincheney]

> That demonstrates to me that you can't write unit testable code, because you didn't write any tests and your code isn't broken up in to units.

The code is testable. I provide data samples to test against and documentation on forming original new data samples for further testing. This manner of testing is easily automated.

I explained my thoughts on this and various forms of functional testing before receiving the assignment. To me this means they either did not understand test automation or they needed internal unit tests to make sense of the logic even though I provided copious code comments and documentation.

Again, it reaffirms they either cannot read code or didn’t bother evaluating past code style. If I were happy with that level of immaturity I wouldn’t be looking around. I am glad though to have discovered that immaturity during the interview process before leaving my current employer. I just wish they didn’t waste my time with an unnecessary assignment when they could have formed identical conclusions by looking at my GitHub projects specified on my resume and discussed in detail during the prior interview.

My final thoughts then were that they either lied about their conclusions, in that they used code style but really it’s that they cannot read code, or that my time isn’t valued (thus I am not valued).