Can we just ban coding posts that have no code? They usually give you an illusion you learned something but are a total waste of time. It's like reading a self-help post on following your biggest dreams or something. The hard part isn't these big beautiful ideas, it's how to actually put it in practice. How to actually take something away and measure whether abstractions or duplications are more costly in real code??
This seems like an anti-intellectual argument. For example would "ban" many of Dijkstra's famous numbered papers. I'm guessing you haven't read them.
While we're at it, why don't "we" just "ban"
- mathematical proofs without numbers
- all criticism, as it's about art but contains no art
- all papers in the field of music theory, since they aren't music.
It's definitely anti-intellectual. But people who run this site themselves say they're interested in high signal to noise ratio.
I don't think those are good comparisons. Better example would be a post about how to write rigorous math proofs and then not giving a rigorous proof as an example.
I think "examples might help" is valid feedback, but the author has sort of provided a reason why examples aren't included: in small projects the abstractions are usually worth it, was my read. So while the author could talk about examples, he probably couldn't include then in a piece of this size.
"Can we ban" is what has rubbed me wrong way. Who is "we". How are "we" "banning"? Does this just mean you don't agree with this post being highly upvoted? Or that you want to circumvent the opinions of those who upvoted with a "ban"?
It is interesting also to think about the irony of an argument that one should work in terms of concrete examples of the subject matter, in objection to a piece that argues one should not always abstract things.
The problem with his interviews is that it's even more easily gamed. It doesn't really take a genius to go through their employment history and memorize blurbs that show learning technologies, applying it successfully while being humble and nice for one day.
If an interview like that can be gamed by "memorizing blurbs" then it wasn't done correctly. A properly conducted interview will see the interviewer tugging at threads to go deeper. At some point they will crack because memorization won't be enough. Unless of course they are anpathological liar, but those are rare enough that I would ignore the posssibility at the interview stage.
You're right, I exaggerated but I don't think this is a hard game. People spend several months right now on studying interviews. The topics are wide and scope enormous, hence so many complaints; some companies test you on languages, others on algorithms, data structures, dynamic programming, bit manipulations, SQL queries, scalability, unix internals, I could go on and on. On the other hand, there's only so many paths these past history conversations can go, and you know where they can poke at.
