I have done a lot of technical interviews. And mainly I think that interviewers have to change, but I do have some suggestions for interviewees. Ages ago I wrote up my prep list for interviewing at The Conglomerate, which is comprehensive, and frankly excessive. This is the short version with the benefit of spending more time on the other side of it. It’s targeted somewhat more at algorithms and data-structures interviews which are the ones that I think people are most afraid of.

1. Be Calm

I can’t tell you what to do here – you need a degree of self-awareness to figure out what will make you stressed and what will make you feel in control. For me, I need to know what to expect and feel like I have prepared enough to do it.

As an interviewer, I’m always working to make someone feel calm and in control. But you can’t necessarily tell if someone is freaking out (especially if that freaking out ends up coming across as arrogance). And this is a lot of work, that sometimes results in the interview going over time, or me concluding some fraction of it was not a good signal. It’s much easier for everyone if you don’t freak out in the first place. So determine what you need: information? Time? And ask for it. Most places want you to be successful and will be happy to give it to you.

2. Choose Your Language Carefully

Worry less about what will “impress” your interviewer and more about what you feel comfortable in. Then modulo that with the kindness of the language. E.g. if you love C, but are pretty happy in Python, I would suggest choosing Python, because there is a bunch of useful stuff in Python, and you just need to write fewer lines of code to achieve the same thing.

If you are interviewing for a platform specific job, at some point in the process you should expect to demonstrate you can be effective on that platform. And obviously many interviewers are bad, and some are setting secret tests (such as programming language) by which they judge people. However, when I say “code in whatever language you like”, I mean it.

One note on languages that have a lot of magic in them – like Ruby – you can easily end up writing code that you can’t reason about the efficiency of because it’s doing a bunch of things for you and you don’t know what. Anything you write with magic, you should be able to write without magic, and so understand the magic enough to know how you might do that – and when you might want to.

3. Know Your Foundation Blocks

The algorithms and data-structures covered in interviews is essentially second year Computer Science curriculum. Data-structures at least, are building blocks for everything we use – it’s worth understanding what their properties are and when to use them. I think array / list / hashtable / binary tree are probably sufficient.

Algorithms are like… the history of how we learned to solve problems and manipulate data efficiently. As computers become more powerful, it might seem less pressing but it’s still relevant, and still worth knowing. I don’t think you need to be able to re-implement them on demand, but knowing which is which and understanding trade-offs is good. Aside from sorting, binary search, and the basics of runtime analysis (basically: how long will it take proportional to the input?) are useful.