Since I began blogging on Dev.to, one of my primary subjects has been the (arbitrary) standards that we apply to others when we evaluate them as potential candidates for jobs. In fact, it was the focus of my first blog on this platform, and I've addressed it on several different levels since. But this really became much clearer (in my mind, at least) after I posted my last article - an article about applying to Facebook.

In that article, I explained that I'd been told to expect questions about .call() and .apply(). And because I don't feel any need to "bolster" my image in this forum, I also mentioned that I had to immediately Google those concepts - because I wasn't familiar with them.

To be absolutely clear, I've been coding, quite literally, since I was a kid. I've been coding professionally for almost a quarter-century. I've been doing JavaScript development quite heavily for about... a decade or so. And I've been doing React development, specifically, for the last five+ years.

Despite this mountain of real-world experience, I wasn't terribly familiar with the ideas of .call() or .apply(). After I looked them up, I realized exactly why I'm not familiar with them - because I don't use them at all in my regular work. And given "modern" JS norms, I'm not even sure how or why I would use them going forward.

As a React dev, I'm intimately familiar with .bind(). I'm familiar with it because there was a time when I used it frequently. That time has passed. In my current dev (and by "current", I mean, the last 2-3 years), I haven't used it at all. Quite frankly, for me, .bind() is basically... deprecated. And when I looked up .call() and .apply(), I similarly felt that these concepts are deprecated.

You see, I don't even use this anymore. And I'm not saying that there aren't some potentially-valid use-cases out there for this. But for the most part, if you're repeatedly falling back on this, I gotta wonder how "modern" your JS dev really is? And if you're not using this, then the use-cases for .bind(), .call(), and .apply() become incredibly... scant.

But this article is NOT about .bind() or .call() or .apply(). I truly couldn't care less whether you agree with my take on them. In fact, this article isn't about any particular language construct at all. This article is about the arrogance of "tech folks" (like myself), and litmus tests, and shibboleths.

Shibboleths

To truly understand someone's abilities is... hard. And most of us can't really put in the time to do a "deep dive" on someone else's credentials. So we take shortcuts.

I'm not pointing fingers here. I do this. We all do this. We create an informal list of slang that we can use to determine whether someone is "one of us" or "one of them".

In other words, we create (consciously or subconsciously) shibboleths. We create shortcuts to separate the real devs - from the pretenders.

What do shibboleths look/sound like in the current JavaScript environment? Here are some common examples:

• If a JS dev says "class" or "constructor" or "OOP" without the appropriate level of derision, he's one of them.

• If a JS dev says "declarative" or "pure" or "immutable" or "functional programming", he's one of us.
  
  

• If a frontend dev (of nearly any language) uses tabs, he's one of them.

• If he uses spaces (and only two-space indents!), he's one of us.
  
  

• If a JS dev refers to object properties via dot-notation, he's one of them.

• If a JS dev relentlessly destructures all of his object properties into standalone variables, he one of us.
  
  

• If a JS dev uses the function keyword, he's one of them.

• If he uses arrow syntax, he's one of us.
  
  

• If a JS dev uses .then()/.catch(), he's one of them.

• If he uses async/await, he's one of us.
  
  

I could go on and on here, but I think you get the point. Because we don't have the time to do a "deep dive" on everyone's skillset, we resort to using these shorthand call signs to swiftly label a dev as one of us, or one of them.

The (massive) problem with this approach is that it's lazy. And it frequently leads to wildly-inaccurate assessments.

If I can perfectly pronounce shibbólet, does that mean I'm Jewish? Possibly. But it could also mean that I was raised in an environment with heavy Jewish influences. Or it could mean that I study languages and I'm fluent in Hebrew. Or it could even mean that I knew you'd use this silly test as a sorting mechanism, so I studied, beforehand, exactly how to pronounce shibbólet.

Similarly, the shibboleths we employ when evaluating fellow coders are prone to serious miscalculations. More importantly, they're also rife with our own personal biases.

I've met some coders who absolutely adore async/await. And that's fine. But sometimes they are so enamored with it that they'll look down their nose at anyone who uses .then()/.catch(). Or they scoff at anyone who uses the function keyword. Or they snigger when they see a class in your code. In other words, they're treating these concepts as shibboleths to sort out the poor coders. But what they're really sorting out is: people who don't code like them.

Litmus Snobbery

A litmus test is similar to a shibboleth - but not entirely. Shibboleths are more about communication - concepts that we want to hear from other coders, and concepts that we do not want to hear.

But litmus tests are more about tactics that you've either mastered - or you haven't. Here's how a litmus test typically works in coding environments:

A candidate comes in for an interview and the team positions the nervous, sweaty soul at the whiteboard. Then they ask him to code an example of doing a search with a binary tree. The candidate has some extensive experience, and a solid grasp of many coding concepts. But he's never studied or implemented a binary tree. So he fails to provide any satisfactory solution to the problem.

At this point, the interview is functionally over. They might afford him the courtesy of continuing the interview for another 45 minutes or so. But the devs in that room who are evaluating the candidate have already decided that this guy's an imposter. And they know he's an imposter because he can't do a binary tree!

I mean... the nerve of this guy! Whatever made him believe that he was worthy of writing code if he hasn't already mastered the concept of binary trees?! Not only should he be eliminated from consideration for the job, but he should also have his hands chopped off, so he's never tempted to sit down at a keyboard again! Ammiright???

Of course, the reality is quite different. In a quarter century of professional coding, a binary tree has been the "right tool for the job", for me, exactly... ONCE. I know what a binary tree is, and I generally know where they should be used. But if I had to set up a binary tree search today, I'd first start by hitting up Google for a few minutes, because I haven't actually written anything related to a binary tree in about 15 years.

But this article isn't about binary trees. It's about the fact that we latch onto some programming technique that we're familiar with, and then we use that technique as a litmus test to eliminate potential candidates.

Thinly-Veiled Arrogance

Litmus tests reek of arrogance. They function from the perspective that you know how to do this thing, so anyone else who claims to be a "real" coder should also know how to do this thing. And if they can't do that thing? Then no amount of experience will allow you to overlook the fact that this person - who claims to know how to code - couldn't do this "thing" that you yourself can do just fine. So clearly... they must royally suck at life!

This is where the Arrogants get all in a lather. They start hyperventilating and flailing their arms, and they say:

But, but, but... if this guy can't do a binary tree, he's obviously not a dev with broad and deep knowledge!!

Take it from me. When a litmus tester reaches this point, there's really no benefit in talking to them about it any longer. Because at this point, there is no amount of knowledge or skill or experience that will, in their mind, erase the fact that this guy didn't know how to do this one thing. You can tell them, "But... he wrote Tesla's entire self-driving application. By himself. In assembly code. Over a long weekend." And their only response will be, "But he didn't know how to write that binary tree search, so he obviously can't be too dedicated to his craft!"

You see, once someone gets it in their head that you should know some particular bit of programming knowledge, it won't matter to them whether you can prove that you know ALL THE (other) THINGS!!! They will always come back to the fact that you didn't know this thing - and therefore, you suck.

Defenders of this mindset will tell you that there's nothing wrong with expecting a candidate to have certain skills - like programming a binary tree search. And if they can't do that, then how is it arrogant to eliminate candidates on that basis??? But the answer to that is incredibly simple:

For those who rely on litmus tests, their basis for what is-or-is-not "standard" is: Do they know how to do it themselves??? If they know how to do it, then they automatically assume that any "real" dev should also know how to do it.

Let me say that again, in a slightly different way. Because I want this to really sink in for you.

When we apply litmus tests to other coders, we generally assume that whatever we are comfortable with is "common knowledge" - and any "real" coder should be able to do the same. And we assume that whatever we aren't comfortable with is... esoteric. Rare. Arcane.

The Arrogants who are judging you based upon your binary tree skills are doing so either because A) their environment just so happens to use a lot of binary tree searches (thus, to them, it's become a commonplace coding task), or B) it's been established in their dev shop that this is a Sacred Coding Test and all of their current devs either knew how to do binary tree searches before they came onboard, or they quickly learned after it became a "standard" in their environment.

Karma is a...

In case you can't hear them yourself, those Arrogants are still squawking in the background. They're fidgeting and arguing that:

I don't care what you say, if someone isn't intimately familiar with binary tree searches, they're not a real programmer!!!

To which I will only respond with this:

I wasn't familiar with .call() and .apply() until a few weeks ago. I guess that means I'm not a "real" coder. I'd need to do a little googling before I'd be ready to sit down and write out a binary tree search algorithm from scratch. I guess that also means that I'm not a "real" coder.

But I've been doing this now for a quarter-century. Do you really believe that, if I'm the one conducting the interview, I couldn't possibly come up with a litmus test that you would FAIL??? Are you so certain in the incredibly-broad and impressively-deep scope of your knowledge, that you're sure I couldn't possibly stump you???

And if I could stump you on any particular "litmus test", how will you feel when you get summarily dismissed from consideration just because you hadn't mastered the one technique that I happened to ask you to illustrate on the whiteboard???