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
functionkeyword, 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???
Top comments (16)
What’s wrong with
this? Seems like the classes support in JS is a lot better now than it used to be andthisis a pretty essential part of that. I like a functional style too but sometimes a class is a good option.I don't disagree with you. Maybe I should've been a little clearer in stating that, for the last 4-5 years, I've been almost exclusively a React dev. And in React, everything seems to be trending away from classes and toward functions. I'm on record as not "believing" in that trend - but I'm also on record as wanting to keep getting paychecks. So, for some time now, I haven't written a single class. Anywhere.
To be clear, the
thiskeyword still "exists" in functions. But if you're writing purely in functions, I think it's a rather dodgy practice (obviously, just my opinion there) to keep usingthis.Yeah that makes sense.
thisin a functional style would be weird.I'm not sure if I'm one of them or one of us. I'm a fan of using classes in JavaScript, I use tabs, and I prefer object dot notation, however I abhor the
functionkeyword and I loveasync/await.If you're not hung up on tech "shibboleths", then it doesn't matter where you fall in that combination of traits.
Heh, true I guess.
I'm definitely guilty of judging people on how they write their code though. I do try to avoid it but sometimes it cannot be helped. Seeing
vareverywhere will change a person.I agree, but
varhas quantifiable reasons why it's potentially harmful. (Of course,varisn't necessarily harmful - it's just potentially harmful, depending upon how you use it.) So I understand the aversion to seeing any new code written withvar.Contrast that with those who shudder every time they see
classin JS code. I have yet to hear a single quantifiable reason why this is "bad". All of their arguments fall back on fuzzy bromides and vague notions of "best practices". Yet they'll still use the appearance of thatclasskeyword as a shibboleth to eliminate you from consideration.Thanks for the great article! I totally agree with you and can admit of being guilty of sometimes carrying out "litmus tests" myself. It is total nonsense to discard a candidate if they don't know a specific thing or two in a given language.
Could such tests bring more value when there are sufficiently many of them? If the applicant doesn't know async-await, cannot explain "this" in JS, cannot code a binary search tree, and doesn't know what a pure function component is, isn't it then reasonable to be able to make the assumption that this candidate may not be the ideal candidate for our company? We cannot rank the candidates by how many they got "right", but we can say whether they passed or failed. Does this make any sense?
Yes, I totally agree. It's incredibly valuable to ask a candidate a range of questions on a range of topics - or to ask them to attempt a range of different whiteboard-style challenges. But as you point out, the key is to not treat any one of those questions/challenges as a "knockout" issue. Instead, look at the aggregate value of all the answers combined.
Also, I think it's important to differentiate between "the candidate can't code this from scratch off the top of his head" versus "the candidate has no idea what this concept is, when to use it, or where to find information about it."
In the example I gave regarding binary trees, I know dang well that I can't sit down, right now, and code it up from my head. But I know what a binary tree is. I know when you generally consider using one and what benefits (and downsides) it provides. And I know that, if I had to go code one up tomorrow, I could absolutely be "up to speed" on it in a very short period of time. That's far different than dealing with a candidate who's never even heard of a binary tree and has no clue what purpose it would serve.
Such a great job of framing the issue. I love apply, I wish people knew it so I could use it. But is
add.apply(null, [10, 20])more readable or understandable thanconst [x, y] = [10, 20]; add(x, y)or some other variant? Maybe, maybe not. It depend on who you're working with! And if I'm being honest, it probably isn't more readable in any situation. And only once in a blue moon do I use it.Then the functional vs OO, and promise chain vs async await is so great. I caught myself thinking, "but async await is more imperative. Even if it is the new shiny!" And there lies the problem.
This is a great article. I'm going to keep it in my back pocket the next time we do an interview.
Aside: putting together a good interview seems to be an art in itself, I'd love to hear some new ideas in that space
An excellent article that totally describes my feelings of becoming failure in many interviews.
They ask question that seems very simple to them, but when you give them a answer that they do not know becomes a very new and unique thing, I will continue with a very simple example.
let's say you are at an interview and someone asks you "What is Node.JS?" and You answer, "It is a Run Time Environment for JavaScript." if you stick to this question, they will assume you a good candidate but if you say, "It is a Run Time Environment for JavaScript, that uses operating system's I/O operations along side with POSIX." they will consider you an alien and it is quite possible that they will not think you as developer as well.
One more thing, the devs that are taking the interview often forgets that there are multiple ways of solving the same problem, and programming is a very vast field and there are many to infinite things that a person still requires to learn as well. So, becoming a good developer is a long and exciting journey.
There should be a good and effective manner of judging the candidates, rather than these boring hard-coded interview questions, because they represent the fragment of the memory not the knowledge about the programming or a mind filled with passion to solve the problems.
Very well said!
I think the problem is that it is impossible to gage overall skill based off any arbitrary number of fixed questions. I usually ask open ended questions so that candidates can show me what they are most skilled in.
“Tell me about an interesting problem you solved.”
“What is something exciting you learned lately”
If I have to do whiteboarding I would go with some kind of general knowledge use case. For example, measurements.
As an occasional technical interviewer I find it difficult to separate the knowledge I value from what matters.
Most candidates I’ve interviewed in webdev have little experience and zero theoretical knowledge about the tools they use, which is fine for junior entry level. What I find more problematic is for instance when an intermediate React developer has never heard about the event loop, or has never read the official React documentation.
Sometimes, even though I don’t value the answer, I ask basic shibboleth questions, like code syntax, on purpose to check if the candidate took the time to read things like “how to prepare for a React job interview” to check his level of commitment in his job search.
The insight about the one thing vs. Tesla's self driving system is pure gold.
Hahaha - thank you!