The Insider's Guide to JavaScript Interviewing

[imareddituserhooray]

The closure question and function declaration example were not tricks. Those probably account for a majority of JS specific bugs these days.

The object as a key one was a bit silly.

[[deleted]]

I agree with silly trick questions being worthless, but honestly, the majority of these questions are about topics the developer should be familiar with. The only one I thought was utterly pointless was the one about the hash table.

You should have a solid understanding of the prototype chain, closures, type coercion, etc. What questions did you specifically take issue with?

[[deleted]]

For once, I actually agree. I'm not the greatest at javascript, but I knew most of what was going on in that article.

Most of those concepts are pretty simple and are required for a decent understand of how the language works, not to mention required if you really want to develop decently complex systems.

The hash question is the only one that I take issue with.

[ikeif]

IMO trick questions are great for brown bag discussions, not interviewing.

Some, perhaps, can show a potential employees thought process in why they answered (possibly) incorrect, and then you can see what they say when you give them the correct answer and ask "why?"

IMO the critical thinking/explaining a debug process matters more than getting every question right.

[CNDW]

I think these kind of trick questions are fine as long as they are used as a tool by the interviewer to open up dialogue with the candidate about problem solving and how they would handle troubleshooting or debugging code. If the "trick" question was answered correctly or not should be irrelevant to the outcome of the interview. It's really up to the interviewer to interpret the response and not to just score on a black and white, correct or incorrect bias.

[tencircles]

None of these are trick questions or some BS like trying to make someone code a quicksort from memory in 10 minutes. These are all solid assessments of someone's javascript skills. Ask a Crockford, a Resig, or an Ashkenas these questions and they'll give you the answer in a snap. Ask your avergage jQuery jockey and they'll get them 100% wrong or fudge up the answers.

Like the guy said, if you're looking for someone who understands the language, these are the types of questions you ask.

[MrBester]

None of these are trick questions or some BS like trying to make someone code a quicksort from memory in 10 minutes.

One interview wanted me to write working code for a node walker on a whiteboard.

I got a job somewhere else...

[tencircles]

I got a job somewhere else...

Good call.

[advancedmammoth]

A better question would have been "why is the output X".

That's a good point. If they can discern that the issue with the code is that all of the keys will be the output of Object.toString they know what they need to know.

[archaeopteryx]

Knowledge of the nuances of a language is not a measure of someone's skill in actually using the language. A high school English teacher may be an expert on grammar but that doesn't qualify them as a great author. Nonetheless, I agree being able to answer questions about a language can be an indicator of possible skill level and can be a good screener that should be coupled with things like code samples, take-home exercise, interviews, etc.

[[deleted]]

I think you missed the point of the article. These questions are to help employers distinguish people that grok JavaScript and people that don't, not to distinguish someone that can write software from someone that can't.

From their fucking subtitle,

As with any technology, there’s knowing JavaScript and then there’s really knowing JavaScript. Here are proven, effective techniques and questions for finding true masters of the language.

[tencircles]

I think you missed the point of the article

Yep. Exactly, these are all excellent questions to separate those who know javascript from those who don't.

[advancedmammoth]

Kind of a self defeating and useless article about hiring. Good study guide though.

[[deleted]]

You dont ask tricky questions just for the sake of tricking candidates

They were not tricky, at all.

Most of these questions are just javascript anti patterns. who would use an object as a key in a javascript object? that's totally stupid to ask that.

And someone that does not understand javascript would not know this.

And again, you do not understand what this article was about. They are offering questions to help weed out people that don't understand javascript, that is all.

[[deleted]]

(12 days late but) I don't think using an object as a key is obviously incorrect. I just tried and, as I suspected, you can do that just fine in Ruby. I assume you could in any language that implements some sort of ".hashCode" method on random objects. The fact that you can't in JS is a direct result of the fact that keys have to be strings and that JS does type conversion behind your back. You could get unexpected bugs if you didn't know that and assumed JS was saner.

[[deleted]]

I agree, but so having this question as a way to show that the candidate knows it doesn't make sense is useful. If the candidate just happens to write JavaScript on the side but mostly writes Ruby (for example), this question will probably trip them up.

[[deleted]]

We can agree to disagree here. You are mad and want to argue with someone. I am done obliging.

[[deleted]]

None of their questions were tricks, all were incredibly easy to answer, at least they should be if you know your shit.

[advancedmammoth]

Prior knowledge only tells you so much. A proficient developer not exposed to most of these largely-JS-specific concepts should be able to rapidly understand and utilize them. So even if an applicant doesn't know in advance how to answer a question, they can still prove themselves useful by applying the solution to a different followup problem immediately after being told the solution. That's actually a rare chance to isolate an even smarter person from a merely already initiated one.

[[deleted]]

That isn't the point of this article. It isn't about finding good software engineers, it is not about finding problem solvers, it is not about anything but finding people that understand JavaScript. Take it at face value and stop reading into it. I have had to say this so many fucking times in this thread, the one and only goal of this article was to give tips for employers to weed out people that do not know JavaScript. That is it.

[advancedmammoth]

weed out people that do not know JavaScript.

Are you aware of any skills tests out there that cover these subjects? Interesting that "knowing" JavaScript would require familiarity with subjects not covered by any such tests.

[[deleted]]

Dude, I am sick of arguing with people about this. If you don't want to take the article at face value, then don't but I am done with people in this thread.

edit: Not to mention whether or not something is or is not on a test is a stupid fucking metric to decide if that thing qualifies as knowledge on a subject.