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:
That’s it. Now say goodbye to your IDE for a while, and off to practicing!
Let's apply what we have learned to our ZigZag problem. Remember - do not use your IDE.
In this section you learned:
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.