I hear that accusation a lot, but I’ve never really seen a company do that. Having been in the other side of the equation many times, the effort required to review code that’s submitted, especially when you don’t know the author is probably not worth it.

The case I detailed above was a fairly isolated subsystem that didn’t really require any knowledge of their system to work on. They probably chose it because A. It was a readily available problem with an existing solution that you could reasonably expect to be solved within a couple of hours , and B. the CTO thought he had a cool solution.

Yeah. Owning code is about taking responsibility for it being in a satisfactory state, it shouldn’t be overly personal and you also shouldn’t attack people directly when the code has problems. Everyone makes mistakes, learning from them is there important thing.

It was a really small startup where the CTO was one of the founders and had written the first version of everything. I don’t mean to belittle what he did, I have a lot of respect for people building thins from the ground up.

It was just a very odd episode and illustrative that you don’t always fail because you’re bad at coding.

That sounds like a very sane and sensible way to behave.

I do have other things to do during the day :-)

Really, it isn’t meant to be. I’m Just trying to say it’s not always the candidate at fault.

This is one example from a great many interviews I’ve had in my time, most of which went much better.

What I’m about to say might come off as smug. I don’t mean it to be a flex, it’s just for context.

I’ve been programming since i was 6 years old, and have 26 years of continuous professional experience. 30 years of open source contributions. You are almost definitely interacting with code I wrote on a daily basis.

7 years ago I was caught up in a round of layoffs and I was scouting around for jobs. I got an interview at a startup - it wasn’t a huge tech challenge, but I needed a job.

I did an initial technical interview with the tech lead for the company. All went great. I did a “final HR interview” , again great. Then the CTO stepped in and said that he would need me to complete a coding test before I could be hired.

I failed that live coding test despite producing code that outperformed the code in the “correct” solution by several orders of magnitude.

The CTO was clearly upset by my solution, which he got very angry about and insisted was wrong, without explanation, and despite it beating the spec and passing all the predefined tests.

2 days later the tech lead, who was also present in the test, told me there was nothing wrong with my code. Better still they had actually taken it and put in into production in place of the code that CTO had written, and which was the basis of the “correct” solution.

He also told me that he’d quit after an argument with the CTO about this and asked if I found a good place to work, if I’d let him know.

Sometimes tests are not about what you can do, but how smart they make the person testing you look.

Culture flows down from the top, I’ve been places like that. It won’t change any time soon. If you want autonomy and trust, your best bet is usually to join a small company, just be careful that you don’t join one where the leaders are so hands off that it dissolves into chaos. It’s a difficult balance.

This is actually really common in Germany. Not generally in big firms, but the whole office complex where my company is based in Berlin, declares itself dog friendly and you can just bring them in.