kafkaesq

Meanwhile:

The mayor of San Juan lashed out at Trump administration on Friday, decrying its relief effort in the wake of hurricanes Jose and Maria and saying if it doesn’t solve the logistics “what we we are going to see is something close to a genocide”.

“We are dying here,” Carmen Yulín Cruz said at a press conference, speaking with tears in her eyes. “I cannot fathom the thought that the greatest nation in the world cannot figure out the logistics for a small island of 100 miles by 35 miles. So, mayday we are in trouble.”

Cruz appealed directly to the president, saying: “So, Mr Trump, I am begging you to take charge and save lives. After all, that is one of the founding principles of the United States of … America. If not, the world will see how we are treated not as second-class citizens but as animals that can be disposed of. Enough is enough.”

And:

Earlier in the day, Cruz was strongly critical after acting homeland security secretary Elaine Duke said the relief effort in Puerto Rico was a “good news story”. “Dammit, this is not a good news story,” Yulín Cruz told CNN. “This is a people are dying story. This is a life-or-death story.”

Cruz implored Duke to visit the ravaged island. “This is a story of a devastation that continues to worsen because people are not getting food and water,” she said. “When you’re drinking from a creek, it’s not a good news story. When you don’t have food for a baby, it’s not a good news story … I’m sorry. That really upsets me and frustrates me.”

https://www.theguardian.com/world/2017/sep/29/san-juan-mayor...

What makes "modern dev" more labor intensive than not "modern dev"?

Well it is, objectively, way broader and deeper than before the web explosion. Even aside from the web aspects - barely anyone did heavy database work back then. And if you had a reasonably firm grasp of one OO language - guess what, you were practically a "rock star" (well before the current usage of the term). You knew something about the differences between the Unix shells, and maybe something about inodes and fsck? Great, here's a "devops" (er, sysadmin) job for you.

Nowadays there's just (conservatively stated) at least an order of magnitude of basic "stuff", much of it conceptually independent from the rest, and a lot of it quickly obsolescing (almost as soon as it "matures") - that one has to have a reasonably firm grasp of, just to move the needle from A to B. Or at least not come off as "fossilized or "enterprisey", when talking to "hot" companies, these days (I've actually had the latter said to me, as a description of me, over the phone - after an interview).

So yes, objectively speaking - it's way more intense.

Yes pretty much, but with a more positive spin - i.e. what one really needs is a healthy mix of jadedness and "believing".

Younger people really are faster and have more "energy". On a certain level this is just basic biophysics.

Particularly the kind of "energy" most immediately associated with the modern dev grind (i.e. to work long hours, and pick up toolkit X at the drop of a hat, etc). And you know, to just "believe" (in your company's mission; in whatever your stack is made out of this particular microsecond; in "Agile", or whatever).

None of which I'm knocking. A lot of times I feel I could still use that kind of energy.

But there are other kind of "energy" - e.g. the energy to resist learning too much about toolkit X (very likely to be obsoleted within 3 years). Or to get to wrapped up the latest architecture "debate". Or for that matter, in your company's "mission" (before it's at least halfway baked). Or, when people in your company start bragging about how many hours they "work", how no one really takes vacations and all... the energy to speak the intuitive and well-documented truth about where that strategy inevitably leads.

Both kinds of energy are needed. They aren't opposites; they're parts of a larger (necessary) whole.

The mistake lies in thinking that only one kind of energy is valid and sufficient to get your "mission" off the ground.

So I guess the problem with objective-seeming (and often just simply gratuitously hard) "filter" questions like those suggested here is that their real purpose seems to be give the process an appearance of objectivity - "We had a guy in here, his code samples looked great, and he talked a great game and all -- but would ya believe, he totally froze on that Lego robot puzzle question! What a poser!" -- when of course it's never going to be anything of the sort.

Which inevitably leads to outcomes like:

"Oh I see you're from Kazakhstan, and got top grades at one of the top schools there. And your GitHub account just blew our team away, the minute we saw it. And we can tell, from talking to you for 5 minutes, that you obviously know FP and SQL/NoSQL and database internals and caching and consensus protocols inside and out."

"But wait -- what's that look in your face when we ask you about solving this little Lego problem? Do you not like puzzles? Or wait - you mean you've never heard of Legos, for chrissake? We'll, what can I say. Sorry to break this to you, but we're looking for engineers here, not mere 'coders'. And how do you tell if someone has the soul of an engineer? It's because they dig shit like Legos and robot kits and stuff. They totally geek out and go to town on problems like this, in fact!"

"But then again, that kind of person obviously isn't you. Feel free to apply again in 6 months (after you've passed another 3-hour HackerRank test and our mandatory Skype session on culture fit, of course)."

There's no need to make it any "harder" - the point is that just wasn't well-articulated to begin with. (Noting again that "well-articulated" is very different from fuzzy / ambiguous, in the engineering sense).

And given that the people you want to hire, by definition, are generally very busy (and have many, many important things to do with their time) -- even when they aren't currently working (despite the urban legend that "they always have jobs") -- as such, it just isn't a good use of their time.

No I'm not - I'm very much looking for engineers in the mindset you describe. I just don't think your Lego robot question is a good tool for sniffing out that mindset. (For the simple reason that "muddled interview question" != "fuzzy real-world problem" - in fact there's a world of difference between the two).

But then again, we have a disconnect. Which is of course totally fine.

Yup, that seems to be it.

As if there's some "secret sauce" to interviewing that all the other shops know except their own.

Not only is this a perfectly reasonable question to ask - one is almost tempted to fault someone for not coming back with this as the very first question to ask in response to the question that was initially asked.

Given that 99.99% of the time you're tempted to go that route (as with, similarly: your own ORM, "scripting language", whatever) - you're going to wind up with, at the very least, way more of a challenge than you initially bargained for.

Sounds like they're the ones who messed that one up - not you.

"Every step?" Not at all true, in my experience.

What you need is a reasonable sense for the breadth and depth of the topic -- which quickly reveals itself to be far broader and deeper than what most engineers (including many very capable people I know) can hope to "absolutely understand every step of". And the ability to drill down (and go down rabbit holes) when needed. Combined with the experience of actually having gone down more than a few (and having from relatively unscathed, eventually).

In fact, if anything, your observation isn't just overstated - it actually misses the point of what makes some of the most effective people as effective as they are: their ability to manage complexity, and in particular, their ability to (reasonably) "connect the dots" in a complex system despite not "absolutely" knowing, at every level of detail, how every component in that system works.

Mind you, for the right value of "reasonably". It's when knowing when their level of understanding, while imperfect, is still good enough to solve the problem at hand - and when it isn't - is that makes these people so effective.

You need to have a bit of an idea, sure.

But in order to give any kind of a meaningful answer to the question, you need to have not just a "bit of" an idea, but in act, a deeply solid and intuitive idea. Either that or -- crib the answer from websites like these, know that it's one of the top 30 questions you're likely to be asked.

Which, very sadly, is exactly what the modern interview process (greatly) incentives people to do, these days.

Right off the bat, this is very muddled question to ask.

For one, "sensors"? I think you meant to say "actuators". Because a sensor by itself can't knock anything off a table.

More fundamentally, "Legos", for those of a certain age, were entirely non-mechanical components in their day. So (even though yes, we've also vaguely seen and heard about, and rolled our eyes at, the newer kind), this just sounds like asking them to (seriously) consider the question of how to build a logical circuit out of tinker toys. Yes, it can be done - but on the face of it, that kind of a question comes off as an invitation to join a mental masturbation session. Not the kind of question you'd ask of someone you respect, and whose time you know to be as invaluably precious as you own.

The person who can give sane answers on those would do a lot better than a coder who knows one toolkit well and nothing else.

This is of course a false dichotomy. Especially given that it was -- not sure how else to put this -- a silly question to ask in the first place.

"What happens when I'm asked a question like X? I spout a mutated form of some canned response I cribbed from a list I found on HN a while back. Because I hear that's how you're supposed to 'rock your coding interview', these days."

3. What are the things you should consider if you were writing your own database server?

"Look, you know as well as I that this job has nothing -- as in, nothing whatsoever -- to do with actually building production-grade database servers. Or anything even remotely analogous to it. Debugging that tangled mess of poorly conceived, never-reviewed JSON APIs left behind by the other developer (while you were pestering them about 'disruption' and 'just needing to get this thing to market') is more like it."

"But hey, since you're playing that game, I can play too: here's a bunch of catchphrases like 'non-blocking I/O, sharding, blah blah.' Because I hear that's the killer answer to give to questions like these. And BTW, if you really think that people Michael Widenius or Salvatore Sanfilippo would be interviewing for this job, then your problems are way bigger than I could ever hope to help you with."

Yes, but if so then that's something for the localities (through their democratic process) to decide. Not you or I. And it's certainly not for Uber to decide, on its own, what's "best" for that given locality - and to continue operating despite local regulations it happens not to like.

As it has unfortunately has not only had a habit of doing in the past - but which it has done as a deep and abiding expression of its core values as an organization.

Sorry for the rant.

Nothing to be sorry for; you're just being honest (both intellectually and in your opinions). And HST himself would probably agree that that's all that matters.

That's not what the article is saying. And you know that's not what the article is saying.

Right?

And that they need to interview you, accordingly.

As to the core of what you're saying -- between the lines, the value proposition seems to come down to this: "Yeah, everyone knows by know those whiteboard sessions are mostly bullshit. But hey, if you're willing to swallow your pride and suck it up like everyone else, these companies might throw a little bit of money your way. Coz that's the name of the game, yo -- in case you haven't heard by now."

At some point one gets tired of basing one's life on considerations like that.

Leaving aside the whole issue of whether actually done properly (or even reasonably).

You may no particularly like the author's point of view -- but you looked carefully, you might have noticed it was placed in he "Perspective" section, which as the name implies, is dedicated to expressing what are commonly known as "points of view" -- otherwise known as "biases". Which, forming the very core of our cognitive processes as they do, are very far from flaws -- an in fact, when used properly, not just useful, but absolutely crucial to one's survival in this murky, deeply ambiguous and ambivalent world of ours.

And at least the author gave some supporting observations to back up their (clearly labeled as such) point of view. OTOH the sentence you're offering above provides no insights or justifications; it is, quite literally, a pure expletive.

Journalism should be objective.

Should it, now?

“So much for Objective Journalism. Don't bother to look for it here--not under any byline of mine; or anyone else I can think of. With the possible exception of things like box scores, race results, and stock market tabulations, there is no such thing as Objective Journalism. The phrase itself is a pompous contradiction in terms.”

-- Hunter S Thompson

And there's certainly no need to soft-peddle Harvard's moral and intellectual cowardice, as revealed in this episode.

Unfortunately one does not, in general, get a job simply by being "willing to put up with" a whiteboarding session or two.

No - it's how these permits are allocated -- and who pulls the strings on those making these "decisions" -- that's the crisis.

Good strategy. The "game" has gone on for so long, now -- and become such absurd caricature of itself (apparently without the participants being aware of this fact) -- that it brings to mind the closing line from WarGames:

"Strange game. The only winning move is not to play."

That's just a variant of the video / landing page, basically. Something that looks like a product (and may in fact even offer some partial functionality). But isn't like, you know, a real, actual product. Where "real" of course means sustainable.

Which again might still make sense as a business strategy. But shouldn't be confused with actually "building" something.

But if they think that such activities are somehow a form of actually "building" something, they're horribly, horribly confused.

"Don't Build When You Can Just Bluff" might have been a more accurate title of their posting, in that sense.