Interview Advice

I do a lot of interviewing these days and the most likely reason for anyone to bother looking me up is if they are going the extra mile on their interview prep.

So, for those people, I thought I'd offer some advice on interviewing.

  1. Practice Interviewing
    Interviewing is it's own skill. Just getting better at being a software engineer over time, will help but learning how to convince others of your skills is potentially going to be just as important (or possibly more important) for your career. So, take the time to learn it. The number one thing I recommend is interviewing at a lot of places, even if you're not interested in the jobs you are interviewing for. Then follow up the experience with some honest introspection, pick out where you could have improved, and move forward. It's rare that feedback is offered, but take people up on it when you can. Understand that even if you think their conclusions are incorrect, there might be something you can learn about making sure others don't draw those same conclusions.

  2. Cultivate Humility
    What you want to do in an interview is project both humility and competence. The best way to do that is to actually be competent and humble but it's okay to fake it until you make it. Project humility and do your best on the technical evaluations and let those speak for themselves.

  3. Listen to the Interviewer
    An interview is an opportunity to show your collaboration skills. Make sure you've understood what the interviewer is asking for. If you have questions, ask them. If you don't understand the answer to the question, ask for clarification.

  4. Ask Questions
    Don't be afraid to admit you don't know something. For instance, someone is asking how many cows are needed to feed the United States. Maybe you don't know the population of the United States? Ask! It's okay to not know things. In particular, pay attention to what assumptions you are making about the problem and ask the interviewer about them.

  5. Understand What the Interviewer is Looking For
    You need to know what the goal(s) of the exercise are. Are they going to want to see a working solution? Then don't spend the first half of the interview just talking - you need to get some code written. Are they looking for the most optimal solution or just anything that would work?

  6. Don't Stop Working on the Problem
    When you think you're done with the problem, tell the interviewer that you think you've got the solution but want to check it. And then turn a critical eye to your own work. Find your own bugs and fix them. When you think you've caught all of the low hanging fruit, ask your interviewer what they'd like you to do, something like: "I'm not sure if this is right yet, I'll start thinking through more test cases, but is there anything in particular you'd like me to focus on?"

  7. Understand Trade-Offs
    There is almost always going to be a trade-off involved in your solution. Be aware of the trade-offs and think critically about whether or not the ones you are making make sense.

  8. Don't Cling to a Poor Solution
    If your solution is getting more and more out of hand, it's possible that it's a poor solution. Generally, interviews are expected to take about an hour so if you can finish it quickly, go for it. If you don't like where it's headed, talk to the interviewer about it.