A few of my thoughts:

• Measure what matters
  • What do you look for in an employee or what traits do your successful employees possess (dev.to/ryansmith/in-your-opinion-w...)? Are the canned questions "where do you see yourself in 5 years" or "why do you want to work here" really getting at those traits?
  • Ask open-ended questions that pertain to the traits you are looking for. Allow the candidate to explain their thoughts and converse with them. Closed-ended questions are frustrating and tend to disqualify someone, they have to know it or they cannot answer effectively or show their best qualities.
  • Is that obscure technical trivia going to make the difference between success and failure at your company? If yes, ask it. If no, don't ask it.
• Emulate work situations
  • There seems to be a lot of hate towards take-home assignments as giving the company "free work" but I think it can be done effectively if it isn't too daunting of a task. I think answering questions or doing a coding assignment outside of an interview is closer to how developers work on the job.
• Make parts of it asynchronous
  • Most communication is written in chat or via email. Design a hiring process with some of those elements to gauge how well they communicate. Not everyone is great at 1:1 or panel interviews, but they could be an exceptional candidate. If they do not have a chance to show it, your company may miss out.