The point is that using "vocabulary" tests to determine programming ability is nonsense. You can still write useful JS without knowing what the hell "var" does. And if you discovered that person doesn't know what it does, then it's trivial to correct.
You say that you can write useful programs in a language for 5 years without knowing how to declare local variables? Wow. Yes, I wrote useful programs using only global variables in C64 Basic when I was 12 years old, but it was much worse code than I write now.
You can. Global variables work like any other type of variable. If you don't like that style, that's a matter of opinion. Some people don't like Hemingway's terseness, and others don't like Faulkner's run-on stream of consciousness. However, they wrote things that "worked" and were "useful" to others (their publishers, their culture, the Nobel committee).
At the end of the day, your software has to save or earn money. The salesmen and business heads don't care how pretty your code is, or if the people who developed it knew the language spec inside and out.
Again, disqualifying someone who can "do" something but in a way you don't find palatable is the core reason why hiring engineers is such a clusterfuck.
The problem is that people who write Javascript for a living, who do not use 'var' are usually the people that do not even know what the difference between global and local variables are, and why global variables are dangerous.
I have seen code that used global variables with the same name in totally unrelated different functions (the author probably thought these are local variables), and of course as one function called the other there was a bug because of it.
Also, even if it were subjective whether to use local variables is good or not (this is not subjective I think, but there are other things that are really subjective), a team cannot hire someone who writes code totally differently than them. Even if a guy is brilliant but cannot fit into a team or into a codebase that needs to be developed together, then it is not wise to hire him.
Of course I have seen companies who hire based on extremely tricky questions on certain programming languages, or when they only ask algorithmization, as if on a programming contest. These extremes are not very good in my opinion. Where I work we ask a little bit of everything, and we also work on real-world code with the candiadate together for a few days, before deciding.
> At the end of the day, your software has to save or earn money. The salesmen and business heads don't care how pretty your code is
You're right, they don't care, but maybe they should. Pretty is one thing but maintainability is another.
Global variables is one (out of many) thing(s) that decreases the maintainability of your code. It will make it more difficult to change something because other unrelated things will break. It will mess with your unit tests. It will mess with your head.
All in all, bad coding styles (like the use of global variables), while quick in the beginning, will eventually grind your feature spouting code-monkey machine to a halt. Then the salesmen and business heads will care, and by then it will be too late.
So, it's not just about taste. The number of whitespaces used for indentation is about taste. Good coding styles are not.
I don't disagree. But scope is something that's easily taught. And the term "maintainability" is subjective. Your team decides what's maintainable. So showing someone the door because they aren't aware of your version of "maintainable" is silly.
You can play this language-game all day with your candidates (and yourself), but it's largely a waste of time. I'd take someone who can "do" things, is willing to make mistakes, and willing to learn over someone who thinks "good coding styles" are set in stone and stubbornly adheres to them.
True, but this is not expected for an experienced mid-level/senior role. I would expect a senior developer to not only know the language but know the potential pitfalls.
> And the term "maintainability" is subjective.
Nothing subjective about the downsides of polluting the global scope; it shouldn't take a genius to figure out how this could lead to hard-to-debug bugs. Interviewers are interested in differentiating between candidates who have this knowledge and those who do not, so the answers to these seemingly "low-level" questions are surprisingly enlightening.
Yes, scope is very easy to learn, which is why it's so damning when you encounter someone who claims multiple years of experience with Javascript, and doesn't understand the most-basic fundamentals of scoping.
