6 ms·

>2. I really wish I had studied JavaScript. I didn't, at all. I was like "Yeah front end is easy anyway, lets roll" and just got started developing. I did so ma

>2. I really wish I had studied JavaScript. I didn't, at all. I was like "Yeah front end is easy anyway, lets roll" and just got started developing. I did so many stupid things, suffered so much, and really resented the language at so many different points exclusively out of my own ignorance. Once I got my head out of my ass, and actually studied the language in depth I felt like so many things started making sense. Based on my experience interviewing candidates with years of alleged "experience", I marvel at how many so-called professionals don't bother to learn Javascript in any depth. I've had more than a few candidates that couldn't demonstrate how to iterate through the elements of an array, for example. Or correctly give the truth value of expressions like: " "; ""; undefined === null; and on and on. These, to me, are dealbreakers. If someone can't rattle them off, I'm not going to pay them the six-figure salary they claim they're worth. I'm surprised at the amount of resentment this sentiment of mine generates here on HN, of all places, but it does.

ta43737553757 8y ago
The fact that you even need to ask those questions (about the truthiness of those variables), means the language is a dealbreaker, to me. What absurdity.
- rhapsodic 8y ago
  >The fact that you even need to ask those questions (about the truthiness of those variables), means the language is a dealbreaker, to me. What absurdity. By "dealbreaker", do you mean that you will not take a job that requires you to write Javascript at a professional level? If so, kudos for walking your talk.
- deleted 8y ago
  [deleted]
balfirevic 8y ago
Is your comment sarcasm? I seriously can't tell.
- rhapsodic 8y ago
  It was not sarcasm.
Nadya 8y ago
If I need to test on such things does that mean I can write code like the following? var a = []; a[0] = (a[0]+"")[1]; a[1] = (a[1]+"")[2]; `${a[0]}${(!"" + "")[3]}${(!"" + "")[1]}${a[1]}`; Anyone who couldn't easily read it deserves to be fired on the spot.
- rhapsodic 8y ago
  Nadya, I don't understand the vitriol in your reply. If you think I'm being unreasonable not hiring someone who doesn't understand those basic aspects of the Javascript language, I would be interested in hearing your reasoning. Please share it if you don't mind.
  - is_true 8y ago
    I think he is being sarcastic. That code is a nightmare and if a company has code with that cognitive overhead then they better get cleaning that mess.
  - Nadya 8y ago
    I was being very heavily tongue in cheek. Your knowledge tests that people understand implicit conversions in Javascript to be able to find the equivalent boolean values. !!( " ") !!("") !!(undefined === null) You probably want to test for any falsey value though. So the interviewee understanding the ToBoolean spec [0] would be what you actually want to be testing for. if (!x) { // interviewee should be able to answer for which values of `x` this condition would run // this shows they understand which values are falsey and which values are truthy } The knowledge being tested would be "the same" but in a different, and I feel more direct, way. I felt your test was testing their knowledge of implicit conversion and not truthy/falsey values, so I wrote purposefully confusing code that uses implicit conversion. "If everyone can easily understand what's going on, there's no harm writing code like that!" /s [0] http://www.ecma-international.org/ecma-262/6.0/index.html#sec-toboolean http://www.ecma-international.org/ecma-262/6.0/index.html#se...
    - rhapsodic 8y ago
minikomi 8y ago
I'd much prefer a length check than truthiness check if I wanted to test for empty strings - that way if any nulls or undefineds come through, they would show up as errors.
- rhapsodic 8y ago
  >I'd much prefer a length check than truthiness check if I wanted to test for empty strings - that way if any nulls or undefineds come through, they would show up as errors. That may well be the best approach in some circumstances. But do you think I'm being unreasonable wanting to hire only someone who knows those very fundamental aspects of the Javascript language?
  - L0stLink 8y ago
    I don't think it is unreasonable at all. Also the code evaluates to 'nerd' that person was probably just being cheeky.
sharmi 8y ago
Hey, I can answer them all and even say how 3rd is different from undefined == null; Does that mean I am hired? :-)
- rhapsodic 8y ago
  >Does that mean I am hired? :-) Not necessarily, but it puts you ahead of about 80% of all the other candidates in consideration.
marcus-digitz 8y ago
You are the reason I keep a few pieces of esoteric code in my interview notebook. I'll gladly answer yours as long as you can answer mine.
- rhapsodic 8y ago
  > You are the reason I keep a few pieces of esoteric code in my interview notebook. I'll gladly answer yours as long as you can answer mine. I don't see those examples as esoteric at all. Ignorance of those basic things can result in all sorts of bugs. If I'm paying someone a six-figure salary, I want them to know those things. But that's just me.
  - zbentley 8y ago
    Not GP, but "esoteric" might be a less useful term than "not a great idea". I agree with what you've posted elsewhere with "knowing what you don't know" in order to check your assumptions, but that's very different than knowing the exact answers to factoids which--while useful to know about--may not be feasible to memorize in their entirety. That doesn't mean they're esoteric, just that there are a lot of them. For example, if a candidate responded to a question like those you ask with "My hunch is that they would evaluate to $answer, but I'm not 100% sure of that: I can never remember the whole JS boolean-equivalence table, so I'd look that up to be sure. May I do so now? Also, if faced with that situation at work, I would, within reason and with testing, try to remove code that relies on rules like that--which I recognize are common, but still consider a very high-risk bug surface--in the area in which I was making changes", would you consider that an unqualified candidate? Or someone with perspective?
olavk 8y ago
The rules for implicit coercion in JavaScript are rather unintuitive. When people post funny examples of JavaScript "WTF's" it is almost always surprising consequences of coercion rules. {}+[]==0 and so on. Of course you could memorize all those rules and then use them in your in your codebase to save a few keystrokes - requiring all other developers to also memorize them of course. Alternatively, you could just avoid the mess altogether and use explicit conversions, which is also what JavaScript linters recommend. But then you will easily forget the rules since you never use them. Therefore the questions say a lot about what forms of knowledge the workplace prioritize, so it is a valuable signal to the applicant. Knowing that the interviewer requires applicants to be able to rattle off these rules say a lot about what kind of colleagues you will get and how the company approach code.
- rhapsodic 8y ago
  > The rules for implicit coercion in JavaScript are rather unintuitive. Yes. And a lot of self-described Javascript developers don't even know that. Because they've never read a book or any other document that explains those rules. And that's why they struggle, like the person in this thread to whom I originally replied, and they can't produce correct code quickly and efficiently, and they create bugs that they don't understand and can't fix, and they can't correctly understand code written by someone who actually understands those aspects of the language. I agree that you can't memorize everything there is to know about Javascript. But if you don't know something, you have to at least know that you don't know it, so you can look up the correct information when you need it. But a lot of self-described Javascript developers don't even know what they don't know. For example, I know that the methods String.prototype.substr and String.prototype.substring both exist and they're both used to extract substrings from a string. But I still, for some reason, unless I've used one or the other within the last day or so, I have to check the API docs to determine which one I want to use and what its parameters are. I know that I don't know what I need to know. What I will never do, is write a loop that extracts the characters I need one at a time and builds the substring from them. But I have seen where people have done that, in production code and in technical interviews. I am of the opinion (not universally shared here on HN, apparently) that that is not acceptable from a highly paid professional software developer. And certain basic things about JS, like the ones I originally described, I think you should just know. But again, that's just me.

ta43737553757 8y ago

The fact that you even need to ask those questions (about the truthiness of those variables), means the language is a dealbreaker, to me. What absurdity.

rhapsodic 8y ago
>The fact that you even need to ask those questions (about the truthiness of those variables), means the language is a dealbreaker, to me. What absurdity. By "dealbreaker", do you mean that you will not take a job that requires you to write Javascript at a professional level? If so, kudos for walking your talk.
deleted 8y ago
[deleted]

balfirevic 8y ago

Is your comment sarcasm? I seriously can't tell.

rhapsodic 8y ago
It was not sarcasm.

Nadya 8y ago

If I need to test on such things does that mean I can write code like the following? var a = []; a[0] = (a[0]+"")[1]; a[1] = (a[1]+"")[2]; `${a[0]}${(!"" + "")[3]}${(!"" + "")[1]}${a[1]}`; Anyone who couldn't easily read it deserves to be fired on the spot.

rhapsodic 8y ago
Nadya, I don't understand the vitriol in your reply. If you think I'm being unreasonable not hiring someone who doesn't understand those basic aspects of the Javascript language, I would be interested in hearing your reasoning. Please share it if you don't mind.
- is_true 8y ago
  I think he is being sarcastic. That code is a nightmare and if a company has code with that cognitive overhead then they better get cleaning that mess.
- Nadya 8y ago
  I was being very heavily tongue in cheek. Your knowledge tests that people understand implicit conversions in Javascript to be able to find the equivalent boolean values. !!( " ") !!("") !!(undefined === null) You probably want to test for any falsey value though. So the interviewee understanding the ToBoolean spec [0] would be what you actually want to be testing for. if (!x) { // interviewee should be able to answer for which values of `x` this condition would run // this shows they understand which values are falsey and which values are truthy } The knowledge being tested would be "the same" but in a different, and I feel more direct, way. I felt your test was testing their knowledge of implicit conversion and not truthy/falsey values, so I wrote purposefully confusing code that uses implicit conversion. "If everyone can easily understand what's going on, there's no harm writing code like that!" /s [0] http://www.ecma-international.org/ecma-262/6.0/index.html#sec-toboolean http://www.ecma-international.org/ecma-262/6.0/index.html#se...
  - rhapsodic 8y ago

minikomi 8y ago

I'd much prefer a length check than truthiness check if I wanted to test for empty strings - that way if any nulls or undefineds come through, they would show up as errors.

rhapsodic 8y ago
>I'd much prefer a length check than truthiness check if I wanted to test for empty strings - that way if any nulls or undefineds come through, they would show up as errors. That may well be the best approach in some circumstances. But do you think I'm being unreasonable wanting to hire only someone who knows those very fundamental aspects of the Javascript language?
- L0stLink 8y ago
  I don't think it is unreasonable at all. Also the code evaluates to 'nerd' that person was probably just being cheeky.

sharmi 8y ago

Hey, I can answer them all and even say how 3rd is different from undefined == null; Does that mean I am hired? :-)

rhapsodic 8y ago
>Does that mean I am hired? :-) Not necessarily, but it puts you ahead of about 80% of all the other candidates in consideration.

marcus-digitz 8y ago

You are the reason I keep a few pieces of esoteric code in my interview notebook. I'll gladly answer yours as long as you can answer mine.

rhapsodic 8y ago
> You are the reason I keep a few pieces of esoteric code in my interview notebook. I'll gladly answer yours as long as you can answer mine. I don't see those examples as esoteric at all. Ignorance of those basic things can result in all sorts of bugs. If I'm paying someone a six-figure salary, I want them to know those things. But that's just me.
- zbentley 8y ago
  Not GP, but "esoteric" might be a less useful term than "not a great idea". I agree with what you've posted elsewhere with "knowing what you don't know" in order to check your assumptions, but that's very different than knowing the exact answers to factoids which--while useful to know about--may not be feasible to memorize in their entirety. That doesn't mean they're esoteric, just that there are a lot of them. For example, if a candidate responded to a question like those you ask with "My hunch is that they would evaluate to $answer, but I'm not 100% sure of that: I can never remember the whole JS boolean-equivalence table, so I'd look that up to be sure. May I do so now? Also, if faced with that situation at work, I would, within reason and with testing, try to remove code that relies on rules like that--which I recognize are common, but still consider a very high-risk bug surface--in the area in which I was making changes", would you consider that an unqualified candidate? Or someone with perspective?

olavk 8y ago

The rules for implicit coercion in JavaScript are rather unintuitive. When people post funny examples of JavaScript "WTF's" it is almost always surprising consequences of coercion rules. {}+[]==0 and so on. Of course you could memorize all those rules and then use them in your in your codebase to save a few keystrokes - requiring all other developers to also memorize them of course. Alternatively, you could just avoid the mess altogether and use explicit conversions, which is also what JavaScript linters recommend. But then you will easily forget the rules since you never use them. Therefore the questions say a lot about what forms of knowledge the workplace prioritize, so it is a valuable signal to the applicant. Knowing that the interviewer requires applicants to be able to rattle off these rules say a lot about what kind of colleagues you will get and how the company approach code.

rhapsodic 8y ago
> The rules for implicit coercion in JavaScript are rather unintuitive. Yes. And a lot of self-described Javascript developers don't even know that. Because they've never read a book or any other document that explains those rules. And that's why they struggle, like the person in this thread to whom I originally replied, and they can't produce correct code quickly and efficiently, and they create bugs that they don't understand and can't fix, and they can't correctly understand code written by someone who actually understands those aspects of the language. I agree that you can't memorize everything there is to know about Javascript. But if you don't know something, you have to at least know that you don't know it, so you can look up the correct information when you need it. But a lot of self-described Javascript developers don't even know what they don't know. For example, I know that the methods String.prototype.substr and String.prototype.substring both exist and they're both used to extract substrings from a string. But I still, for some reason, unless I've used one or the other within the last day or so, I have to check the API docs to determine which one I want to use and what its parameters are. I know that I don't know what I need to know. What I will never do, is write a loop that extracts the characters I need one at a time and builds the substring from them. But I have seen where people have done that, in production code and in technical interviews. I am of the opinion (not universally shared here on HN, apparently) that that is not acceptable from a highly paid professional software developer. And certain basic things about JS, like the ones I originally described, I think you should just know. But again, that's just me.