# The actual interview

It feels a little weird to separate this out into it's own section but couldn't figure a better place to do it so here it goes.

## Coding on a whiteboard (generally for on-site)

When coding a whiteboard, it's easy to glaze over things but it is definitely worth practicing on a real whiteboard. If you have a friend who can let you into their office to practice in a room with a whiteboard, take advantage of it. If you have none, pencil/paper is the next best thing and practice length wise.

### Some tips

* Before you start coding, write down test input you'll want to try somewhere in the right corner so you know to keep it in mind but it won't get in the way
* Before you start coding, in words talk with your interviewer about the thought process of how you will tackle the problem. You could start writing the function signature if you want but the investment of just thinking through the pseudo code will help you code faster.
* Write small and start at the top left with extra space in between lines. You more likely than not will need to add stuff and it helps to have some space reserved
* If you find yourself getting overwhelmed with a lot of the problem, break the problem up. Functions are very useful for this -- break up the logic so that you aren't tackling everything and feel free to defer things for later. It helps to have an idea of what the interviewer might be evaluating you on
  - Example: You have a question where you have to search for a tile on a grid/2D array and part of the problem involves looking at adjacent tiles around the tile. Naturally if you are at the edge of the grid, you'll want to make sure you aren't returning adjacents that are out of bounds. This can be broken up and deferred later (it's busy work and most likely isn't the core problem the interviewer is testing you on)
  - If you find yourself needing to write helper functions, don't do it under your code -- go from left to right and start high. You don't necessarily know how LONG your function will be but you can at least column them. Once you finish a function, feel free to write under then
* Be smart about naming variables but don't be too verbose. Those things are trivial but most important is you write something that is clear and will help you keep track of what's going on
* If tackling data structure questions, it helps to have a visualization to step through as you code. So if you're traversing a tree, draw out a tree and walk yourself through it. It also shows the interviewer more of how you think and how they should be thinking about the problem
  - The sad truth is, if they don't understand how your answer solves the problem, even if it does, it's a penalty on you and not them
* Don't think brute force is a bad solution unless the interviewer says so -- even showing that you know how to get a brute force solution working and commenting on where the bottle necks are is good and some problems don't have a more optimal solution.

## Coding on a computer (generally for phone screens)

Many frontend interviews will use some sort of repl or coding environment to test you, especially for the phone interview. Some really common ones include:

* Coderpad
* Codepen.io
* jsFiddle
* Skype Interviews
* HackerRank

It's important you are familiar with the one you'll be tested on. Usually the calendar invite will have a pre-made link.

Coderpad for example has a [whole section on JavaScript](https://coderpad.io/languages#javascript), how to write tests, use jsdom, etc and also on [HTML/CSS](https://coderpad.io/languages#html)

While all of these have some autocompletion or templates you can use, assume you may not be able to use them. Google for example tests people in Google Docs so
don't think it's a guarantee you'll be able to depend on IDE functionality.

Familiarize yourself with what language specific features you use. ES6 for example isn't necessarily supported and you'll need to use Babel or check if
the [Node enivronment you are on supports ES6](https://node.green/).