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).
Re-thinking developer experience • Product @Gitpod 🍊 Helping folks get their start in cloud • @openupthecloud ☁️ AWS Community Builder 🛠 Replies in GIFS 😃
"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.
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.
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.