Fourth, augment your answer. Answer the question and then some. Here’s a very useful exercise if you have never done this. Put yourself in the position of the interviewer. Pretend you have 30 minutes to give a phone screen on C++ and programming skills. What topics do you cover? You can’t possibly cover everything, so you have to prioritize. Try making a list of things that you think are important. Then cut the list down until you have maybe 6-10 things. Now come to the phone screen with your list in hand and try to make sure that you say something about each of your points somewhere in the phone screen. Now, of course, you can’t just launch into a random tangent after a totally unrelated question, but the idea is that your list and the interviewer’s list should have significant overlap (otherwise, if the skills you think are necessary and the skills the interviewer thinks are necessary are vastly different, the job is probably not a good match anyway). Therefore, when the interviewer asks a seemingly “random” question, you’ll be able to see which of the underlying points he is aiming at and you can beat him to the punch.
Another personal example, here. One of the questions I had in an on-site interview was to write some bit counting code and then optimize it. This being my very first on-site interview, I might have been a little obtuse, but when the interviewer asked some general question like, “why did you only use 16 entries for that table? Why not use 1024 or 10 million?” I wasn’t sure what he was getting at. It just seemed like a dumb question. Of course you’re not going hard-code a static 10 million entry table in your program – that’s stupid, what kind of question is this? What the interviewer really wanted to hear was a description of the memory hierarchy – L1, L2 cache and main memory and how performance would take a nose dive after you exhaust those caches. My frustration was that I’m well aware of the memory hierarchy and cache design issues (set associativity, aliasing, cache-line alignment for performance, etc, etc…) but I really messed up that question. Had I come with a mental checklist of things that I thought were important to the job, cache issues and cpu architecture would be at the top and I would have made sure to communicate that somewhere. I could have seen that in the question right away. So don’t make the same mistake. Come with a list. Make it a two-way street. The interviewer is trying to “pull” out what you know, so make sure to “push” out what you know.
Fifth, impressions do count. Rarely does a candidate just nail every single question and answer everything perfectly, so then, like it or not, it does come down to weighing the good and bad – “well, he did well on my data structures questions, but I don’t think he really understands threading, …” This is where the subjective part comes in. For a candidate that I like, I might be more forgiving of the things that he doesn’t know. For a candidate that I don’t like, I’m less forgiving. Shocking, but that’s human nature. Of course, that’s within limits. If the candidate totally bombed the interview, it doesn’t matter how much I like him, he’s not going to pass. And if a candidate answers every question perfectly, I’ll pass him even if I didn’t like his attitude. (The idea being we can evaluate again in an on-site interview with other interviewers). In terms of attitude, basically it comes down to not being cocky, arrogant and dismissive and instead showing genuine enthusiasm and eagerness and being gracious with the interviewer on questions that you think are bad (all interviewers ask bad questions occasionally). Hopefully common sense, but too often candidates seem very stiff and even slightly defensive.
Finally, be sure to follow-up at the end. The interviewer may not offer you a chance. This may be intentional. When I’m going to fail a candidate (and I know as soon as the screen is over), I might just say, “well, it was nice talking with you … ” Most candidates don’t ask about follow-up. They just say, “OK” and we hang up. I’ve had a couple candidates ask me straight out if they passed or not right at the end. This puts the interviewer in a slightly awkward position if they are failing as I hate to say right out, “no, you failed.” If the candidate is passing, I have no problem telling him so on the phone and explaining the next steps. You should know the status of the phone screen by the end. If you don’t, ask what the next steps are. You can get a pretty good read by how the interviewer responds whether you passed or not. (Basically, if he doesn’t tell you right away that you passed, you probably failed).