I wonder whether are language specific tests good for selecting potential candidates? Questions such as
and so on. The candidates have to answer them in a given time frame.
Only if you must have someone who already knows the language in question well. Otherwise you'll lose potentially brilliant programmers who have not or only little used the language. I can learn a language well in a month or two; it's taken me nearly 30 years to become the programmer I am today.
Personally I can't stand them.
The big failing is that they exhibit (or imply) that the interviewer doesn't really understand the art and science of programming and they're just reading a checklist of skills handed down from someone pushed into giving HR a checklist.
Why? Because when you're given a task are you solving the problem or the language? It's all about patterns and algorithms and the thought process not the implementation. Beyond a certain base level of familiarity and experience, honestly can you say that someone who "knows" Java won't be able to solve the problem in C# given Visual Studio and Google?
I say give me a problem and ask me to solve it how I will. Get the people who are good at solving problems and train them in the tools of your choice (and that won't take long) or let them use the tools of their choice.
Bonus edit: plus, hiring for a given language today is going to bite you later if you're not hiring people capable of changing to your language platform of choice tomorrow.
If you're hiring professionals on a specific technology, then it's not bad to ask detailed, even syntactical questions. However, if you're hiring a "general developer," it's not a very good idea.
However, I think it's OK to ask him or her about the language they are most experienced in to see if they really have in depth knowledge about what they have worked with (and not just pretending they know something). The keyword was worked of course, not what you want them to work on.
I prefer not to ask things that a good IDE will fix or that you can look up easily. I do think that concepts are very important -- that is, I'm less concerned if someone knows C# or Java, but it is important to me that they understand OOP. I might ask them to define encapsulation or coupling/cohesion. For a more senior person, I might ask about reflection or have them sketch an architecture for a fictitious application.
I do typically have a coding problem, but I let them choose their language of choice. I specifically tell them that I'm not too concerned about syntax or remembering the exact framework names. Usually I just have them write it in an editor since different people are familiar with different IDEs, this levels the playing field somewhat.
Understanding basic database concepts is also a must for us. Knowing how to join two tables -- both inner and outer joins. I might ask them to design a schema for a simple problem to see if they understand normalization. More senior folks should be able to tell me where to create indexes to improve performance and define constraints, views, etc. as needed.
The thing I'm most concerned with is whether someone has the intellectual background, conceptual tools, and communication skills to be successful. Language idioms and framework details can be learned.
As someone who has done a lot of interviewing, you would be surprised at how many people can't answer simple syntax questions in the languages they say they know. These questions are used to filter out people. Are they valid questions? Of course they are, the interviewer wants to know if you really know what you are claiming to know. Now the idea usually isn't to ask tricky stuff in these kinds of questions but stuff you expect the person would know without having to look it up. I wouldn't hire someone to program a database who didn't know the differnce between an inner join or a left join for instance. They simply don't have the knowledge I consider a bare minimum to do the work.
When interviewers ask the tricky questions, they are probably doing one of several things, often this is a stress test to see how you handle yourself when you don't know the answer. Or if you are hiring for a truly senior level position, you might expect that level of knowledge. If I'm hiring for a job that requires high level skills, I expect them to be able to handle those types of questions. As a business, I'm not going to hire people I have a train at a senior level. If I'm paying more, I expect more knowledge. And nothing says that telling someone how you would find the answer wouldn't be exactly the right way to answer a question when you don't know the technical answer. Maybe I'm asking it to get an idea of your research methodology.
Somewhat subjective; in general specific syntax is not key to good interviewing. Good engineers sort of transcend issues of syntax and language specifics. The tools change over time and it's more important to understand the fundamentals and know how to learn and adapt than it is to know the specifics.
It goes without saying that one must know some syntax to be able to work, though, and I don't think fluency in one or more languages should be overlooked. When I interview people, I do make them write code, but the trick is that I don't care what language they use. I want to see them solve a problem, and write real code, with real syntax. People who write code for a living should be able to write some code that is close to functioning on the spot. They don't need to remember a specific API interface, but if you can't write primitive functions, pass arguments for basic types/structures, and aren't familiar with the "core" of a language's features (any language!), there's a problem.
Occasionally this is a bit fun, because they happen to be especially talented at a language with which the interviewer is unfamiliar. I've only had this happen a few times, but it wasn't an impediment to understanding what the candidate was doing. If anything, it makes it more interesting because you can ask them to explain how the language works, and see how well they do at that. More often than not, though, it's self-apparent.
All of that said, I agree that a candidate needs to understand pointers. And, for that, I think everybody needs to understand at least enough C to write or understand a basic buffer/string manipulation function. If they don't, I'm going to be scared what they're doing when working with higher level abstractions.