Coding in an interview can be intimidating. It can often lead you to do things that you NEVER usually do (at great cost!). Here's a guide to tackling the coding interview to the best of your abilities.
Quickly scan the files
The first thing to do is scan the files you have available and understand which ones are helpful and which ones can be ignored for now. Typically you won't have time to read every single file in detail, so try to narrow down the important information. Normally, the important points are in the README.
Run the test suite
Before attempting to fix anything, run the test suite. Some tests might pass immediately, which is valuable information!
Use a whiteboard
Often, all of the detail will be in the README.md (or similar). Reading the text multiple times is a valid way to understand a problem, but an even better idea is to draw the problem and poke at some examples.
Typically, a coding challenge will involve some complicated logic OR they are looking for you to implement a solution that is more elegant than brute force. In both of these cases, drawing objects (strings / arrays / nested dicts / etc.) can help you tackle complicated logic, better understand the problem and think more clearly about potential solutions.
It's even better if you can isolate distinct resources to identify things that should be handled separately.
If the challenge is super complicated, you may spend most of your time on the whiteboard, but re-drawing a new solution is often quicker than re-writing the code.
You might even find that the interviewer is willing to clarify certain scenarios if you have explained them with an example (which can be helpful if the wording in the README is unclear).
Write the simplest code possible
Unlike the real world, where you probably want informative and useful objects like dataclasses or pydantic models, the goal here is to write the simplest code possible to solve the challenge. Once you solve the problem, it is very easy to discuss improvements such as validating inputs, making your code more robust and creating more ergonomic objects.
Write the shortest code possible to get to the next milestone. You may need to change the code later, or you may make better use of your time by whiteboarding better ideas. You can always iteratively improve your code once you have a working solution.
Write pseudocode
Before writing for loop logic or while loop logic, write some basic comments explaining what you are going to do and (if appropriate) why. This often helps structure your code, communicates your ideas concisely, and the interviewer might even jump in with valid concerns to prevent you going down the wrong path.
Brute force at first is fine
When tackling "leetcode-style" problems the interviewer is typically looking for an elegant solution. In the interest of "make it work, make it right, make it fast" it may be okay to first implement a brute force solution (if it doesn't involve much code) OR you aren't entirely certain about the elegant solution yet.
Read tests for complicated logic
Sometimes you can better understand the problem you are trying to solve by reading tests and checking the assertions. You WON'T have time to dig into every single test, but have a quick poke at any that handle the more complicated parts.
Comment out the code
You might be using tooling that is unfamiliar to you. For example, you might be using Python's unittest functionality despite the fact you're a ninja with pytest. One hack is to comment out things that aren't important to you when tackling individual problems. I wouldn't normally do this, as it can involve commenting out half of the codebase, but in an interview with limited code and unfamiliar tools this can be a very helpful trick to simplify your problem space.
Read the error logs
If you hit an error, take a moment to isolate it and read it properly. If the errors are long and confusing, copy/paste only the parts you care about.
Spend a moment identifying the exact problem. Find the filename and the line number. Narrow the problem as much as possible. Only use tools like the debugger (at the identified line) once you have truly run out of ideas.
Separate coding and discussion
Don't fall into the trap of trying to explain difficult things like time or memory complexity while also trying to reverse a binary tree. Get the code to the next milestone (fixing a test or finishing a function) before discussing more complex topics.