I liked this article about "semantic compression"[0] by Casey Muratori very much. He also posted some video lectures fairly recently about what he calls "non pessimisation" (a term that I personally didn't read anywhere else so far), which is mostly concerned with performance, but the idea is to simply avoid and isolate abstraction and indirection and programming in a style that adheres to what some people describe as mechanical sympathy.
It basically comes down to:
1. Write the code that makes the computer do what it needs to do to achieve a specific goal. No more and no less.
2. Refactor ("compress") the code by deriving re-used (implicit) structures and functions.
He puts a lot of emphasis on those steps being done in order and on deferring the second step
Note that this is from someone who writes games/engines/tooling so there is a large, real pressure to write simple and reasonably performant, optimizable code. He would also prefer that most of programming would be done in this way.
I cost myself a position recently arguing about this.
I had a first round interview that went well, and was given a take home and the problem was very simple, dead simple. In turn I tried to keep the code as simple as possible, with only necessary abstractions.
The second interview was with an entirely different person who seemed displeased I didn’t bloat the solution with all sorts of enterprise patterns, dependencies and conventions. I was kinda backed into a wall and while attempting to explain my reasons I ended up in an argument with the interviewer and it was clear we did not see eye to eye. He would later challenge my ability to perform in a patronizing tone and I was sure the opportunity was dead
It wasn’t the only thing that went wrong with that interview, but I feel that disagreement was the biggest killer.
>In turn I tried to keep the code as simple as possible, with only necessary abstractions.
I always talked the talk and walked the walk for the interviews. I know people love Solid, design patterns, Dry, OOP, Restful, Clean Code, complicated architectures. So I am always willing to talk about these and even sprinkle the discussion with the most obscure design patterns they may never heard of.
Yes, I do consider some of these being fads or even detrimental to good software but my goal was to be employed, not to convince people that there is not only one True Way.
That would be your everyday experience. No reason to not be picky right now. I would go crazy having to work with over-abstract code for OOP religions sake