This is what I mean by most people don't think this way. Your activities have no bearing on whether it is, in fact, raining. What you are wanting is to measure whether it's raining enough to affect my plans. That's a question unrelated to whether precipitation is happening.

Nobody cares if it's "raining" or "not raining." That variable has absolutely zero use - it would be like having a binary variable for "Is it 5:17 PM." (Which would break the day after you shipped it and someone asked "Which time zone?")

Virga is rain that falls, but evaporates before it hits the ground. Is that "true" or "false" for the "Rain" variable?

And you're sitting here arguing and arguing and arguing that it's possible for it to be binary, which nobody needs or wants, when you can make it an integer and just use "0" and "1" (Until the day after you ship and a user says they need more states for the "Rain" variable).

Male/Female - or XXY or XYY or TG or...

Pregnant - or "May be pregnant, waiting test results" or "Pregnant but planning to give up for adoption" or "Surrogate mother" or "Disclosed but protected under privacy concerns"

Is a light on or off? Or is it burned out? Or is the bulb missing?

If you give me a real-world "variable" that you assert can only be binary, I'll wager I can come up with a real-world use case that breaks your model. The point is that the model has to reflect the world - you don't define the world to make the model easier. And when I say "the world" I don't mean "every single possibility" - I am talking within the parameters of the current application and use cases. But my point is that for virtually any variable that represents a real-world state, if you insist that it's binary and use a bit to represent it, the users will come up with a third option at the most inconvenient time. And if you've coded for a bit through all the layers, now you have to rework a huge amount of code.

If you start from the presumption that there are no real binaries, and always use an integer as your smallest variable, then only code for the binary check box at the UI, when the users come up with "Oh, and we need..." then you just have to change the UI.

Yes - there are processing tasks where bitmasks and boolean logic are standard for processing or storage purposes. But they're more carefully controlled, special case, insulated from "the real world" type affairs, and generally the engineers working in that space are aware that they are living in a world of abstraction and approximation out of necessity.

If it's drizzling, raining = 1. If the rain is tapering off, raining = 1.

Not if you're planting seed, or laying cement, or taking the kids to the park.

Dawn or dusk is day.

Not if you're talking about a car accident, or filming a movie, when lighting conditions are critical.

In the entire history of the English language, we have ended up with a lot of words for "rain." We have "dawn" and "dusk". There are very real semantic differences between "snow," "flurries," "wintry mix," and "blizzard." And I don't believe you will find any representation of weather anywhere that simply says "Raining" or "Not raining" - at the very least you'll have icons for "light rain" and "rain" and "thunderstorms."

When I suggested that "rain" is not binary, you didn't ask me a single question about the use case or purpose - you just insisted you could shove it into a binary field and make it work.

Which is the absolute epitome of where shitty applications come from.

Similarly I have face blindness. If you don't know cars, you know how it seems like magic when someone says "That's a 1988 Firebird V8 with the Formula trim package"? That's what it's like for me when normal people recognize someone they haven't seen in a while, even with different hair and clothes.

I finally realized what it's like for regular people when we were watching an animated movie and I recognized some actor's voice - just instantly knew who it was. I asked my wife "Is that what faces are like for you? Holy shit" (There's a great movie based on this idea called Faces In The Crowd about a woman who loses her ability to recognize people. What's totally cool about it is after she's "face blind" they use multiple actors for some of the main characters to keep the audience as off-balance as she is)

These kinds of things fascinate me, especially how we grow up completely unaware how differently people can see the world.

For anyone interested in digging into this idea more, I'd recommend looking into cognitive spatial awareness, which I think has seen a lot more research, and appears to be more clear-cut on "can they or can't they?"

When applying for flight training in the military, there's an exam called the AQT/FAR that tests for aptitude. A big part of the test is being able to look at a picture of an airplane as seen from a cockpit and answer questions about the relative positions of the two aircraft. Some people ace it easily (9 out of 9), but I had a few classmates that wanted nothing more than to be pilots - they studied their asses off and never got higher than a 3 out of 9. They simply could not process the 2d picture to a 3d picture in their head.

Hm. I'm an excellent programmer, and I bitch slap people who act like software should only deal in binaries. To this day I refuse to use bit fields in database schema, because I've been bitten far too many times by last minute "Did we say there are only two options? Sorry - there are five"

Fuck - even the silicon isn't really binary. We've just forced it to work like a binary switch through artificial gating.

The real world has no binaries - It's raining or it's not... or it's drizzling... or the rain is tapering off. It's not day or night - it could be dawn or dusk.

Programmers who think there are only binaries need to be kept on the back end and carefully guarded to make sure they never try to create requirements or anything that will interact with users. [evil grin]

It's like saying you should design cars so people who can't figure out how to drive can use them.

Then why is Google spending so much money on doing exactly this?

Whatever. Just get on the short bus, drooly.

More to the point, let's say there's some test question that "worked at Google" can't do - it should seriously make you question your approach, not Google.

"We're behind schedule because we're taking the time to validate our work with the users and we've caught some mistakes. So let's work longer hours to keep with the artificial deadline!"

I think inviting Johns to your house would be kind of like using your own car to patrol as a cop...

And I am stating that it's not an "employer" thing, it's a "person" thing, and unless you can tell me that Google has specific training for hiring interviews and has managers periodically audit the interviews of their employees, then yes, it even happens there. Because if you have a thousand people doing hiring interviews, you're gonna have a significant percentage that think it's supposed to be an exam instead of a conversation.

As for the code - my apologies. I didn't even glance at it. "Pseudocode" was not meant to be dismissive - only a lowest-common-denominator of "enough codelike substance to show your thinking in designing the algorithm." Looking at it now, it's fascinating in that it's theoretically correct, but we both know that in reality you'd have to optimize / rework it because it would freaking explode in memory. (Nature of the beast, not the solution)

The prerequisite for this problem by contrast is being capable of thinking in a logical and algorithmic fashion and having a grasp on the most fundamental computer science datatypes.

Except that...

I actually had to look it up to make sure it was what I assumed it was

So you didn't know what it was for sure. Also, the amount of programming experience necessary to even guess what "invert a binary tree" means is probably far beyond what I am saying when I say "anybody who has done significant RDBMS work"

And here's the thing - I'm going to guess you've never done any data modeling, so my "many-many join" question looks completely alien to you. Does that mean I shouldn't hire you for any job that touches a database? Or should I ask you questions to see if you have the aptitude to grok data design and database interaction and that I can teach you what you need? Note that to do this kind of poking, I'm going to have to get out of RDBMS terminology and try to discover where you are with concepts you know (key-pair sets, hash tables, linked lists, arrays, etc).

And I'll say it again - you went with pseudocode to solve a problem you'd never addressed before. I'm asserting that I know for a fact there are interviewers who would expect you to be completely familiar with the concept and write down the standard book solution, otherwise you get a "No Hire." Someone who asks you the question and works with you through your lack of familiarity is fine; the issue are the people who think their perspective of the world is the only world and if you can't answer something they learned when they were 17, then obviously you are an idiot.

To go meta - don't think in terms of how you would treat a candidate in this situation. We're talking about pedantic asshats who don't understand how to interview.

How do you implement a many-many join?

Anyone who's done significant RDBMS work knows the thumbnail answer is "three tables." But what if all your work is C, NoSQL, and Hadoop? You could have a mountain of knowledge and skills to offer and not even know how to start answering the question.

I could look at someone who doesn't know how to answer that most basic of RDBMS questions as an idiot. Or I could simply realize that it's entirely possible to spend an entire career in IT solving big hard problems without ever touching an RDBMS. I don't agree with that philosophy, but "programming" didn't check with me.

What about "When would you use a doubly-linked list?" or "What is the fastest sort algorithm?" or "Explain a pointer to me."

There is no one "if you don't know this, you don't know programming" question. Okay, maybe there's one:

"Is there one single 'you don't know programming' question?"

If you answer "yes" to that, I'll throw you back into the ocean to get more experience.

They're not asking you to recite A*, they're asking you to share how you'd go about solving it.

That's the textbook answer. But you just have to read some of the replies on that article to see that a lot of interviewers don't know this - they expect you to know these kinds of algorithms off the top of your head.

I knew one old-school interviewer that asked every candidate the layers in the OSI model. He told me in all the time he'd been asking, only one person knew the answer. My response to that was "Doesn't that say more about you than the candidates?"

...except that after the first wave of really smart programmers show up, following waves will be even less able to answer the questions.

But it's silly to nitpick over H-1B. Everyone knows they're being abused, and if ICE and the IRS actually audited the companies using them, there would be fraud indictments flying all over the place. If I were king, any company that had more than a dozen H-1B employees would get audited with a proctoscope. (The law would also be amended so that no company could have more than a dozen H-1B employees, and the salary floor for H-1Bs would be $100k)