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.
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.
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 Reactdeveloper?
JavaScript allows for some pivoting between technologies and there are lots of support technologies within the ecosystem that benefit from skills beyond React core.
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.