- Your resume sucks
- You don’t have a portfolio
- You’re not getting a referral
- You don’t know how to tell a story
- Your technical skills aren’t up to par
Phew! If you made it this far give yourself a nice pat on the back. That was a lot of information to digest!
This last part is the hardest to implement yet most straightforward. At some point you’re going to have to prove that you have the chops to do the job. Unfortunately what that means depends on the size / style of the company.
There isn’t a one size fits all interview for every company. Most interview styles will fall into one of the following buckets:
- Algorithmic / Whiteboarding
- Take home projects
- Pair programming
Algorithmic
This is pretty straightforward. There are a billion+ resources on how to prepare for one of these interviews, so I won’t belabor the point very much. Chances are if you have an interview with a large tech firm they will share these resources with you as well. Google “Coding Interviews” and you’ll see recommendations for a litany of books.
Take home projects
This style of interview generally gets mixed reviews. I hate them. They generally mean that you have to do a lot of extra coding work outside of normal work hours.
If I can, I tend to avoid these like the plague as they are hard to prepare for. They also interrupt your normal work schedule and need a significant time investment.
For Algorithmic interviews you go through many screens before going to an onsite. That usually means 1-2 hours max before having to spend a full day interviewing. By juxtaposition a take home project can take up to 10+ hours. So you’re committing to the same time spent on a full interview loop. IMO this style of interviewing is a nightmare, and the opportunity cost is way too high.
Pair programming
This is a pretty loose designation. Pair programming can crop up in many forms. It all depends on the style of interview the team wants to deliver to you, but when they work our they are fun. The most standout interview I ever had of this sort was one where I was presented with a prompt in a language I was not familiar with. We spent the interview debugging, and solving problems in the codebase as if we worked together, and I loved every moment of it.
At the end we talked through the steps needed to take to fix the problem (it involved using a Heap data-structure / priority queue). The whole experience felt very collaborative, and even though I didn’t get the job in the end it left a very positive impression.
Yes We’re Talking About Practice…
Practice, practice, practice. That’s what most of this boils down to. In an upcoming post I’ll list some of my resources for problem solving practice (not just interview preparation).