Before actively looking for my second job, I really had no idea how to interview folks effectively. After going through the process many times over the last month, I've come to the conclusion that there were essentially 3 good ways to evaluate me:
1) Give me a take home problem.
Granted, a couple of the companies that gave me these problems clearly didn't know how to interpret what I gave back to them. One of the comments I got back actually offered as a criticism that my code looked "too sparse." But if you actually have the ability to make sound judgments, this seems to me to be the ideal way to judge a candidate.
No one is coding over the phone (ever) or with someone watching over their shoulder even most of the time, so if you reject someone just because they can't perform under such pressure, you're going to have a lot of false negatives.
2) Ask a breadth of questions.
One of the other interviews which I excelled at was a series of 20 questions that asked me about things ranging from what happens when a browser makes a request to a server, to what a CDN was, to what the difference between UDP and TCP was. This was only a small part of the range of what was asked, but the fact that I was able to speak with confidence on most of the issues showed that I had a strong foundation of knowledge. They also asked my confidence in each area before asking me the questions, which I imagine helped them gauge whether I was down to earth enough to even recognize the things I didn't know.
3) Ask a depth question.
Drill down deep into a specific problem that the interviewee seems comfortable enough in. For this one, it could be entirely theoretical, such as how one might build a particular system to solve a problem. The key is that you want to dig into why they make any particular choice along the way.
You should look for someone willing to say "I don't know about X, I'd probably look for the reference to learn if there's a data structure to solve Y" if you end up getting too deep. That being said, not all personalities will understand that this is okay during an interview, as by the same token, a selection of interviewers won't understand that this is a sign of strength, not weakness.
1) Give me a take home problem.
Granted, a couple of the companies that gave me these problems clearly didn't know how to interpret what I gave back to them. One of the comments I got back actually offered as a criticism that my code looked "too sparse." But if you actually have the ability to make sound judgments, this seems to me to be the ideal way to judge a candidate.
No one is coding over the phone (ever) or with someone watching over their shoulder even most of the time, so if you reject someone just because they can't perform under such pressure, you're going to have a lot of false negatives.
2) Ask a breadth of questions.
One of the other interviews which I excelled at was a series of 20 questions that asked me about things ranging from what happens when a browser makes a request to a server, to what a CDN was, to what the difference between UDP and TCP was. This was only a small part of the range of what was asked, but the fact that I was able to speak with confidence on most of the issues showed that I had a strong foundation of knowledge. They also asked my confidence in each area before asking me the questions, which I imagine helped them gauge whether I was down to earth enough to even recognize the things I didn't know.
3) Ask a depth question.
Drill down deep into a specific problem that the interviewee seems comfortable enough in. For this one, it could be entirely theoretical, such as how one might build a particular system to solve a problem. The key is that you want to dig into why they make any particular choice along the way.
You should look for someone willing to say "I don't know about X, I'd probably look for the reference to learn if there's a data structure to solve Y" if you end up getting too deep. That being said, not all personalities will understand that this is okay during an interview, as by the same token, a selection of interviewers won't understand that this is a sign of strength, not weakness.