Whiteboard with markers

Having interviewed, coached, and sat on hiring committees with many candidates during my three year tenure at Google, I’ve learned a lot about what works and what doesn’t. I conquered the interview process after failing once before and, even then, I thought it could’ve gone either way. With tons of stuff to study, it’s hard to figure out how to prepare. Even really smart people can fail if they don’t have a good plan for what to do when they get into the room with an actual software engineer and a whiteboard.

So, I’m going to share six tips I believe you absolutely need to nail your interview. After you check these out, watch this sample interview video conducted by Google engineers.

1. Repeat the question in your own words

As soon as you hear it, repeat it out loud. Do this preferably in your own words to demonstrate your comprehension. Remember, your interviewer is there to assist you, so repeating the question aloud will only serve to make their job (and yours) easier.

This will also buy you some time to think about what you’ve been asked and develop good questions or approaches. Plus, hearing yourself restate the problem might help you think through it more clearly.

2. Check assumptions

Many candidates start writing code almost immediately after hearing the question. This is a big mistake. Most coding questions have some level of ambiguity built in. Have at least two or three questions ready so that you can confirm you have all the necessary detail to solve the problem. You can also write out confirmed assumptions on the whiteboard (do it in small print to save space). Questions like “does input fit in memory?” or “can I assume input is always valid?” are good candidates if you can’t think of any at first.

3. Use real examples

You’ve got a whiteboard—use it! Draw out an example array, a binary tree, a linked list, etc. Give it real data and write out the expected output of a working solution. You should practice coming up with good examples as part of your study regime (you do have one, right?). Using a visual example also gives you opportunity to think up more questions and your interviewer a chance to correct your assumptions. Don’t forget to keep thinking out loud as you work through it.

If your interviewer provides examples, use those since they probably exist for a reason. This is also how interviewers will point you towards problems with your design or implementation.

4. Brainstorm solutions and their time/space complexity

Stop and think about various approaches. If you’ve put in time studying algorithms and data structures, this is where it really starts to pay off (Cracking the Coding Interview, anyone?). Think about trade offs using Big-O analysis and think out loud. Don’t stop with the first solution that comes to mind. Always ask yourself what’s the best you can do. Trust me, we always will!

Tips: Don’t forget the space–time tradeoff principle. Wanna go fast? Use more space. Also, hash tables people! And learn how to think graphs—including trees. If all else fails, recursion, backtracking, and memoization are useful tools on particularly difficult problems.

5. Write working code (no pseudo-code please!)

You might normally use pseudo-code to design your code, but you don’t have time for that in a 45-minute interview. Choose your strongest language and turn your thoughts into working code as quickly as possible. This should be the easiest part of the interview assuming you’ve put time into practicing without an IDE (seriously, don’t use an IDE to practice for the interview unless you’re compiling code you’ve already written out). Make sure to practice using a whiteboard or just use pen and paper.

6. Test your code, always

Now turn your brain into a compiler and execute each line of code to ensure you don’t have any logical bugs. Use the whiteboard to keep track of variable state as you iterate. Also, use the example(s) you created earlier and confirm that you get the expected output. Testing is crucial in software engineering, so never make the grave mistake of leaving this step out.

Practice makes perfect

It took nearly an hour and a half to finish a coding question when I first started using these six steps. After a month and a half of daily practice, I could solve most questions in about half an hour. Nothing takes the place of putting in the time to prepare for the interview until you’ve developed the muscle memory to execute these six steps perfectly. Is it worth it? I’d say so.

This post originally appeared on LinkedIn.