Trivia questions during a phone screen probably aren't as effective as you think. I used to be a big fan of coding trivia questions. Why would you have a virtual destructor? If you cross two normalized vectors is the result guaranteed to be normalized? You get the idea. Here's the thing: after phone screening literally hundreds of candidates, I found that my success rate in actually hiring competent people was quite low. Turns out knowing coding trivia does not guarantee the individual's ability to actually write good code. Point in fact, I frequently found that those individuals who could regurgitate the C++ coding standard usually didn't meet my goal of having programmers with sufficient practical knowledge that I could be very hands-off with them. Unless you're hiring candidates for Jeopardy, come up with a way of screening that really tells you if the individual's talents and skills map to the goals you have for that position.

Any problem that can be solved in 45 minutes or less isn't going to give you a good idea as to someone's ability to write solid code. I used to be very good at taking tests in college. This is because I understood that you only had a very limited amount of time, maybe 1-2 hours. Therefore the professor was very limited in what sort of problems they could ask and would focus on just the problems that were solvable in that time frame or less. In reality, they usually had to be problems that were solvable in 30 minutes or less so they could have several questions on the test. Cake! To get around this limitation, companies frequently add silly constraints to the problem to make it harder. In my experience, these constraints usually revolve around using a different coding technique then is typically used to solve this particular problem. Unless the candidate happens to know that specific technique already, they either have to make an intuitive leap or guess, instead of being able to logically deduce a good approach given the time limitations. Do you really want your engineers guessing at solutions? Maybe you do. I certainly don't think it's a recipe for success, but if that's what you want..... ;)

White board coding. Programmers write code at a computer with their favorite editor, a compiler and a debugger. Writing code on a white board is nothing like writing actual code and doesn't really show you how this particular candidate actually writes code to solve problems. Unless your company actually writes all of your code on a white board (I'm guessing not ;) ) and transcribes it into the computer, why oh why do we still interview people like this?

Silly logic problems. I understand the reasoning behind asking them, but do they truly measure someone's ability to solve real-world problems, especially when the candidate can't do any research to look for a solution? Is that how your normal development process works? I still remember one of my first interviews, it went something like this: How would you weigh a manhole cover? I'd put it on a scale. Ah ha! There are no scales. There are no scales? I think we have bigger issues than how much a manhole cover weighs. :-/ Seriously. Translate that into any regular conversation at your company. How are you going to implement this feature? Well first I'd look up if there are any discussions or examples online. Oh no! You can't look anything up! You must implement it from first principles in the next 45 minutes. Well I'd probably start with using the standard libraries. Oh and you can't use any standard libraries. If this is really your culture, great, I guess you've perfected your hiring process. Stop reading now.

Frequently, interviews end up feeling antagonistic. In my experience, this is because the interviewer is trying to "win" the interview by proving the candidate doesn't know what they're doing. Just stop this. Seriously. Crushing a candidate during an interview is trivially easy if you want to set things up with that as your goal. I've also seen plenty of interviews where the interviewer sat quietly and stared while the candidate squirmed. Is this what your culture is really like? Your real goal should be hiring a great candidate who actually wants to work with you.

Interviews are rarely collaborative. See above with giving candidates problems that rely on them knowing bits of trivia instead of core techniques. Because these types of problems involve knowing or intuiting (which people are rarely good at while under stress in an interview) some bit of ah-ha! knowledge, it is next to impossible to collaborate with the person without simply giving them the answer. You can't give them hints and see how they consider and apply them, or see if they ask good questions, or get any other insights into their thought process.

The atmosphere of many interviews can be very condescending towards or dismissive of the candidate, in a  "prove why we should let a peon like you work for our awesome company" kind of way. I recently did a technical screening where I was on video call. Their video feed was disabled, so they got to watch me while I got to see a blank screen. It's what I imagine being interviewed through a one way mirror is like. I can't say I recommend it. ;) My takeaway was that the company had a very us vs. them culture. Until you're one of "us", we don't want to interact with you. Is that how you want to present your culture? Especially if that isn't what your culture really is.