Since I began blogging on Dev.to, one of my primary subjects has been the (arbitrary) standards that we apply to others when we evaluate them as po...
For further actions, you may consider blocking this person and/or reporting abuse
What’s wrong with
this? Seems like the classes support in JS is a lot better now than it used to be andthisis a pretty essential part of that. I like a functional style too but sometimes a class is a good option.I don't disagree with you. Maybe I should've been a little clearer in stating that, for the last 4-5 years, I've been almost exclusively a React dev. And in React, everything seems to be trending away from classes and toward functions. I'm on record as not "believing" in that trend - but I'm also on record as wanting to keep getting paychecks. So, for some time now, I haven't written a single class. Anywhere.
To be clear, the
thiskeyword still "exists" in functions. But if you're writing purely in functions, I think it's a rather dodgy practice (obviously, just my opinion there) to keep usingthis.Yeah that makes sense.
thisin a functional style would be weird.I'm not sure if I'm one of them or one of us. I'm a fan of using classes in JavaScript, I use tabs, and I prefer object dot notation, however I abhor the
functionkeyword and I loveasync/await.If you're not hung up on tech "shibboleths", then it doesn't matter where you fall in that combination of traits.
Heh, true I guess.
I'm definitely guilty of judging people on how they write their code though. I do try to avoid it but sometimes it cannot be helped. Seeing
vareverywhere will change a person.I agree, but
varhas quantifiable reasons why it's potentially harmful. (Of course,varisn't necessarily harmful - it's just potentially harmful, depending upon how you use it.) So I understand the aversion to seeing any new code written withvar.Contrast that with those who shudder every time they see
classin JS code. I have yet to hear a single quantifiable reason why this is "bad". All of their arguments fall back on fuzzy bromides and vague notions of "best practices". Yet they'll still use the appearance of thatclasskeyword as a shibboleth to eliminate you from consideration.Thanks for the great article! I totally agree with you and can admit of being guilty of sometimes carrying out "litmus tests" myself. It is total nonsense to discard a candidate if they don't know a specific thing or two in a given language.
Could such tests bring more value when there are sufficiently many of them? If the applicant doesn't know async-await, cannot explain "this" in JS, cannot code a binary search tree, and doesn't know what a pure function component is, isn't it then reasonable to be able to make the assumption that this candidate may not be the ideal candidate for our company? We cannot rank the candidates by how many they got "right", but we can say whether they passed or failed. Does this make any sense?
Yes, I totally agree. It's incredibly valuable to ask a candidate a range of questions on a range of topics - or to ask them to attempt a range of different whiteboard-style challenges. But as you point out, the key is to not treat any one of those questions/challenges as a "knockout" issue. Instead, look at the aggregate value of all the answers combined.
Also, I think it's important to differentiate between "the candidate can't code this from scratch off the top of his head" versus "the candidate has no idea what this concept is, when to use it, or where to find information about it."
In the example I gave regarding binary trees, I know dang well that I can't sit down, right now, and code it up from my head. But I know what a binary tree is. I know when you generally consider using one and what benefits (and downsides) it provides. And I know that, if I had to go code one up tomorrow, I could absolutely be "up to speed" on it in a very short period of time. That's far different than dealing with a candidate who's never even heard of a binary tree and has no clue what purpose it would serve.
Such a great job of framing the issue. I love apply, I wish people knew it so I could use it. But is
add.apply(null, [10, 20])more readable or understandable thanconst [x, y] = [10, 20]; add(x, y)or some other variant? Maybe, maybe not. It depend on who you're working with! And if I'm being honest, it probably isn't more readable in any situation. And only once in a blue moon do I use it.Then the functional vs OO, and promise chain vs async await is so great. I caught myself thinking, "but async await is more imperative. Even if it is the new shiny!" And there lies the problem.
This is a great article. I'm going to keep it in my back pocket the next time we do an interview.
Aside: putting together a good interview seems to be an art in itself, I'd love to hear some new ideas in that space
An excellent article that totally describes my feelings of becoming failure in many interviews.
They ask question that seems very simple to them, but when you give them a answer that they do not know becomes a very new and unique thing, I will continue with a very simple example.
let's say you are at an interview and someone asks you "What is Node.JS?" and You answer, "It is a Run Time Environment for JavaScript." if you stick to this question, they will assume you a good candidate but if you say, "It is a Run Time Environment for JavaScript, that uses operating system's I/O operations along side with POSIX." they will consider you an alien and it is quite possible that they will not think you as developer as well.
One more thing, the devs that are taking the interview often forgets that there are multiple ways of solving the same problem, and programming is a very vast field and there are many to infinite things that a person still requires to learn as well. So, becoming a good developer is a long and exciting journey.
There should be a good and effective manner of judging the candidates, rather than these boring hard-coded interview questions, because they represent the fragment of the memory not the knowledge about the programming or a mind filled with passion to solve the problems.
Very well said!
I think the problem is that it is impossible to gage overall skill based off any arbitrary number of fixed questions. I usually ask open ended questions so that candidates can show me what they are most skilled in.
“Tell me about an interesting problem you solved.”
“What is something exciting you learned lately”
If I have to do whiteboarding I would go with some kind of general knowledge use case. For example, measurements.
As an occasional technical interviewer I find it difficult to separate the knowledge I value from what matters.
Most candidates I’ve interviewed in webdev have little experience and zero theoretical knowledge about the tools they use, which is fine for junior entry level. What I find more problematic is for instance when an intermediate React developer has never heard about the event loop, or has never read the official React documentation.
Sometimes, even though I don’t value the answer, I ask basic shibboleth questions, like code syntax, on purpose to check if the candidate took the time to read things like “how to prepare for a React job interview” to check his level of commitment in his job search.
The insight about the one thing vs. Tesla's self driving system is pure gold.
Hahaha - thank you!