[fnbr]

As a junior developer, I find myself confused by your comment. It seems as if a large proportion of the posts on HN claim that, when looking to hire someone, they focus on problem solving abilities and and culture fit.

However, in May when I was interviewing with companies (including YC backed startups), almost every company focused on quizzing me about trivia [1]. I was actually given a paper quiz by one of the companies on equality comparisons in Javascript (e.g. "Does 4 == '4'?"), which I found pointless, as I can test that within seconds at a computer.

[1] The major exception was 42Debut. Even though they didn't give me an offer (just stopped replying to my emails, but c'est la vie), I was treated with respect throughout the whole process, and the interview was very well done, with challenging questions that forced me to think, and didn't rely on language trivia. I would recommend the company to any of my friends, whereas I can't say that about almost any other company I interviewed with.

[lostcolony]

That kind of question can actually be useful as a proxy for experience with the language, and whether you're the type of person who digs into understanding your tools. If you say "I'm a rockstar Javascript dev", it's very hard to prove it; but if you've never been bitten by some of Javascript's type conversions, and/or have never really looked into some of its intricacies on your own, you probably aren't. It's just one data point, it won't be enough on its own to sway the interview either way, but it's interesting.

To give you an idea, I once interviewed a Javascript dev who said you should null out your variables with 'undefined' when you were finished with them. Oh, why is that? 'Because sometimes they leak out into the global scope and that can cause problems elsewhere in the code.' This person had noted that you could declare a global anywhere in Javascript, but had not noticed, nor asked anyone, nor looked up, nor anything, to find out that there's a difference between "x = 5" and "var x = 5". We didn't hire him.

Had he simply been unaware you -could- declare globals (and had instead said that "x = 5" won't work, you have to use the 'var' key word, or something), we wouldn't have counted it against him; he's following a best practice and never encountered it, fair enough. If he had never been bitten by the scoping rules, fair enough, a minor ding but we'd continue the interview. But the fact he had seen it, possibly been bitten by it, and just handwaved it away as non-deterministic weirdness that required a mystical incantation to avoid? No.

[x0x0]

I find it hard to believe anyone has spent a bunch of time writing js and never been bitten by a type conversion. Am I wildly off base?

I do data science, but everyone who writes R has been bitten by it's scoping rules, which are definitely not mainstream. Everyone I know who writes java or python has been bitten at least once by the pass object references by value (is there a better name for this?) function argument semantics. Everyone who writes java has accidentally written == when they meant .equals and stared at the code for far too long. etc etc etc You just can't claim you can competently use a language without understanding some basics, like how functions work, how arguments are passed, and how equality is decided.

[scarmig]

Not at all off base.

Which is the reason I would be deeply annoyed by the 4 == '4' question. The technical answer is it evaluates to true, but the real answer is "any code that requires all readers to have intimate knowledge of Javascript type conversion rules to read and understand is horrific code."

[x0x0]

I'm with @lostcolony: if I were interviewing and a candidate said "don't do that, it's unpredictable, do this instead" it's a great answer.

[fnbr]

At the same time though, as someone looking for their first dev job, I'm not going to tell the interviewer "don't do that." Given the people I've met in industry, I can't see that ending well- I would expect some variation of "who does this kid think he is!?"

[SilasX]

True, but one time I was asked about the difference between "foo = bar" and "var foo = bar", and my answer was, "Don't do the first."

[x0x0]

You can always phrase it as, "That's ill advised, here's why, my guess is it does X, but you probably shouldn't do that in production code".

[kourt]

pass object references by value (is their a better name for this?)

Barbara Liskov used "call by sharing", aka "call by object-sharing" or "call by object". http://stackoverflow.com/questions/40480/is-java-pass-by-ref...

[x0x0]

thank you! I really like that

[lostcolony]

Agreed. So when someone answers it wrong, while claiming some knowledge of Javascript, that's kind of a major ding against them.

[mikeleeorg]

I was treated with respect throughout the whole process, and the interview was very well done, with challenging questions that forced me to think, and didn't rely on language trivia. I would recommend the company to any of my friends, whereas I can't say that about almost any other company I interviewed with.

This is a really important point to remember for interviewers. The interview process isn't just to help you find good candidates, it can be a great branding/marketing vehicle as well. I've gotten many good people from former candidates who enjoyed our process and spoke highly of our team.

I wouldn't have just stopped replying to emails though. An interviewer should always reply, even to politely decline. And it can help to add a reason why you are declining a candidate too, since it can help them improve and perhaps return for another interview in the future (I've hired a few people that I originally passed on too).

[danielweber]

Of the many companies that have rejected me, Suitable Technologies (makers of Beam robot doubles) were the best. The biggest thing was that they rejected me as soon as they knew they had rejected me. Within a few hours.

Which hurt, in the short term, because I am a human being. But it was better than many other companies that would say "we'll tell you later today" and then wait a week, or wait for two weeks since my last interview and then reject me in the middle of the CTF they are running and I'm participating in (what, did my answers in the CTF suck?) and then invite me to apply for a job at the end of the CTF after rejecting me. That's really yanking my chain.

[dllthomas]

"And it can help to add a reason why you are declining a candidate too, since it can help them improve and perhaps return for another interview in the future (I've hired a few people that I originally passed on too)."

I've always tremendously valued the rare feedback I've gotten, but my understanding is this is not the same advice a lawyer would give (and that makes me a little sad).

[Jemaclus]

I don't generally ask those kinds of questions. Mine are more of the algorithmic variety (i.e., given this problem, how do you solve it?). Having said that, the last 10% of getting the job is demonstrating that you know SOME programming. I may ask you some programming questions like the one you presented, just to see whether you know programming at all. If you got this right, you're 95% of the way in the door, as opposed to just 90% of the way in the door. It's not a deal breaker -- I can teach you the difference between 4 and '4' -- but it's a huge plus if you get it right.

Plus, like the article says, most people suck at tech screens, so that interviewer may have just been asking random questions with no clear idea of what they're looking for.

[x0x0]

Testing 4=='4' is far from pointless. For better or worse, programming as the majority of us practice it is no longer about flipping bits or moving bytes or red-black trees or building common collections data structures. It's now about a language plus an api or apis, and the language of front end web development is javascript. So checking if front end or fullstack dev candidates have a basic understanding of types in javascript is perfectly reasonable.

[RogerL]

One can learn facts. In fact, it is incredibly trivial to do so if you are smart. I need to do it dozens of times a day to do my job, as does any programmer.

I don't program javascript at all, but am vaguely aware of the terrible implicit conversions it does. Isn't that the important part? I do not have memorized that

   false == 'false'    // false, yet
   false == '0'        // true

Why would I (I had to google that, took 5 seconds, btw)? It is ugly, terrible code. Sure, if I spend my days in a terrible code base I might be forced to learn those conversion rules, but that isn't exactly the mark of a hirable person - it is just the employment history of that person.

Now, if somebody who claimed they knew javascript was writing 'j := 0' for assignment I'd be concerned - but probably they've just been writing a lot of Go lately.

I can see a question like this being asked as part of a lead in to a more general discussion about types, type conversion, how different languages manage it and the trade offs thereof. But, most of the nit-picky questions I have ever been asked in an interview were just nit-picky. What is the output of the obfuscated C? What happens if you abuse the syntax like so? Just pointless questions compared to the real thing you should be measuring - can I produce high quality code on schedule and budget that adds value to the organization without making everyone around me wish they were dead rather than talk to me again? Can I recognize inefficieces in the company and improve things? Can I step up and lead a team or a project? If asked to do something outside of my comfort zone, like go on a sales call, can I do it? Will I complain bitterly if asked to fix bugs for awhile? Will I skip off to a new job just as I start becoming productive at your company? Can I mentor junior people? Can I converse with the CEO and tell him difficult facts if necessary? Can others read my code, modify and extend it without undue problems? Can I untangle other people's spaghetti code?

Measure that stuff, not whether I know if 0 == 'false'.

[x0x0]

Um, no. If you don't understand types in js, you don't understand js. I'm not hiring a front-end engineer who somehow hasn't learn js unless he or she is a totally raw intern. And a 1st or 2nd year intern, not a 4th. For anyone else, you need to know js, and if you don't understand types, you don't know js. If you need to google your example, you simply can't write js on a daily basis. (The one exception is, as noted below, saying "don't do that, here's why, do this instead"; that's a great answer.)

Types, functions, objects, classes, type conversions, etc, are part of the minimal working set needed to write code in a language.

[nawitus]

Well, testing 4 == '4' is pointless in my opinion, because you should never use the '=='-type equality in JavaScript. I never use it, so I don't even know what that evaluates to. You should always use ===, and set up a linter to enforce that.

What I think is valuable to understand is the concept of truthy and falsy, as I've seen even some experienced JavaScript programmers struggle with that. Maybe that could be a decent interview question.

[lostcolony]

A response of "I'm not sure; I always rely on === and explicit conversions to avoid the ambiguity. My guess would be (doesn't matter) though" is not only answering that question, it's scoring an 11/10 of the possible points (were it pointed).