Hacker News Reader

Comment by mirsadm | Hacker News Reader

It could be many things. Your solution may have worked but that is only a small portion of the task. When we were hiring ages ago we'd look at style, formatting, structure, etc. This is especially true for a small company. The place I use to work at was small with only a handful developers that were really passionate and opinionated. We often had discussions about simple indentation or placement of a bracket in code that could go for hours. When we hired people it was important they fit in into this culture.

View on HN

by this culture, do you mean a dysfunctional one? The braces / indentation formatting argument is one that has come up in a place I used to work (on many occasions) and generally it seems to be this is indicative of people focusing on the wrong things, I still don't understand why, when there are so many larger issues to address, that this comes up time and time again, in the case of the company I worked for, this was just the tip of the iceberg as seemingly every topic would devolve into a meandering, pointless "discussion" (argument) where if they would just stick with known conventions a lot of wasted time would be saved.

Actually in my experience it is always the small details that make a product great. Granted, source code indentation is probably not one of them but it was indicative of a group of people that really cared about their work. You tackle the larger problem by solving small ones. I have always found people that focus solely on the "big picture" then to miss it entirely.

Its a convention vs configuration issue, some people seem to prefer configuration where they tinker around with every detail, this seems to be prevalent with Java as it has a background of "configuration over convention", it seems. Sure, its my opinion, but I prefer not to sit around debating about a problem where there is no real benefit of one over the other, where its really just a matter of personal preference, like in the case of code indenting.

Personally I'd regard it as a bit unfair to be rejected just on the grounds of code formatting. I've changed my indentation style before to meet a "house style" and would do so again if asked.

In my opinion it would be more useful to see if the candidate seems prepared to change and has thought about the reasons for their style choice.

(Plus I admit I probably should know the precedence rules for my languages of choice off by heart, but sometimes it's easier just to put extra parentheses in than wait for a compilation error or, worse, an inscrutable bug - especially if you're up against the clock or being watched in an in-person interview)

I completely agree. I really meant to say that we looked for someone who was passionate about coding and they could defend their style/structure because they cared. We always worked in the style/structure of the original author because the code should be consistent. That is more important over personal preference.

Our arguments over small things like indentation were heaps of fun because everybody there was really passionate. It was never about enforcing it because it is the one and only way to do it. Stubbornness on matters like that is not good.

Reply on news.ycombinator.com