#1 is good, but I’d suggest always using the same set of questions to have a good baseline against which you can compare candidates.
#2 I have mixed feelings about. it may make sense if you’re after an expert on that language but may evaluate wrongly candidates that would be great reading code once they get just a bit more familiar with and get the overall architecture. In many companies, you’d be forbidden from sharing actual code with non employees, so the excerpt shown in the interview would have to be purposely crafted and loose value.
I propose a more interesting exercise could be to examine a random piece of opensource that Both the interviewer and interviewee are unfamiliar with and trying to get a good discussion from it, but it’s a risky move leaving the interviewer exposed.
#2 I have mixed feelings about. it may make sense if you’re after an expert on that language but may evaluate wrongly candidates that would be great reading code once they get just a bit more familiar with and get the overall architecture. In many companies, you’d be forbidden from sharing actual code with non employees, so the excerpt shown in the interview would have to be purposely crafted and loose value. I propose a more interesting exercise could be to examine a random piece of opensource that Both the interviewer and interviewee are unfamiliar with and trying to get a good discussion from it, but it’s a risky move leaving the interviewer exposed.