But I make sure to not judge them on that. They're often over zealous and looking for a job, so I don't blame them. The content of the interview is the real meat and potatoes in my experience.
Heh. I've written production code—and lots of it—in... god, eleven or twelve languages? Not counting transpile-to-JS languages—add another two for that. Also not counting markup languages or CSS or anything like that. Oh, and I forgot bash, if that counts (not sure I'd count it).
I'd probably get stuff like "how do you declare & populate an associative array?" wrong in at least half of them, and the others I'd basically be guessing but luckily several accept syntax so similar that if I used it on all of them I'd be correct in enough cases to get me up to about half-right. I'd have about as much trouble with this task in languages I last wrote fifteen years ago, as ones I wrote code in today.
Stuff that's common to most or all languages, I tend not to keep in my head. Any given language probably has this kind of feature, so I just expect it to be there, and not confined to any particular language. I crib off nearby code, let my tools tell me the correct invocation, or look it up. If it's anything even somewhat common, there's usually an example nearby to use as reference, so it hardly even slows me down. If it's uncommon enough in the codebase that I have to look it up or spend 10 seconds finding an example in some other file, that probably means I'm not having to do that often, so that's OK too.
Honestly, once a person has demonstrated some proficiency in a cross section of languages, you should just skip the language proficiency section and instead talk about how learning new languages has gone in the past. Look for any red flags or biases that are going to be a hindrance in the new languages particular paradigm, but otherwise the “can you X” is already a done deal.
What if I can google how to do that in all of the languages I've used (and many I haven't) faster than most can write it out from memory? How do I convey that to you and what is it worth to you?
Wrote memorization like that is one of my weaknesses but I can compensate for it. I heard an interesting theory that one aspect of intelligence is how efficiently you can forget information that you don't benefit from retaining. If our brains have finite storage capacity that seems pretty logical.
I'm smarter than what I thought :-)
& frequently forget how to iterate through arrays and objects in Typescript although been using it for years
> if I can google
Sounds fine with me, or via an IDE, or pseudocode
Which is to say, the difference between a genuinely good candidate and one that merely claims to be is clearly visible in exactly the kind of interview the linked article is arguing against.
I think there's lots of room for criticism of the Big Tech Coding Interview. But "it doesn't work" is just not reasonable. It does work, it objectively works very well, probably better than other techniques (the existence proof being that there aren't any other hiring organizations out there beating the FAANGs at their own HR game).
If you want to criticize, point out that it doesn't necessarily work fairly. It rejects specific qualified candidates more often than it should, and it fails to reliably measure other areas of qualification than mere technical skill.
But don't say it doesn't work, or that it's a waste of time. Show, don't tell. If you know how to hire better people, then do so and beat the world.
You touch on one of the reasons this technique isn't used in general:
> it’s quite difficult because it requires the interviewer to know their shit
Having an interviewing team in an engineering org n > 100 with the following properties is nearly impossible:
1. Everyone knows their shit
2. Everyone cares enough to give the interview well
3. Has enough throughput to meet the company's hiring needs
4. The interviews are given in such a way that legal isn't worried we'll get slapped with a discrimination lawsuit