DEV Community

Discussion on: Applying To Facebook

Collapse
 
offirmo profile image
Offirmo

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!

Collapse
 
pozda profile image
Ivan Pozderac

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!

Collapse
 
bytebodger profile image
Adam Nathaniel Davis • 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).

Collapse
 
loujaybee profile image
Lou (🚀 Open Up The Cloud ☁️) • 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.

Thread Thread
 
bytebodger profile image
Adam Nathaniel Davis

Well said.

Thread Thread
 
anthonygushu profile image
Anthony Gushu • 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.

Thread Thread
 
bytebodger profile image
Adam Nathaniel Davis

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.

Collapse
 
miketalbot profile image
Mike Talbot ⭐

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...

Collapse
 
bytebodger profile image
Adam Nathaniel Davis

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.

Thread Thread
 
loujaybee profile image
Lou (🚀 Open Up The Cloud ☁️)

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.

Thread Thread
 
bytebodger profile image
Adam Nathaniel Davis

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.