>Fix a real bug or implement a real feature. Beyond the obvious copyright issues if you don’t get an assignment from the candidate,
Irrelevant if you've already fixed or implemented it and do not intend to use the candidate's code.
>there’s no good way to make this process repeatable,
Select fixed bug/feature, isolate code, create question, use in interview, iterate on task.
>no way to ensure the question always fits the available time,
Other than selecting the question such that it does and/or tweaking it such that it takes more/less time.
>and no way to ensure you see a good range of programming skills (e.g. the feature may simply involve copy/pasting some existing code with minor tweaks).
Other than selecting the question such that it isn't that.
>It also assumes you’re hiring Java developers for a Java codebase or Ruby developers for a Ruby codebase
I'm certainly not going to hire ruby developers for a java code base or java developers for a ruby code base, and I find it weird to assume that I would.
> I'm certainly not going to hire ruby developers for a java code base or java developers for a ruby code base, and I find it weird to assume that I would.
Learning a programming language is usually not the hard part unless it follows a completely new paradigm that you are entirely unfamiliar with. E.g. programming in an object oriented language if you only ever have done imperative. I've interviewed people in languages they didn't know with great success, you just gotta ask the right questions and sometimes their questions (or lack of) are more important than their answers.
>Learning a programming language is usually not the hard part
The syntax and semantics can indeed be picked up in a day or more. It's working within the ecosystem and circumventing all of the non-obvious pitfalls, knowing the shortcuts (and knowing what can't be shortcut), knowing where all the important information is located that all requires years of experience.
I've worked with developers who have switched languages and they often port across bad habits and quirks and try to make the new language more like their "home" language. Sometimes years later they're still trying to do things in a non-optimal way.
I also think that most people are more productive in their favored language (or languages) and you're unlikely to get as good quality work if you pull them away from it.
There's also a cultural element to programming languages that I think is underrated. I don't expect java programmers to have the same kind of outlook or approach to python programmers.
You simply cannot be arguing that companies who need a developer to maintain a java code base should take special care to not consider candidates ability in java just in case they don’t know the language at all.
Yes learning a new programming language can be easy, so go do it before you apply for the job that’s looking for someone experienced in the language.
Irrelevant if you've already fixed or implemented it and do not intend to use the candidate's code.
>there’s no good way to make this process repeatable,
Select fixed bug/feature, isolate code, create question, use in interview, iterate on task.
>no way to ensure the question always fits the available time,
Other than selecting the question such that it does and/or tweaking it such that it takes more/less time.
>and no way to ensure you see a good range of programming skills (e.g. the feature may simply involve copy/pasting some existing code with minor tweaks).
Other than selecting the question such that it isn't that.
>It also assumes you’re hiring Java developers for a Java codebase or Ruby developers for a Ruby codebase
I'm certainly not going to hire ruby developers for a java code base or java developers for a ruby code base, and I find it weird to assume that I would.