Most people think technical interviews are terrible. The proposed remedies you'll find are all over the map and often contradictory. This outlines how I think about and manage the process. I went through this many times as VP of Engineering at Tune and my methodology led to great hires.
This flow is specifically for software engineers. I use different techniques for managers and other roles.
Top of the Funnel
New hiring managers often propose all sorts of obstacles for candidates to jump through. I remember a "Who's Hiring" on Hacker News listing: take home project, phone screen #1, phone screen #2, full day on-site technical interviews, culture-fit interview, personality test, and then just a provisional employment offer to start. That is batshit crazy.
The Googles and Facebooks have the prestige and compensation packages to get away with this. Almost everybody else does not. The people you really want are scarce and always in high-demand. You're competing against a sea of other employers trying to snag them.
Take-home tests are useful if it's unclear from the resume whether you should bring them in or not. In lieu of passing them by, offer a straightforward coding project. Be respectful. The project should not take more than 2 or 3 hours to complete. If the candidate puts in the work of implementing a reasonable solution, give them the benefit of the doubt and courtesy of an onsite interview.
For the great looking candidates, skip the test and bring them in.
Onsite - Philosophy
Most engineers go years between doing interviews. They are understandably often nervous. The interview room is an utterly alien environment compared to what real development work is like.
As an interviewer, try to get the candidate to relax. Be friendly, not confrontational. Your job is to get this candidate to shine and succeed as much as they're able to. Ideally a candidate walks away from the interview feeling good about the company, even if they know they're not getting hired.
Be mindful that you are limited in what you can discover via an interview process. There are both time constraints and you're not observing what the candidate is actually like as an on-boarded developer. You will inevitably reject some phenomenal developers and make offers to people who don't work out. Don't live in terror of the latter case. If you are losing sleep over it, your performance management strategy needs work.
Every session is also a chance for you to improve as an interviewer. Even if the candidate has become a 'no', keep putting in your full effort and attention.
Lastly, I think it's obvious but still worth saying. Be respectful. Pay attention. Don't play with your phone or work on your laptop. Don't be late.
Onsite - Implementation
My onsites start with a quick five minute tour of the office and then a single round, ninety minute interview. (That may be mind-blowing to folks insisting on day-long, multi-round battle royales).
The office tour should show the actual work area for engineers. That way, any concerns (e.g. an open office) can be addressed during the interview. This is also a good time to offer a bathroom break and a beverage before the real fun begins.
In the interview, after initial introductions, I start with "tell me a bit about yourself". I leave that open-ended on purpose. The goal here is just to get the conversation going. Near the end, I ask for some details on the last few positions they've held and what specific projects they worked on.
Next up is the design portion. The candidate must explain the design of a system they worked on recently, using the whiteboard, as if I were a new hire about to work on that system. I make clear that the goal of this exercise is to see how they communicate technical concepts. They can choose any project they like. They're free to choose a high-level overview or to zoom in on specific components and interactions.
By letting the candidate pick the system under discussion, they operate from familiar territory which makes things less nerve-wracking. Ask them which parts specifically they contributed to. Ask operational and design questions. "What part tended to break?". "What would you change if rebuilding it from scratch?". "How did you monitor the system?". "Why did you choose A instead of B?".
This gives you a good feel for the candidate's big-picture understanding and the magnitude of their own contributions. It gives some impression of how well they can communicate technical concepts. (A great explanation is a good sign, but a mediocre one is not necessarily a deal breaker).
Next up is the coding portion. I clearly state that I don't ask trick questions, that I don't care about minor syntax errors, and that they can pick any language they like provided I can understand it.
In the real world, developers don't write code on whiteboards while others sit silently staring and judging. This goes back to the limits of what you can actually discover in an interview process. The goal is to pose a question which is sufficient (a bit tougher than fizz buzz) to weed out the Billy-can't-code candidate, simple enough to keep nervousness away, yet interesting enough to lead to follow-on questions.
I usually pose a fairly simple problem involving recursion. Be mindful that this can be far away from what candidates normally do. Someone working on CRUD apps for a living probably doesn't touch recursion at all in their daily life. Your mission as an interviewer is to get the candidate to successfully solve the problem. Be liberal with tips. In the most extreme cases you'll have to hand-hold almost the entire way through the solution.
My favorite coding problem leads naturally to a series of follow-on questions, including one which involves envelope-estimation. My estimation question is nice because it's fundamental, far from what programmers normally think about, and solving it provides an interesting insight on the recursion question. Again, it's about getting the candidate to success.
Finally, in the last ten minutes or so, I tell the candidate that it's now their turn to ask questions. "Ask whatever you want". This part is critical. Interviewing is like dating; both sides need to be wooed. So far you've been judging them. Now they are going to be judging you. Great answers here often make the difference between a candidate accepting or passing on an offer.
This open question time is also why it's critical to give your full effort to candidates who become a 'no' early in the interview. Their questions give you a chance to practice your answers. Learn how to sell the position and the company! When that 'yes' comes along, you will be ready.
Afterwards
Once the candidate has left, join up immediately with the other interviewers and decide 'yes' or 'no'. Be prompt on communication. Telephoning an offer later on the same day is ideal.
You may have to defer deciding when there's other candidates coming for the same position. Of course, the longer the wait, the more likely people will move on. One week is reasonable. Two weeks is pushing it. Don't go beyond that. Let candidates know how long it will be until a decision is made.
Be prompt and respectful with 'no's. A simple quick email suffices. If they hit a hiring 'yes' but lost out to a slightly better-fitting candidate, it's worth letting them know they were great and in the running. Your other candidate might still back out or a second position might open up. Don't burn bridges.