tropicalia

If you start an argument with a false premise (like the above), then sure, you can come to just about any kind of conclusion you want.

The GNU perspective is very distrustful of the idea that anyone else should be administrating their devices [etc etc]

Which is a perfectly reasonable position to have, and no one takes issue with GNU for having it.

What one takes issue with is the consistent use of manipulative language, egregious omission of context (e.g. like what was just said about Google in the post above) and other generalized mindfuckery that GNU folks seem to routinely resort to in order to get you to buy into their shtick. As exemplified in the article referred to in the original post for this thread.

And which has gotten to be way beyond old. For like, multiple decades now.

The same way countless other endangered subsets of humanity (particularly those facing essentially total annihilation by, or permanent subservience to a foreign occupier) have: by recognizing the simple the simple fact that they'll either have to put their heads together, put aside their differences, and "figure out a way" to prevail against overwhelming odds --

or face the inevitable consequences of failing to do so.

So whether it's about software coming from GNU or FSF (or something endorsed by Google) doesn't really matter, in this context.

At least there seems to be some general agreement (within the thread) that, while not super-hard -- it's still basically a "eureka problem" -- that is, even among what we may consider to be adequately good engineers -- some will get the visual solution more or less right away; but a fair percent (25 or more) won't.

And that's given ideal circumstances -- working alone and in unhurried circumstances. Throw in the (considerable) distraction of having to think aloud in front of other people (who themselves may not exactly be providing the most relaxing vibe, to say the lease), and all the other stress that comes with interviewing -- and I'll bet that 25 percent failure rate rises quite considerably, in turn.

And in many cases -- if you fail just one of these "eureka" problems -- and maybe fail to provide the expected canned response to a "behavioral" question or two -- than that's pretty much all it takes. To be considered, you know, "not a fit".

As to why I jumped the gun -- fatigue, probably, from being fed a few too many "cute" problems like these.

In other words, a good chunk of New York’s transportation infrastructure [including the Holland Tunnel mentioned in the previous paragraph] could collapse, at any point.

With no substantive support. (It may be behind on maintenance; and like various subway tunnels, and it may not fare too well during the next major storm, requiring lengthy, expensive repairs. But that's a far cry from "could collapse at any point").

What stands out about this tirade -- and why we need to call it a "tirade" -- is the complete absence of any mention of opposing factors. As in, you know -- the reasons why plastic bans are being proposed in the first place. Instead we are told that the idea of banning them just "brainless" lunacy that "you can't make up."

What a nice, simple world the author seems to live in.

But (massive) empirical evidence demonstrates that, by and large - the private sector won't do the right thing (or even "the common sense thing"), in this regard -- at least not at adequate scale -- unless it is very tightly regulated.

Indicating the intimate involvement of the Chinese Communist Party (CCP) in the investigation of the airline, Hogg's resignation was first made public by Chinese state-run media outlet CCTV at 4:50 p.m. on Aug. 16. It was not until 5:14 p.m. that Cathay Pacific itself officially announced that Hogg was stepping down as CEO, leading to speculation that his resignation was the result of pressure from Beijing authorities.

Yup - we might say that as a topic, it's been discussed throughout the ages. For example there are the findings of this guy Paul the Apostle (as summarized by an unknown transcriptionist sometime in the 1st or 2nd century):

For the love of money is a root of all kinds of evil. Some people, eager for money, have wandered from the faith and pierced themselves with many griefs.

-- 1 Timothy 6:10

Even if we leave aside the question of to what extent facility at competitive programming contests actually correlates with success in real engineering environments (my own sense is: yes it can help; but at the end of the day, just not all that much) --

if that's a skill you consider to be important, then for gosh sakes, put it in your job ads. Something like "We typically hire CS olympiads, and folks who have at one point or another have been fascinated by competitive programming contests. If this doesn't describe you, then this probably isn't the right company for you."

The unstated implication in most cases is that you damn sure are supposed to solve it - or get "flushed".

As to "seeing how the candidate behaves in front of a difficult and concrete problem" - I'm sure this is what a lot people who ask questions like these think they're achieving by asking them. But again, you have to ask yourself if that's what the questions actually do permit you to assess.

My sense is that it's not - and that questions of this sort are mostly, well - cheap gimmicks, basically.

As if it's a given the whiteboard process actually provides a useful measure of technical competence.

[statement of the Maximum Subarray Problem]

Before going further—and regardless of your coding proficiency—we’d like you to spend a few minutes and take a stab at this question.

From Wikipedia:

The maximum subarray problem was proposed by Ulf Grenander in 1977 as a simplified model for maximum likelihood estimation of patterns in digitized images. ... Grenander derived an algorithm that solves the one-dimensional problem in O(n2) time, improving the brute force running time of O(n3).

Jay Kadane of Carnegie Mellon University soon after designed an O(n)-time algorithm for the one-dimensional problem,[1] which is clearly as fast as possible. The same O(n)-time algorithm was later automatically derived by algebraic manipulation of the brute-force algorithm using the Bird–Meertens formalism.[2]

If you really think anyone -- short of a faculty-level algorithm specialist at places like CMU -- can be reasonably expected to derive an optimal solution to problems like these on the spot (as opposed to the way candidates are actually forced to prove their ability to "solve" them: by binge-cramming on dozens and dozens of problems like these for weeks on end, so that they have at least a 50 percent change of passing your "filter") --

the you're either very naive, or deliberately kidding yourself.

Sounds very bold.

I'm assuming the author made a similar plea in regard to the refugee crisis in Syria - yes?

https://en.wikipedia.org/wiki/Potemkin_village

but I wish someone would think of something to "Change Everything" so that one day we'll see fewer clickbaity article titles.

Yes (and you'll find a lot of advice from experienced hackers emphasizing this point).

If not exactly the first language you start using -- at some point one should definitely start making a serious investment in a language with what we might call "solid bones" (that is, strong CS fundamentals). Or at least wit a high "fundamentals-to-fluff" ratio (and most especially a high "fundamentals-to-cruft" ratio).

Which isn't to say that "fluffy" languages (like Python or Ruby) are always bad. Or that crufty languages (like JS) cannot in some contexts be "good enough" (and certainly good enough to pay the bills).

But the point is, one should at least know (and know through grit and experience; not through second-hand opinion) when one is in a fluffy or crufty environment (and how it is that one got there -- hopefully by being consciously aware of the tradeoffs involved).

A key trait of inexperienced programmers is not that the use or don't use certain languages (or databases, or other tools). It's that they don't recognize situations when they're using an (inordinately) crufty one. For the simple reason that they have... insufficient basis for comparison.

Multiple easily findable sources suggest that the median tech salary at Google is well below $150k -- probably more like around $130k.

I get your point about the "whining" -- but while the average Google definitely does better than someone with a non-tech salary -- it most cases they aren't bulge-bracket either, or anywhere near it.

This is a straw man argument. The critique made of Google is not that has come to embody "true evil". But that it has (by degrees) slouched towards moral ambivalence, and acquiescence of (yes) evil.

Serving banner ads across sites does not even remotely compare.

I think you are perfectly aware that Google is engaged in a lot more than simply the business of serving banner ads.

That's not to get into an overall advocacy debate in regard to JS, btw. But even its staunchest advocates will acknowledge that it can be quite slippery to work with, in certain parts.