DEV Community

Applying To Facebook

Adam Nathaniel Davis on March 25, 2021

So I just had an idea for what might be an interesting/helpful blog series for all of my faithful readers (both of them). Just today, I decided th...

Read full post

Offirmo • Mar 25 '21

Good post!

May I suggest: you say you vaguely know .call or .apply or IIFE because they don't have use in real life.

May I suggest that it could be the opposite? Because you don't know them, they are not part of your toolbox and thus you're not using them.

In a former job, I was not using .reduce or .map and co. because I found them "too complicated to read". My coworkers forced me to rewrite my clumsy loops into proper readable .reduce or .map and improve my game. I ended up using them all the time.

Another time, 2 coworkers "forced" me to learn how to rebase git branches. I couldn't see the point. Well, now I'm using it ALL the time.

While I'm not using .call or .apply or IIFEs often, I still use them at least once every few monthes.

Let's be open!

Adam Nathaniel Davis • Mar 25 '21 • Edited

I actually agree with you. And at the risk of sounding a wee bit nitpicky here, I'll point out that I said, "I can't honestly think of a single REAL-LIFE instance where I would, you know... USE them." Notice, I didn't say, "There is no use for these tools whatsoever." It's a subtle difference - but an important one.

The key here (in my mind) is that you can ask someone in their next JS interview about .call() or .apply() or IIFEs, but it shouldn't be much of a distinguishing factor about whether you want to hire that person - unless you're actually screening for a job that has an unusual focus on those tools.

I totally understand that sometimes, the tools we dismiss as having no use, are simply the tools with which we're not comfortable. And am I guilty of that at times? Of course I am. We all are.

But imagine that you never got to meet those 2 coworkers who "forced" you to learn about rebasing - because the interviewer asked you to demonstrate rebasing during your interview. And then, when you couldn't, they eliminated you from consideration. Not knowing about rebasing didn't mean that you were a poor developer and it didn't mean that you should've been eliminated from consideration for that job.

One of my big pet peeves about the tech hiring process - at nearly any company - is that the interviewers pick a handful of esoteric concepts and decide to use them as a litmus test for the candidates' abilities. And that's fine. They have that right. But it will end up eliminating some of their best candidates (which, coincidentally, was the central point of the first article that I ever wrote on this site).

Lou (🚀 Open Up The Cloud ☁️) • Mar 25 '21 • Edited

"interviewers pick a handful of esoteric concepts and decide to use them as a litmus test for the candidates' abilities. And that's fine"

This is sadly, very true. Developers learn a concept, feel superior, then use that as their test for others, but if turned around the other way I'm sure the developer on the other side of the table knows some equally puzzling or tricky and esoteric questions. A very irritating aspect of tech hiring for sure.

Adam Nathaniel Davis • Mar 25 '21

Well said.

Anthony Gushu • Mar 29 '21 • Edited

This is exactly why we focus our dev interview around a creative coding challenge that forces the candidate to learn a new concept and apply it with a ton of wiggle room around how they want to approach the task. We just give some general goals to accomplish in the project, then we discuss how they solved the problem without nitpicking the tools outside what we asked them to demonstrate.

We also give them an appropriate window of time on their own to research the new concepts so that it's not an on-the-spot stressful thing.

Adam Nathaniel Davis • Mar 29 '21

BINGO!

Pretty soon, I'm going to do an article on how I want to do interviews - and it's basically what you're describing here.

Ivan Pozderac • Mar 26 '21

I think everybody should set aside hour or two here and there to check out new bells and whistles they didn't try before. When I find something that I didn't use before I set some time to read about the feature and then try it to see if it can be useful for something I usually do. It is always good to know that something exists so when you face some weird problem, you know you have one more tool in your toolbox to consider.

Sometimes it provides value, sometimes it is about just playing around with the things you didn't play before.

Curiosity is a great thing to have!

and yeah, git rebase.... I postponed that for way too long! Will play with it today!

Mike Talbot ⭐ • Mar 25 '21

I'd love to hear how you are improving your reduce and map. I do use them, not sure I feel I really like how I use them...

Adam Nathaniel Davis • Mar 25 '21

Same here. I now use Array.prototype functions frequently. But too often, I first start out with .forEach() and then, once I've written the dang thing, I look back at it and think, "Oh... wait. This should really be done with map/filter/reduce/whatever." Then I spend a few minutes refactoring it.

Lou (🚀 Open Up The Cloud ☁️) • Mar 25 '21

Very rarely, if ever does something need to be a .forEach as opposed to a reduce/map etc. That said, as much as I do love functional (and functional-esque) programming, other languages do advocate for just using humble for-loop, and I see their point, it's not evil.

Adam Nathaniel Davis • Mar 25 '21

Oh, I totally agree! The thing is that my old-skool brain just kinda "fits" naturally into loops. So when I'm first thinking through the solution, I often reach for the forEach as the first thing out of the toolbox.

You're absolutely correct that a for loop is not "evil". But I've also learned that, as you pointed out, something rarely needs to be a forEach. And when I fall into a lazy habit of submitting code that's littered with forEach loops, the other devs on my team tend to notice (rightfully so).

So rather than beat myself up over it, I just write the logic the way it first "appears" in my brain. Then I give it a once-over, and I might refactor some of those forEach loops if they don't feel optimal. (And as you said, they rarely are.)

I used to be this way about ternary operators. I would write everything with traditional if/else, then I would look at it and think, "This should be a ternary" - so I'd change it. It took quite a while, but now I pretty much "think" in ternaries. I'm not quite there yet with all of the Array.prototype functions - but I'm definitely a lot closer than I was several years ago.

peerreynders • Mar 25 '21

I understand them conceptually, but I can't honestly think of a single REAL-LIFE instance where I would, you know... USE them.

One possible motive is to filter out people with "tech tunnel-vision".

Most recently I had to use Function.prototype.call() to satisfy ESLint: no-prototype-builtins:

  // top of module ...
  const hasOwnProperty = Object.prototype.hasOwnProperty;

    // ... later in the code to satisfy
    // https://eslint.org/docs/rules/no-prototype-builtins
    if(hasOwnProperty.call(obj, name)){
      // ...
    }

and Rollup can generate an IIFE bundle.

I've come across anecdotes of Rails developers who didn't "know" Ruby and I also remember around 2013 lots of job postings on SO stating a requirement of "JavaScript (not jQuery)" - whether that means that we'll have "Web Development (not React)" in our future I don't know.

The point is that on the one hand they want an absolute wiz in their current tech stack but on the other hand like to keep their options open to turn on a dime to redeploy their "resources" to entirely different tech.

They are strongly favouring Comb-shaped employees.

Adam Nathaniel Davis • Mar 25 '21

Oh... wow. ESLint no_prototype_builtins??? I wasn't even aware of that (horrible, stupid, no-good) ESLint setting (cuz we've never used it where I've worked). On one hand, I can understand that "circumventing our linter" is, on some level, a "real-life" use-case, it's definitely not the kinda real-life use case that I'm thinking about. That's not to say that I can't appreciate your ingenuity there - but, mannnnn... what a HORRIBLE use of ESLint.

As for employers wanting comb-shaped employees? Yeah. I get that. But the "comb-shaped" employee is only a stone's throw away from a "purple squirrel" (dev.to/bytebodger/lie-to-advance-y...)

peerreynders • Mar 26 '21

(horrible, stupid, no-good) ESLint setting

Justification:

Object.create(null) is a common pattern used to create objects that will be used as a Map.

i.e. it made it possible to create objects without a prototype that carried the standard object methods.

I get that. But the "comb-shaped" employee is only a stone's throw away from a "purple squirrel"

The "purple" squirrel" metaphor breaks down because real people are being hired, not "purple squirrels".

For example, if you've watched Data Fetching with React Server Components you should be familiar with Lauren Tan. I remember her from the 2016/17 talks about Elixir/Phoenix. Her resume is available on Linkedin and describes a 10 year journey. Not a "purple squirrel", not "hyphen-shaped", not "I-shaped".

So what I think is really going on is that FAANG companies are mining for gold:

It's easy enough to find the gold nuggets just lying on the surface but they are rare.
Fools gold carries an opportunity cost that is high enough to make it acceptable to miss a gold nugget here and there.
Meanwhile to find the gold beneath the surface they'll adopt any selective strategy that seems to keep the fool's gold out.

Meanwhile non-FAANG companies are simply copying the mining (selection) practices of the FAANG companies assuming that there is enough gold to go around.

cuz we've never used it where I've worked

Now I can't say for sure but I suspect sentiments like that are a red flag for a recruiter. Because it doesn't convey a sense of curiosity/inquisitiveness in one's chosen occupational field that leads to a constant expansion of one's comfort zone and pursuit of knowledge that leads to iterative improvement of one's work.

For example apply() appears about 30 pages into "JavaScript: The Good Parts". Granted a 2008 book may not seem relevant in 2021 but the longer one claims to have been working in JavaScript the more likely it should be that one has run into some of the more esoteric parts.

My latest favourite:

Array.from({length: 5}, (_v, i) => i);
// [0, 1, 2, 3, 4]

Adam Nathaniel Davis • Mar 26 '21 • Edited

i.e. it made it possible to create objects without a prototype that carried the standard object methods.

I don't much care what the justification is. When you have to write hacks just to get around your linter, the problem is in your linter.

The "purple" squirrel" metaphor breaks down because real people are being hired, not "purple squirrels".

No. The metaphor doesn't break down, because I didn't say that there are no comb-shaped employees. I said that they're a stone's throw from purple squirrels. Obviously there are people out there with wide and deep experience. But the wider and deeper that you expect your candidates' experience to be, the closer you get to angling for a purple squirrel.

Adam Nathaniel Davis • Mar 26 '21 • Edited

Now I can't say for sure but I suspect sentiments like that are a red flag for a recruiter. Because it doesn't convey a sense of curiosity/inquisitiveness in one's chosen occupational field that leads to a constant expansion of one's comfort zone and pursuit of knowledge that leads to iterative improvement of one's work.

If it's a red flag - for anyone - that I haven't happened to work in a shop that's chosen to use that particular ESLint configuration - then it definitely is a red flag. For me. Because I don't want to work for anyone who thinks that it's somehow a knock against me that my previous dev shops haven't chosen to use this configuration.

And as for curiosity, the last thing I care about is going through and learning about every possible ESLint configuration. I can learn more about... coding. Or I can memorize all of the ESLint options. I know which one I'm choosing.

And no, I don't much care about ensuring that I've covered all of the concepts in a JS book that came out 13 years ago. The "good parts" that existed 7 years before ES2015, are not the same as the "good parts" now. The language has evolved - greatly.

peerreynders • Mar 26 '21

If it's a red flag - for anyone - that I haven't happened to work in a shop that's chosen to use that particular ESLint configuration - then it definitely is a red flag.

The comment was about call() and apply() - not no-prototype-builtins which in itself only served as a present day example for call().

The language has evolved - greatly.

Fair enough - see this treatment then:

Decorators and forwarding, call/apply

Hopefully that is more relevant in the present.

Adam Nathaniel Davis • Mar 26 '21

The comment was about call() and apply() - not no-prototype-builtins which in itself only served as a present day example for call().

Look. I assume that we're having a cool/professional conversation here. So I'm not trying to get all pissy. But if you read the chain of messages in our thread, it goes like this:

I said, "I wasn't even aware of that (horrible, stupid, no-good) ESLint setting (cuz we've never used it where I've worked)." In other words, I was explicitly referring to ESLint when I said that we've never used it where I worked.
You then quoted, "cuz we've never used it where I've worked" and cited it as a reason why this might be a "red flag" for a recruiter, positing that it potentially displays a lack of curiosity/inquisitiveness in one's chosen occupational field. In other words, you quoted my comment about not having used a particular ESLint configuration, and used that as a basis to suggest a lack of curiosity on my part.
I then made it clear that, if my unfamiliarity with a given ESLint configuration disqualifies me for consideration from a given job - then I don't want to work there anyway.
And now you reply saying that your comment was about call() and apply() - not no-prototype-builtins. But that statement is completely inconsistent with the thread. You quoted my comment about a particular ESLint configuration and proposed that it may be a "red flag" because I'm not sufficiently curious/inquisitive.

I'm assuming that, when you quoted me saying, "cuz we've never used it where I've worked", you were getting confused about the context in which I said that. So you then replied as though I said, "I don't know/care about .call()/.apply() cuz we've never used it where I've worked." But that's absolutely not what I wrote - in any way, shape, or form.

peerreynders • Mar 26 '21

Look. I assume that we're having a cool/professional conversation here.

Yeah, sure.

You then quoted, "cuz we've never used it where I've worked"

I quoted it as the last occurrence of a repeating pattern - in the body of the original article your stated:

but I can't honestly think of a single REAL-LIFE instance where I would, you know... USE them.

which expresses the same sentiment as the section I quoted. That said the reaction

I wasn't even aware of that (horrible, stupid, no-good) ESLint setting

is interesting in itself. Rather than simply judging the rule off the cuff there is an opportunity to investigate why it exists, discover that Object.create(null) can create objects without a prototype - at which point

it is possible to disable the rule OR
simply proceed to borrow methods.

if my unfamiliarity with a given ESLint configuration disqualifies me for consideration from a given job

Perhaps it's better to view the recruitment process less as an assessment of qualifications but more as an assessment of potential and risk. One could take the perspective that these type of questions are more suited to gauge the potential of working as a library developer or as a technical lead to more junior developers. Once the candidate turns employee, the employer may choose to "squander" that potential by having them work in an application developer role (at least temporarily).

So you then replied as though I said, "I don't know/care about .call()/.apply() cuz we've never used it where I've worked."

Again, I was responding to the general response of "I haven't used that before". In some contexts it's perfectly valid. People working with Oracle don't necessarily get curious about Postgres. But when it comes to programming language knowledge, claiming multi-year experience and not having ventured into the dustier corners may raise some eyebrows.

Adam Nathaniel Davis • Mar 26 '21

But when it comes to programming language knowledge, claiming multi-year experience and not having ventured into the dustier corners may raise some eyebrows.

As soon as you start playing that game, there is always some dusty corner that you haven't ventured into. I don't care how long you've been doing a given language or using a given tool/framework/whatever. So the idea that your unfamiliarity with a given feature somehow calls into question your claim of "multi-year" experience - is facetious.

I've been doing React very heavily now for about 5 years. In fact, it's pretty much all I program in. Am I the end-all, be-all expert in all things React?? Of course not. But that doesn't negate my experience. Dan Abramov can probably name 10 things about React of which I'm either unaware or only vaguely familiar. That doesn't mean I don't know how to do React. And it doesn't mean that my "claims" of 5 years of React experience are a lie.

peerreynders • Mar 26 '21

there is always some dusty corner that you haven't ventured into.

Sure, but call() and apply() aren't as esoteric as you make them out to be.

Also my discussion isn't about assessing your personal qualifications - that's simply not my place.

But I'm trying to paint the view of someone who would rather pass over the "right" candidate than hire the "wrong" one.

I've been doing React very heavily now for about 5 years. In fact, it's pretty much all I program in.

Have they been explicit about looking for a React developer?
JavaScript allows for some pivoting between technologies and there are lots of support technologies within the ecosystem that benefit from skills beyond React core.

Interestingly the things that Dan Abramov admits to knowing don't seem to be React centric.

Kenneth Lum • Mar 26 '21

call and apply are when we have a function, and be able to invoke this function (method) on an object as if this object has this method.

In the old days, we wanted to make the arguments of a function into an array, but that object doesn't have the slice() method. So we can invoke slice on that object using call:

jsfiddle.net/KennethKinLum/dw7jz6na/

const arr1 = Array.prototype.slice.call(arguments);

It is as if we are using arguments.slice() when arguments does not have that method.

And then call and apply just differ in how they take the arguments, as comma separated or as an array.

In the old days when there was no bind() in JS, we can use call to do a binding, because call lets us choose what the this is when running that method -- the same idea as obj.fn().

Adam Nathaniel Davis • Mar 26 '21

The operative words here are:

In the old days...

Kenneth Lum • Mar 26 '21 • Edited

yeah, some interviewers ask you to see what experience you have with JS, sometimes when you claim you are familiar with vanilla JavaScript. I think it also helps when you read some docs on MDN and about polyfill, sometimes you also see the usage of call and apply, so it is at least good to know what their working principles are.

Mike Talbot ⭐ • Mar 25 '21

Another great article. I think a lot of things like IIFEs, call and apply have more modern equivalents these days. When I read your article I looked through my main code base for where I use them and they are there, but in deep and more esoteric parts of the system where I am using them to handle attaching mixins that need to share a common this. They are deliberately there to stop developers needing to worry about stuff and never appear in anything apart from libraries. Back in the day I'd have been using IIFEs to capture loop variables for closures or making "private properties" for a class and .apply() was always for fn(...thosePeskyParameters)

Adam Nathaniel Davis • Mar 25 '21

Well said! It's not that I think those tools are pointless. I'm just not sure that they're particularly useful in "modern" stuff. And yeah... I understand that an employer may be asking about these things because large parts of their codebase are not modern. But you can be a pretty dang good dev without being knowledgeable about .call()/.apply().

Specifically, since I switched to fully-functional React w/Hooks, it's been more than a year since I even used this. And without this, there are a lotta ways to do the same things that you do with .bind()/.call()/.apply() - without using .bind()/.call()/.apply()

Graham Morby • Mar 25 '21

Quite honestly one of the most honest funny posts I’ve read here for a while. I’ve been around pretty much the same time and know exactly what you are talking about. I mean I’m not a react dev but i do Vue and see so many concepts used for the sake of using it or using the buzz word of the framework at that time.

Deffo will follow and Also keep an eye on your journey with Facebook

Adam Nathaniel Davis • Mar 25 '21

Thank you! I've never had an opportunity to do much with Vue. But as a "React guy", it definitely sparks a lot of curiosity in me (and Svelte, as well...)

Lou (🚀 Open Up The Cloud ☁️) • Mar 25 '21

A nice article, and a fun read!

As has been stated, and mentioned, IIFE's and .bind, .call, etc don't really have much place in modern JS anymore. If there are any devs who blissfully don't know about them, that wouldn't really surprise me.

However... I do think that knowledge of these constructs does say something about a developer if they've taken the time to dig into these aspects of a language. It does (in my mind) say something about a candidates thoroughness, and commitment to depth of knowledge in their craft.

Does it say much if you don't know them? Not really.

Would I use it as a selection criterion on it's own? Absolutely not.

But... is it a useful question? IMO yes... as part of a series of increasing technical questions to ask of a candidate when understanding the depth of their knowledge and the limits of their exploration in a language.

Adam Nathaniel Davis • Mar 25 '21

There's another element here, that I'm perfectly willing to admit is a "valid" use for such questions:

Sometimes you wanna ask really "arcane" kinda questions because you wanna see how a candidate responds when you find something that they're not familiar with. Do they try to BS their way through it? Do they stare at the whiteboard and "freeze up"? Or do they just tell you, "I'm sorry, I'm not really familiar with that concept" ??

Adam Nathaniel Davis • Mar 25 '21

This is a great point. And in case I wasn't clear about it in the original article, lemme make it totally clear here:

I'm not mad, at anyone, for asking any kinda interview question.

You wanna ask me about assembling byte code in my interview? Sure. Ask away. You wanna ask me to do my whiteboard coding in emojicode? Hey... it's your interview! And you can put whatever restrictions on me that suit you and/or your company.

The only "problem" that I have with these kinds of questions is that, when they're asked, you can almost feel this sense of judgment coming from the interviewer. It's usually implied (or even - outright stated) that this particular esoteric concept is one they believe that you should know if you're a "real" developer - or if you're a solid prospect for the job.

You can ask anything in an interview. But ideally, you're taking all of the answers as smaller pieces in a much larger puzzle that is: the candidate.

I totally understand that, if you're looking for a top-notch JS dev, and you ask him about .call()/.apply()/.whatever(), it's probably a good sign if they know all about it, and they can talk about the concepts inside-and-out. But it's not necessarily a bad sign if they aren't familiar with it. It's just part of the broader picture.

In some interviews that I've conducted in the past, I did indeed start to wonder "just how deep does this person's knowledge go??" And in those scenarios, I absolutely started asking more esoteric questions. But when I reach the point where I'm asking about something they're unfamiliar with, I typically let them know that it's no big deal, and I was just curious if they knew about that particular concept.

Tamer • Mar 25 '21

Why all images are streched? lol
Good luck Adam!

Adam Nathaniel Davis • Mar 25 '21

Haha, that's funny. I've never had anyone ask that at all. You have a good eye.

When I'm finding images to use, I've noticed that 1280x500 seems like an ideal size to properly "fit" in the body of the articles. So I take the images and crop them to that size. But sometimes they're a little too tall/short or a little too wide/narrow to fix them easily with simple cropping. So if they're still a little outta whack after cropping, I typically complete the process by just resizing them to 1280x500.

On most images, it's hard to even notice, unless you have the original sitting next to you for comparison. But again, good eye!

Tamer • Mar 26 '21

Okay my friend! As front-end I suggest you to take care about visual... it's become too much important 😉

Davide de Paolis • Mar 25 '21

Evaluators in Big Tech wanna grill you. About esoteric programming concepts that you'll probably never encounter in decades of real-life experience.
At least they are Big and you might end up working on some esoteric hardcore project where you might need that stuff.

What I find ridiculous is when this Interview Grill happens at interviews in tiny startups which are just looking for a full-stack dev able to quickly prototype a Mobile App with probably less than 20 endpoints.

Could not agree more with everything you wrote!

sunflowerseed • Mar 26 '21 • Edited

You know what, interviewing with Facebook or Google or Amazon, it is like, they ask you something that have 8 pages of solutions, every angle, every possibility, all details refined in at least a few hours, and they ask you to present the best answer in 25 minutes. (Two questions per interview session sometimes. If you only worked on one, it is an automatic fail).

Ok, that's the questions. And everybody doing tons of LeetCode, so that they know answers to lots of questions. So then, what, we are memorization programmers? I found they don't even care if you don't have the most optimal answer, but can think really well or not. In fact, if you can think too well, you might be not the corporate obedient, "follow the leadership" type, and you may be a troublemaker. They just want somebody to work for a few years without trouble, that's it.

And then there is the "culture". I have more than 12 years of experiences. They ask a person with 1 year of experience to interview me, and then say "It is not a good fit", or "I don't see a strong signal". What does that mean? I was writing Assembly and machine code when they didn't exist, working for the top 1 and 2nd top software companies when they didn't even exist in the world. And they are judging me, saying "not a fit"? You know, sometimes it is because I am over 40, and all their workers, including the manager, are under 30. But hey, they cannot say it is due to age. It is illegal. And the companies are not "stupid". They know how to protect themselves. So it is due to "culture fit". So that's nice. They protected themselves. And about us, as the American saying goes, "Well, it is YOUR problem, not ours."

sunflowerseed • Mar 26 '21

using IIFE, for example, is to enclosure everything in the local scope and let nothing affects the global scope.

One cheesy "expert" called that a "closure", but it is not. It merely is due to the local scope. I wrote to the author saying C could have done the same, and C doesn't have closure but just local scope, and his helper wrote back, "C may be able to do that, but JavaScript we are using closure." How assertive and incorrect. The author then later instructed his helper to "JUST CHANGE it to local scope", also assertively, and that helper just obliged.

Fahad Noor • Mar 25 '21

Hey Adam! that's an interesting article.
I would love to read an article from you that how would you conduct an interview considering yourself on the other side of the table.
And yeah we do use iife and .bind in routine programming :)

Adam Nathaniel Davis • Mar 25 '21

Glad you enjoyed it! I may indeed do an article in the future about how I interview candidates. I've interviewed hundreds of them - although, at this point in my career, I've been trying to get out of the management/interviewing game, but it still happens occasionally. In fact, the first article I ever wrote on this site was about the headaches of coding tests. And you can infer a lot about my preferences for conducting interviews in that article. But it might be useful to just do a "How I Interview Coding Candidates" article.

As for IIFE and .bind(), I absolutely don't doubt that some people use them. And maybe I'm just not grokking how/where I should use them (as a React dev, I used to use .bind() all the time - now... not so much). So I'm not claiming that they're completely useless constructs. I just know that, if you can't point to an IIFE that you've personally written, it doesn't necessarily say anything bad about your skills/knowledge as a programmer.

Pawan Pawar • Mar 26 '21

interesting!

Adam Nathaniel Davis • Mar 25 '21

Ahhh... interesting!

Jscoder17 • Mar 25 '21

love the coding features!