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 that I'm gonna subject myself to the Facebook evaluation process. And as a side bonus for all of my awesome fans (both of them), I'm gonna take you along for the ride.
This is far from the first "how to get hired at Facebook" article. The web's littered with them. Will this series be any better (i.e., more useful to you)? I dunno. It may be dull AF. But I was just sitting at my desk, staring at some more React code, and thinking, "You know... maybe others would like to read about my experience through this process?"
So... here goes!
Why Did I Apply?
This is an easy answer: I didn't.
Well... I mean, I didn't go online and try to submit my resume. I didn't try to cozy up to a current FB employee in hopes of a referral. (I don't even know any FB employees, anyway.) In fact, I didn't do... anything. They reached out to me.
That probably sounds like braggadocio. But it's not meant that way. If you've been in tech long enough, your inbox starts getting pinged by recruiters from all over the dang place. It's not because I'm special. It's just because I have a resume as long as my... <ahem> arm.
And when I say that "they reached out to me", I mean it as simply as that sounds. They didn't reach out to me to offer me a job. They didn't reach out to me to give me any favored status. Mark Zuckerberg didn't slide into my DMs with 💖 emojis. One of their recruiters just reached out to me (on LinkedIn) to say, "Hey... maybe we should talk?" So I'm barely even a half-step ahead of anyone who would just go online and submit their resume unsolicited.
[Side Note: I have noticed that, in the last year-or-so, I've been contacted, a little more frequently, by recruiters from ever-larger companies. No, it's not, like, a crushing, every-day deluge of recruiters beating down my door. It's just a little more than it ever was before. I don't know this, but I suspect it's because I've been consciously growing my online footprint over this same period. But I'm not exactly sure.]
What Are My Expectations?
I expect that I will be rejected. Most likely, fairly early in the process.
No... really. Those are my honest expectations. Seriously.
That's not a self-effacing attempt to cover my bases when I "fail" to secure a job offer. It's an honest acknowledgment of who I am, where I am in my career, and what it normally takes to get hired at one of the Big Tech firms.
Because Big Tech pays more than most, and because they have a certain "cachet", they tend to put candidates through the most grueling evaluation processes. And make no mistake about it: I do not tend to do well under those processes.
To be clear, I have no qualms whatsoever about my tech knowledge. I'm entirely self-taught. And, if I'm putting my modesty aside (what little of it exists), I believe I've done pretty well for myself over the last quarter-century of professional programming. But no one in Big Tech wants to give you a gold star for those kinda bootstrap accomplishments.
No.
Evaluators in Big Tech wanna grill you. About esoteric programming concepts that you'll probably never encounter in decades of real-life experience. They wanna put artificial constraints on your evaluation - like timers - that probably don't accurately reflect how you code in the "real world".
But you know what? They can do that. Because they're Big Tech. And when you write the Big Checks, you can define the Big Hoops that everyone should jump through if they wanna be part of your cool club.
I encountered a taste of this last year when I was approached by Amazon. I was pretty flattered to even be pinged by an Amazon recruiter. And at first, I was pretty excited about the idea of going through their hiring process.
But then I decided that I'd better hone my skills before I went through their gauntlet. And I started doing a lotta online coding challenges. And I started trying to cram my brain with nitpicky details about how to optimize every possible sorting algorithm.
Before I could pull the trigger on the "formal" Amazon evaluation process - I ended up getting a really solid job offer from another company, and I allowed the Amazon process to go fallow. But I clearly remember some of the exercises that I was wrestling with before I dropped the process. I was smacked upside the head with a great many micro-optimizations. I was expected to be conversant in concepts that I've never had any need for over 2.5 decades on the job. Quite frankly, sometimes I almost felt "small" because I couldn't ace some timed (15-minute) coding challenge. It was... humbling, to say the least.
The Effery Of Big Tech Interviews
Lemme just give you two examples of the hoops that Big Tech may want you to jump through.
I was warned that one of the key interview questions may be about .bind(), .call(), and .apply(). As a React dev, I'm intimately familiar with .bind(), although, at this point, I view it as something of an anachronism. I can't honestly remember the last time that I wrote any code that included .bind().
As for .call(), and .apply()??? I won't lie. After I heard this, I had to run to Google to look them up. And even after I looked them up, I thought: "WTF???" I mean... I understand them conceptually, but I can't honestly think of a single REAL-LIFE instance where I would, you know... USE them. Specifically, they seem borderline-pointless if your primary specialty is that of a React dev.
It's kinda like IIFEs. I mean... I know what an IIFE is. In fact, I've even seen them used a few times - in other peoples' code. But I've never found any practical use for them myself. Every blue-moon-or-so, I find myself writing something and thinking, "This might be where I finally write my first IIFE!" And then... no. It turns out that there's a better way to accomplish the task - without an IIFE.
I was also told that I'd have to be able to talk about event delegation in JavaScript. Now to be clear, I've dealt with delegates in other languages. But I've never even thought about a "delegate" in JavaScript. Furthermore, when I looked it up and internalized the concept, I immediately thought, "I've already been routinely handling this in React - but not through means that comply with the online examples."
Think about that. I was only told, in passing, about two concepts that I'd probably be asked about in the interview. And despite 25 years as a programmer, I'm already oh-for-two on them. I can Google those concepts now (and I have), but what does that say about my overall odds in the FB interview process??
Umm... not good.
The bottom line is that Big Tech will ask you about arcane tech concepts. Concepts that have little-to-no bearing on your actual job. And they'll do it because... they can. Because they have a mountain of over-qualified candidates to sort through. Because they write the Big Checks.
So for myself, a guy who's incredibly-confident in his own programming skills, where does that leave me? Well... probably not in a good place. Because I can't be bothered to dive down deep theoretical rabbit holes of coding esoterica. I have to dive down deep programming rabbit holes of... productivity. And the job market doesn't always smile on such practicality.
Why Am I Leaving My Current Job?
I'm not! (At least... I don't think that I am.)
Look. It's no secret who I work for. You can see it right on my profile. And I suppose that, on some level, I'm taking a calculated risk by even posting this article. But the simple fact is that my current employer is pretty cool. I'm not pounding the pavement looking for a new gig. And, as I've already spelled out, I don't honestly expect to receive any job offer from FB.
Even if someone at my company managed to find this article and confront me about it, I'd tell them the same things that I'm telling you:
I have no realistic expectation of actually being hired by FB.
I'm not "looking". I didn't approach FB (or anyone else).
Now that they've reached out, it honestly just seems like a kinda fun/interesting exercise - like a programming puzzle to solve.
The most-likely outcome of all this is just that it spawns some engaging blog content that may help others in this process.
And even in the craziest scenario (FB actually offers me a job), it's not as though my small employer really assumes that they are competing against FB for employees. It'd be like if you're dating a really nice girl - but then she leaves you for Henry Cavill. What would you say to that?? Nothing! You'd just shrug your shoulders and move on.
Why Facebook??
As I detailed above, I already started - and then aborted - the Amazon application process more than a year ago. So what's different now?? Only three things:
Although I have a certain distaste for much of the tech-snobbery that happens in Big Tech interviews, the simple fact is that I've been heavy into React for the last 5-6 years. And FB is the birthplace of React. So part of me thought, "Well... I gotta at least explore this."
My current employer is pretty dang cool. The only "problem" with them is that I can't work out of the country. I can work anywhere within the USA. But I must be in the USA (it's a side-effect of government contracting). I sincerely want to live, for months at a time, in places like... Montreal. Or Ecuador. Or Amsterdam. Or... anyplace.
It's a good story! I think it might be helpful for others to follow my "journey" (even if it ultimately turns out to be a very short journey).
What's Next?
I gotta send them an updated resume. (Which is its own little hurdle - my current one is quite... deprecated.) They sent me a bunch of videos and "guides". So once I start going through those, I'll post my next follow-up article.
Stay tuned!
Top comments (42)
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
.reduceor.mapand co. because I found them "too complicated to read". My coworkers forced me to rewrite my clumsy loops into proper readable.reduceor.mapand 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
.callor.applyor IIFEs often, I still use them at least once every few monthes.Let's be open!
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).
"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.
Well said.
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.
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.
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!
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...
Same here. I now use
Array.prototypefunctions 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.Very rarely, if ever does something need to be a
.forEachas 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.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
forEachas 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 withforEachloops, 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
forEachloops 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 theArray.prototypefunctions - but I'm definitely a lot closer than I was several years ago.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: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.
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...)
Justification:
i.e. it made it possible to create objects without a prototype that carried the standard object methods.
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:
Meanwhile non-FAANG companies are simply copying the mining (selection) practices of the FAANG companies assuming that there is enough gold to go around.
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:
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.
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.
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.
The comment was about
call()andapply()- notno-prototype-builtinswhich in itself only served as a present day example forcall().Fair enough - see this treatment then:
Decorators and forwarding, call/apply
Hopefully that is more relevant in the present.
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()andapply()- notno-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.Yeah, sure.
I quoted it as the last occurrence of a repeating pattern - in the body of the original article your stated:
which expresses the same sentiment as the section I quoted. That said the reaction
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 pointPerhaps 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).
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.
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.
Sure, but
call()andapply()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.
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.
callandapplyare 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 invokesliceon that object usingcall:jsfiddle.net/KennethKinLum/dw7jz6na/
It is as if we are using
arguments.slice()whenargumentsdoes not have that method.And then
callandapplyjust 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 usecallto do a binding, becausecalllets us choose what thethisis when running that method -- the same idea asobj.fn().The operative words here are:
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
callandapply, so it is at least good to know what their working principles are.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 forfn(...thosePeskyParameters)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 withoutthis, there are a lotta ways to do the same things that you do with .bind()/.call()/.apply() - without using .bind()/.call()/.apply()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
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...)
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.
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" ??
This is a great point. And in case I wasn't clear about it in the original article, lemme make it totally clear here:
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.
Why all images are streched? lol
Good luck Adam!
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!
Okay my friend! As front-end I suggest you to take care about visual... it's become too much important 😉
Could not agree more with everything you wrote!
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."
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.