Comment by flukus | Hacker News Reader

Comment by flukus | Hacker News Reader

Parent Full thread

> Why is the candidate asking this question in the first place?

Because every company says "we take quality very seriously" and standard crap like that, looking through the code and the most recent contributions is the only way to actually assess them.

> It makes me wonder if they’re inflexible or unwilling to be pragmatic about imperfect code.

Which is perfectly reasonable when the hiring companies try to avoid being pragmatic about imperfect people. They'll give stupid codes tests and look for rockstars, this is the employee equivalent. Rockstars are picky about their collaborations.

> Can they really learn anything about the codebase in the limited interview time we have? They’re not getting repo access.

Ideally I'd want to run some tooling over it and get some stats like cyclomatic complexity and collaboration graphs to see how many pointless layers they have. I'd also take a look at their unit testing to see if anyone in the company actually understands what a unit tests is.

Interviewing is meant to be a two-way street and code review is the only way to address the information asymmetry and make this true.

I absolutely agree that this is the employee equivalent of "jumping through hoops".

With that said, for the companies I've hired for in the past someone who sees the state of unit testing as a dealbreaker would likely be a bad fit. If they're hiring it might be because the company needs more hands to help make the tests better!

if this were actually true I'd be pretty on board. there is a mountain of half-assed code out there. cleaning it up and making sure its adequately tested can be pretty satisfying.

unfortunately those are things organizations like to make lip service about fixing. often times the state of the project is symptomatic of underlying structural issues in the organization that they aren't really willing to address.

It really depends on how the rest of the interview process goes, if they said their tests were in horrible shape and were committed to making it better then it's not a dealbreaker, even less so if they can point to some commits where they've improved things. The two common types that you can sus out with a code review are the bullshit artists and the ones that really do think the code is great.

There are other factors too, I work somewhere with mountains of horrible code, but they compensate by not putting you under pressure and giving you time to work through the mess. If they had the same code and constant pressure then I'd be long gone, life is too short for that.

I'm really surprised by the opposition to the idea, we all seem to agree that good devs are in high demand but few on the hiring side seem willing to bend to that reality. We all seem to agree that hiring is expensive but the hiring side doesn't seem willing to let the candidate who will walk in a month eliminate themselves.

Reply on news.ycombinator.com