Ask the candidate to solve some programming problem, perhaps one from a standard book of such questions, like Cracking the Coding Interview, or perhaps something simpler. These questions can be done either as a take home exercise, with or without a time limit, or while the interviewer(s) watch.
You can. But make it simple and not necessarily something that can be learned by heart form the internet, like FizzBuzz. I've used that, but I've often asked for a factorial function, both with recursion and without. You would be surprised how many can solve the recursion one because they saw it in various interview questions, without actually knowing how it works, and fail miserably on writing a simple
Don't look for syntax, or lacking semicolons, or things like that. Look for having a solution written down on paper that then can be explained by the candidate. Even if they mess it up in the code itself, if the reasoning is the correct one, and they can explain what is supposed to happen at each step (like how the stack grows and shrinks for the recursive one), then that gets them points.
Ask the candidate several short knowledge/intelligence testing questions. I've seen mentions of asking the candidate to respond to I.Q. test questions, generic brain teasers, Fermi estimation questions, or hypothetical scenarios like "What would you do if you were shrunk to size of a nickel and put into a blender?". Or perhaps just asking the candidate to regurgitate technical facts about one or more relevant technologies.
HR has this knee jerk reaction of asking for IQ tests. Sometimes they work, sometimes they fail. I wouldn't bother.
Definitely don't do crap like "What would you do if you were shrunk to size of a nickel and put into a blender?" How is this relevant? Does the job require being transformed into a nickel and being thrown in a blender? Stop this. This was "fancy" invented by "fancy" companies to look "fancy" and even those companies gave it up eventually, because although interesting to learn about some responses from candidates, they don't actually prove anything.
If you want this sort of questions, do logical brainteasers. These are basically short problems with a given set of initial information that you need to reason through, come up with a solution, apply it and get the answer. One, single, correct answer. Not imagining how coins feel in blenders and putting that into any combination of words.
Software developers need to be problem solvers, first and foremost. These sorts of logic brainteasers show those problem solving skills. Even if they get it wrong, again, you can discuss how they went about it and if the reasoning is the correct one, then that gets them points.
Ask the candidate to informally describe a previous project they worked on. Variants on this include asking about the most difficult project they had worked on, their favourite project, or to ask about a particular part of a given project. The book Peopleware recommends a particular variation on this called an Audition, where the candidate is told ahead of time to prepare a 10 - 15 minute presentation on a relevant topic of the candidates choice, to be presented to a small audience of the candidates potential new coworkers. The audience and the hiring manager then have a debriefing about the presentation and the candidate.
This can raise red flags. Do I need to come to the interview with PowerPoint slides besides a copy of my CV? Don't do this!
Definitely ask about previous projects, what they found challenging, what they liked, what they didn't like, why not, or how they solved things. Discuss that. Be curious. Be engaging. Don't just sit there like corporate drones staring at a presentation while the audience (your words) probably check their phones for messages and emails at the same time.
Another possible option is an unstructured interview, where the interviewer(s) just wing it, and more or less see how well they get along with the candidate. As the sole portion of an interview, this probably only works, to the extent it works at all, with experienced interviewers. But adding some time like this into an interview with a structured portion seems much easier to justify.
Never do unstructured interviews. Never.
Go in prepared. Have a list of topics, and things you want to ask about (see my last point in the answer below). Go through the topics with the candidate.
You obviously need to also evaluate "for fit" and see how you get along with the candidate, but this should be one part of the interview, not how the entire interview will unfold.
Have structure in place for the interview and try to stick to it, otherwise you risk going into some tangent that then consumes your entire interview time, and then you need to make a decision to hire or not based on some discussion that might have been interesting but not fully relevant.
For example, one interviewer with a strong technical background can focus on evaluating the candidates technical skills, and another interviewer can focus on evaluating the candidates soft-skills.
This is a good idea. You can do this. But agree before the interview what the roles will be and who will ask what questions, just so the interview goes smoothy, or you'll make the candidate feel like attending a tennis match and switch their attention from one interviewer to the other all of the time. Again... structure.
But it seems to me that there would probably be some aspects that would be common across most scenarios, and/or a general set of things to consider when choosing a process for a particular scenario.
Unfortunately, the most common scenario I've seen is for companies to not pay enough attention on the preparation of the interview itself.
Most of the times it's sending in the wrong people to conduct the interview, without preparation, or people without a plan that then just "wing it".
And the second issue, is that HR has this expectation that the candidate needs a CV tailored for their job posting and company for example (I've seen some HR personnel actually complain when that's not the case). This basically means that the expectation from companies is that a candidate should potentially build 10, 20, 30 specific CVs, depending on how many job applications the candidate might go after, because that's what it adds up to when you look from the lens of the candidate, not that of the company.
But you know what the companies themselves do in this regard? They use generic hiring processes without actually customizing the interview for the actual job position that needs to be filled.
So the last point, and the most important one, is to ask things that are relevant for the job. Spend some time to figure out what skills or knowledge is needed for the job you are trying to fill, and create questions or look for things that are actually relevant and important for that job requirement. Then ask and look for these at the interview with candidates.