[austincheney]

It could be worse.

I recently had an interview with a 5 day code assignment to build services, perform data transform against several competing requirements, and some other things. I provided lots of code comments, interactive documentation, test data samples, and a detailed readme file about as long as the code to explain how I went about things and how to reproduce my results

The feedback was only that the code was disorganized because all 750 lines were in one file and there was no test automation. I really got the impression they didn’t even look at the code or execute it to see if I achieved success or followed instructions. Felt like they were just wasting my time.

All my big GitHub projects are on my resume. They could have given me nearly identical feedback by looking over my GitHub projects and not waste either of our time with this ridiculous assignment.

On the upside I view this as a somewhat positive thing because if their developers can’t read code then I probably be miserable there.

[onion2k]

The feedback was only that the code was disorganized because all 750 lines were in one file and there was no test automation.

These days a coding test has a pretty standard minimum set of features to get a pass, and they include reasonably well organized code and having some tests. If you're working alone those are less important but as soon as you join a team they're critical.

I really got the impression they didn’t even look at the code or execute it to see if I achieved success or followed instructions.

When I do technical interviews I assume the candidates code works (and it often doesn't, but that's not the point). I review it first, then I see if it meets the acceptance criteria. If your code isn't the sort of code that would be acceptable in the organization it doesn't matter if it works.

I would rather reject a candidate on quality than failing the test. Also, occasionally, if the candidate has made an obvious error that stops their code working but it's clear they write great code I might still recommend making them an offer.

[was_boring]

I don't want to be argumentative at all. I find what passes at one company doesn't at another and it's generally an interpretation of style that can be conformed to. For example, I am of the leaning that one line should do one thing only, and should be explicit -- which is different then many modern practices. Another example is array manipulation which, depending on the operation modifies in place and I reassign for clarity.

Does that make me a bad engineer? No. It makes me experienced. If any of those things aren't wanted at a future employer I can change to match the style.

To reject based upon that when the style isn't defined by tooling is weeding out great people who may not confirm but have the ability to.

[austhrow743]

As long as they weed out a high percentage of not very good people, companies accept weeding out some great people as a cost worth paying.

[was_boring]

Very true. I have been working at startups for a while as a hiring manager and one of the skill sets I've had to develop is finding good people who have been passed on by FAANG or who come from a non traditional background and never would make it past there filters. Simply because we can't afford the salaries, but still pay six figures to non bay area employees. It's been interesting watching the "I should work for a startup" to "I should work for FAANG" over the past decade.

[mooreds]

> It's been interesting watching the "I should work for a startup" to "I should work for FAANG" over the past decade.

I would be interested in your thoughts on this. Is it because of salary, opportunity or security?

I am outside the Bay area.

[was_boring]

I think it's do to two reasons: 1) salary at FAANG can be 2-3x what a startup can offer, granted that's in the Bay Area; and 2) there's been more then a few examples of equity not being structured in a way that is beneficial to early employees. Sam Altman even has a blog post that says startup equity needs a revamp.

[CaptainZapp]

For example, I am of the leaning that one line should do one thing only, and should be explicit

I agree. And this is actually the very reason why I can dig into a 5 year old, reasonably complex bash script of mine and successfully maintain it.

[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?

[alexhutcheson]

If you don’t write unit tests on an assignment like that, you’ve pretty much failed. I made the same mistake in a similar situation with a different company. It’s tough because the expectations aren’t spelled out clearly, but unit tests are non negotiable.

[speaking personally, not on behalf of my employer]

[slifin]

I suppose interviewers regularly fail people for less than this but it's just ridiculous I bet if the interviewee is told to add unit tests the majority could and would

It's not a test of skill so much as a test of expectation, hidden expectations are the worse to deal with in an interview

If we're going to wag the testing finger and say always unit tests then why not always generative tests? They'd always test more inputs, why not spin those tests infinitely? Did they test in the repl? why not always mutation testing? why not always integration testing?

I don't think people like to realise that testing is a spectrum of confidence you'll never reach 100% nor should you expect to

Dealing in bullshit absolutes here is stupid, talk to your interviewee about what they could do to ensure their code complies with its intent instead of springing hidden expectations after the fact

[austincheney]

I prefer to perform functional tests in my automation, such that you prove the application does what it claims instead of testing the internals to prove a function outputs the right data type. This seems like unnecessary tech debt that can be solved for in smarter ways, like a strongly typed language.

But had they included this as a requirement I would have provided it. I am not in the habit at guessing informal unspecified requirements. If that is an indicator of their internal communication then I suppose I am glad I failed.

[robteix]

> I really got the impression they didn’t even look at the code or execute it to see if I achieved success or followed instructions. Felt like they were just wasting my time.

I don't know anything about where you interviewed and of course this may not at all be true for them, but bear in mind that the point of home assignments is rarely "does it work?" That the candidate followed instructions and that the project "works" is expected. What many companies are looking for is seeing how you document, how you organize, how you test.

Again, I don't know what happened in your specific case. Just a heads up that writing tests, documenting and writing good commit messages are usually what people look at first when evaluating a home assignment.

[ThinkBeat]

All code being in one 750 line file is a bad thing. It would never pass a code review where I work.

I would not really care if it worked or not and have the team or developer come back with a broken down version. (which if the code is structured well inside a single file should be very fast to accomplish)

[charleslmunger]

Splitting a 750 line file is not a readability improvement, if all the logic is related to and part of a single task.

Splitting code across multiple files when there's no actual reusability or abstraction driving the split makes it harder to follow the flow of logic. In particular, 750 lines is not so much that there's obviously a missing abstraction lurking there.