" Functional style though, broken out into 1-3 line functions that only do one thing -- similar to what you'd expect from a Rubyist."
I'm pretty laid back generally and I'm willing to overlook many things, but I think this is one of those where I'd vote against hiring, since I'd never want to maintain such code.
Following the logic of algorithms would be for instance really hard because of having to jump around all the time.
That's not how that works out in practice though. When each function does one thing, the cognitive load is low and you name things appropriately that make understanding each function on its own easy. You can scan an area of code quickly and find problems without having to build the whole house again in your brain.
It's much clearer when you hit some unintended edge case then having to maintain a mental model of a huge function doing a lot of things.
If your way of grading someone's code is to make sure you can build the whole house in your head, rather than have an exhaustive set of test cases to validate your specification and a simple "each function is appropriately named and does exactly what's intended in the correct manner", then the grading method is the problem, not the code.
You're talking about something different now though: initially you were mentioning functions that are 1-3 lines in size, but now you're describing functions which do one thing, without talking about the size at all. I was very specifically criticizing tiny functions. There are two big issues with such functions:
* the overhead in LoC of declaring and defining the function is between 30-100% of the function body!
* like I previously said following even simple logic becomes an exercise in jumping around the code. Never mind the whole house, even a simple loop barely fits into a 1-3 lines function.
I had literally said "that do only one thing" in the section that you'd quoted.
I've always been talking about that.
LoC aren't a metric. We're not getting paid per line and we're not playing code golf either. It works, it passes tests and most importantly, it's easy to change.
As for the comment about loops, both the languages I mentioned have powerful map functions. The goal of keeping the functions small is to avoid nesting loops and heavy amounts of indentation.
You said you broke your code in functions of 1-3 lines, I offered an explanation why that may have not been well received in your interview. I understand that you don't agree with that and that's fine with me.
That's what names are for. I prefer to find _afterLeft_ spread all over the place rather than `x2<=x1` even if it actually increases code size by 50%. I can validate it only once, and if I stumble upon _aboveBottom_ I don't even need to validate it to infer what it means (left as an exercise for the reader).
This spaghetti line: `x2<=x1&&x1+w1<=x2+w2&&y2<=y1&&y1+h1<=y2+h2`, in my opinion, is much harder than `inside`.
x2 <= x1 is actually a one liner which could arguably be transformed into a one line function. OP was talking about splitting an entire program into 1-3 line functions, or at least that's how their sentence reads to me.
I'm pretty laid back generally and I'm willing to overlook many things, but I think this is one of those where I'd vote against hiring, since I'd never want to maintain such code. Following the logic of algorithms would be for instance really hard because of having to jump around all the time.