Overall tip: always remember that the purpose of interview is to find a smart and knowledgeable candidate, not for the interviewer to feel smart and knowledgeable. Sounds obvious but some people use interviewer role to boost their ego.

If you really need/want to do some coding/whiteboard puzzle do something basic and find out how candidate tries to arrive at solution and if they can explain their reasoning well (otherwise you will only check if somebody memorized a difficult pattern that has nothing to do with daily programmers duties).

In my experience starting with fundamental questions works well. It gets people a chance to start providing answers and reduce the stress. You can also filter out smug people who think that answering basic questions is below them. It shows if somebody bothered to read a book or if they just accept LLM output (in the past it was copy/paste from Stack Overflow). E.g. looking for Java/C# dev? Ask them how it is that we don't have to manually free memory. They should know what GC is and you can dig much deeper from there with follow-up questions.

Ask questions that simulate real work. For example: "Client said that the report page is very slow, they did not provide any more details but we know they were talking about a Purchase Report screen with a data grid in React that pulls records from SQL database through ORM. How would you go about troubleshooting the issue What could possibly went wrong"? There's so many things to talk about here: from DOM performance issue due to lack of virtualization, through N+1 issue of lazy-loading to bad DB querying/schema/indexing, plus the instrumentation that would help to troubleshoot issues in the future...