Hacker News Reader

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.

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

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

It was not sarcasm.

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.

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.

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.

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

Nadya, whether or not that's the best thing to test for is beside the point. All I'm saying is that, in my view, a professional Javascript developer should know those things. And apparently, a lot of people on HN disagree with me.

>Nadya, whether or not that's the best thing to test for is beside the point.

What you test on is almost as important as how you test on it. Interviews go both ways after all. I think a majority of people aren't disagreeing that a professional should know these things - but asking them to "rattle off an answer to [question]" is looked down on. It reeks of the "reverse a binary tree" or "implement [some sorting algorithm]" type of questions.

I consider myself a Javascript professional (in so much that I am paid primarily for the Javascript work I do) and I had no issue knowing the answer to the three items listed. If I was asked to rattle them off the top of my head as some sort of Fizzbuzz Filter equivalent - I'd thank you for your time and leave the interview.

I agree people should know the answers - which (as you've pointed out) is the point you're trying to get across. But how you share that point, much like which questions you ask, is important.

I think you're reading too much into the phrase "rattle off". By that I simply meant that the interviewee should know those things well enough to answer correctly and confidently.

And it still amazes me that this position seems to be controversial here on HN. There are people who have expressed unequivocal agreement, to be sure, but a significant number seem to see that stuff as obscure arcana that a developer would not typically need to know.

I like your forward thinking! Is the following also allowed?

   `${Array(5).join("pi" * 3.14)}, ${atob("QmF0bWFu")}`

Just ran into ing atob the other day. The creator of the language admitted that it was basically a late night for him and he copied python or something.

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.

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

I don't think it is unreasonable at all. Also the code evaluates to 'nerd' that person was probably just being cheeky.

Hey, I can answer them all and even say how 3rd is different from

undefined == null;

Does that mean I am hired? :-)

>Does that mean I am hired? :-)

Not necessarily, but it puts you ahead of about 80% of all the other candidates in consideration.

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.

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

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?

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.

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

A huge reply after being so damningly called out? Please do keep asking those gotcha questions.

It's like the flip-side of foobar, avoid like the plague any place where all the tech questions are gotchas or obscure language features. The lead developer is probably someone you do not want to work with.

>A huge reply after being so damningly called out?

Serious question: what the hell are you talking about?

>It's like the flip-side of foobar...

WTF does that even mean?

>avoid like the plague any place where all the tech questions are gotchas or obscure language features. The lead developer is probably someone you do not want to work with.

If you consider those questions "gotchas" or "obscure language features" you don't stand a chance of working with those lead developers. Their process is designed to weed people like you out.

I think, for the book I'm writing, I can build an entire chapter around this subthread. Can I quote you by name, mattmanser?

>It's like the flip-side of foobar...

I suspect they meant FizzBuzz, but am not sure.

> If you consider those questions "gotchas" or "obscure language features" you don't stand a chance of working with those lead developers. Their process is designed to weed people like you out.

> I think, for the book I'm writing, I can build an entire chapter around this subthread. Can I quote you by name, mattmanser?

I recognize that this may not be how you meant it, but that comes off as condescending and rude. Please be polite--for our sakes on HN, and in order to attract good interview candidates! I and many of my colleagues have left offers on the table before, even without other open offers, due to impressions of similar (much worse, but on the same axis) condescension and hostility during interviews.