Litmus Tests in Tech
Tags: webdev, career, hiring, javascript
Published: 2021-04-09 18:43:37

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_.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p9qmi48tlbt10axk2iyg.jpg)
## 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_.
<br/>

* 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_.
<br/>

* 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_.
<br/>

* If a JS dev uses the `function` keyword, he's one of _them_.
* If he uses arrow syntax, he's one of _us_.
<br/>

* If a JS dev uses `.then()`/`.catch()`, he's one of _them_.
* If he uses `async`/`await`, he's one of _us_.
<br/>

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_**.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uyr3kc4fswzxr7s0y24s.jpg)
## 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.  
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2wawfii32q827dv8tbd0.jpg)
## 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.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xkegalgcm7hzo3lqb40v.jpg)
## 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???