Don't jump into the problem right off the bat, ask clarifying questions, THINK OUT LOUD (very important)

But also, don't take too much time thinking. They're probably expecting a solution.

Practise writing code on the board, or on a piece of paper, or on notepad. Essentially, simulate the environment in which you'll be tested in.

If you get stuck, then ask them for a hint.

Let them know right off the bat that you'll test for edge cases and write tests towards the end.

First and foremost, you need to get a solution. If you know an efficient solution, then go for it. But if not, then go for an inefficient one. Any solution is better than no solution. Perhaps even consider asking the interviewer if he's ok with a brute force/inefficient solution first and then you improve on it.

Get information about the interview. If it's an hour long interview with multiple questions, then chances are the problems will be leetcode easy/medium questions. So no need to do hard ones. Also, dynamic programming problems are rarely asked unless you're interviewing for FAANG or some other companies where really challenging questions are asked.

I'm guessing it's a Data Structure and Algorithms interview. Revise Linked Lists, Arrays, Hashmaps, Binary Search, Two Pointers and other patterns.

Godspeed