> Perhaps the better approach to solving this problem is to stop repeating it on tech blogs, and start moving to publishing and discussing it in HR blogs and si

> Perhaps the better approach to solving this problem is to stop repeating it on tech blogs, and start moving to publishing and discussing it in HR blogs and similarly appropriate, targeted mediums. I'm a computer programmer, but I also do recruiting for a company in Amsterdam and their approach is most definitely "talent". A typical question is "given two arrays, find all the elements in one array that are also in the second array". Most people come up with the standard O(n*m) "two loops" solution the first time (for x in first, for y in second, if x == y ...). The company might let that slide as interview nervousness and ask if there's a way they can do it faster. They completely understand if your programming background is different and asking "trivia" questions about a given language or requiring you to check some tech boxes is silly. You just have to be competent. Sadly, most programmers aren't competent. If they tell me they're comfortable with OO programming, I'll ask them to define OO programming for me and then I squirm as I listen to them. But then gems show up and I have a lively conversation with someone who really knows their stuff and we offer them a relocation package to Amsterdam. Helping people live their dreams like that is really awesome, but I couldn't do it if I was forced to demand that programmers check off boxes on a form. (Relevant side note: I've routinely worked for companies for which a knowledge of UML was "required". I've never used this in my professional life)