> You’ll need at least one question per language that you want to allow people to interview in. ... “Was this performance poor because they’re bad at debugging, or just unfamiliar with this language’s tools?”
Not necessarily a con. Different languages/tech stacks have very different tools. I.e. debugging a GC issue is different than debugging a network issue is different than debugging an embedded issue. If you chose a language for a very good reason, then it's not a con to filter out those who aren't familiar with that language enough to debug an issue in it
> If you chose a language for a very good reason, then it's not a con to filter out those who aren't familiar with that language enough to debug an issue in it
The language is based on/chosen by the candidate. We want to map the candidate to whatever language in our repository of "this question in different langs" is closest, to control for the candidate's familiarity as much as possible.
If you're screening to only candidates who can code in the language your company primarily works with, you're missing good candidates. The best are going to be able to pick up a new language rapidly, particularly if your language is a mainstream one that's probably imperative or OO-ish, or both; adding a non-esoteric language to one's repertoire is just not that hard a thing to do. But in the interview, I don't want them struggling with syntactic bull, as it's not a useful signal; I want to know how they think, whether they've seen code before, and can they reason from problem statement to debugged bug.
> If you're screening to only candidates who can code in the language your company primarily works with, you're missing good candidates.
I agree with that. I work somewhere that uses a lot of OCaml, we don't screen out those who don't know OCaml, but it usually helps them, since static analysis is easier with an ML family language than say, javascript.
> We want to map the candidate to whatever language in our repository of "this question in different langs" is closest
If there's not a close language in any of your repositories for the candidate, then I think that's a good signal that candidate may not be a great fit. As mentioned before, we don't necessarily ask candidates to write OCaml, most functional languages will have a similar bug + fix.
> problem statement to debugged bug
what if the problem you might normally run into is perf issues related to the language? I.e. HFTs usually use C++ and perf = $$$. I would agree that yes, those who have worked on say Rust could be good candidates, but if someone has years of experience in writing highly performant C++, and that's what the job requires, probably easier to look for those candidates.
I definitely agree with you in general, just pointing out that there are times where being familiar with the language used is desirable.
Not necessarily a con. Different languages/tech stacks have very different tools. I.e. debugging a GC issue is different than debugging a network issue is different than debugging an embedded issue. If you chose a language for a very good reason, then it's not a con to filter out those who aren't familiar with that language enough to debug an issue in it