At this point, you’ve already nailed the constraints of a problem, iterated on a few ideas, evaluated their complexities and eventually picked the one you’re going to implement. This is a great place to be!

We see many people who jump straight into coding, ignoring all previous steps. This is bad in real life, and it’s bad when done at your interview. Never, ever jump straight into coding before having thought about and discussed constraints, ideas and complexities with your interviewer.

Now that we took that out of our system, let’s focus on how you code at the interview.

The one thing about coding (other than rushing into it too quickly) that many people struggle with is that coding in your IDE is not the same as coding on a whiteboard / a shared document / using some online system (in short: “outside your IDE”). As engineers, we’ve become so accustomed to relying on our IDEs (which is not bad), that when presented with a blank sheet of paper, we are lost. While this may have been OK at your day job, at an interview it simply doesn’t work.

This is why you need special preparation for “interview coding”. Say hello to the big juicy “Code” section of the Canvas, waiting to be filled in. At first it may be a bit tedious to write your code on paper, but very quickly you get used to it and you become more efficient. And the great news is that being able to code on a sheet of paper will not only boost your interviewing skills - it will also make you a better engineer overall.

Some of the key things to keep in mind when coding outside your IDE:

• Think before you code. Especially if you’re coding on a sheet of paper (where there’s no “undo”), if you’re not careful everything could become very messy very quickly
• Coding outside of an IDE does not give you permission to stop abiding by good code style. Make sure you name your variables properly, indent nicely, write clean code, etc. etc.
• It’s even more important to decompose your code into small logical pieces and NOT copy-paste
• Read your code multiple times before you claim it’s ready. You don’t have the luxury to compile, see if it compiles, run, see if it runs, and then debug for 4 hours. Your code needs to work off the bat.

That’s it. Now say goodbye to your IDE for a while, and off to practicing!

Example

Let's apply what we have learned to our ZigZag problem. Remember - do not use your IDE.

Summary

In this section you learned:

• When should you start coding at the interview?
• Coding for an interview is not like coding in your IDE. How can you prepare for that best?
• Look at important tips for how to write the code. We also write the code for an example problem.

What's next?

Let's wrap up the essential steps of a tech interview with a very important one - testing. You can never be 100% sure that your solution is correct unless you run it through some tests. Doing that has multiple positive effects at an interview. See how to test your solutions.