On Interviewing

Recently I made the decision to look at other opportunities and I completed a number of interview loops and many more phone screens and technical phone screens. I thought it might help others a bit to share some of the lessons I took away from what was more than 40 hours of technical interviewing. Due to NDAs there aren’t going to be any interview specifics here but some feedback and tips that I hope can be useful for both sides of the table.

As an interviewee-

  1. Have questions ready. Write them down if it will help them stick in your head. Now come up with more. Seriously. Do even more. Now come up with some you can ask every interviewer you meet. During one of the longer loops I completed every single person on the loop did great at leaving Q&A time. This meant they quickly burned through my specific questions about the company. I adapted to this by coming up with more questions that the interviewer could answer on a more personal level. Here’s a few of my favorites:
    • What is your favorite part of the role/team (if applicable) or company?
    • What is your least favorite part?
    • What is the biggest challenge the organization is facing today?
    • What can I do on my first day or in my first week to have a major impact for you (as my peer, manager, customer)?
    • Tell me (as much as you can) about how your team or org manages it’s technical debt.
  2. Bring copies of your resume. Even in this so-very-digital age of cloud-based HR and PDF resumes sometimes the person interviewing you hasn’t been given a copy or may not have looked at it yet. Your preparedness will pay off.
  3. Be polite and professional, of course, but don’t hold back being you. I had a great time chatting with one of my interviewers about technology we both found exciting even though it was a little off topic. It’s OK to talk about cases where your hobbies drove you to learn about something and you may find your interviewer shares your passion for motorcycles or video games. You may find that you end up spending a few minutes on that side topic but you’ll both leave the room smiling because you got to chat about something you really care about.
  4. Study. Do the tedious practice of refreshing yourself on algorithms you haven’t looked at in ages. Despite the fact that everyone in the room will know you’ll likely never need to worry about things like searching binary trees or sorting linked lists as a part of your work you will probably get asked anyway. Unfortunately that’s still common throughout the industry even though we all know it doesn’t really mean as much as we pretend it does. To that end:

 

As an interviewer-

  1. When it comes to the coding questions; have them solve something you’ve actually had to solve at work that can be finished in a reasonable time period.
    • Absolutely one of the best experiences of the loops I completed was a company that sent me a coding challenge to start with. They sent me a library and asked me to add functionality to it. This lets them see how I work with existing code as well as demonstrates my ability to read what’s there, understand it, and build on it. During the loop we actually did a code review of my submission and talked through the design. This was great! We were able to discuss the merits and weaknesses in the design I chose in context of future feature growth and refactoring. No learned-this-in-school algorithms. As someone who has learned to write software by doing it and not via 4 years of computer science classes this was a great experience and allowed me to show my skills and knowledge in a very real-world way.
    • Consider using code reviews or a paired programming or debugging session rather than writing out a method from scratch. Doing code reviews for each other and doing them well is an important skill and one often skipped. You may find out that the candidate has never done and may not even believe in code reviews.
  2. Have some code questions (and solutions) ready before things get started.
    • As the interviewer this isn’t your chance to show off to the candidate how clever you are or to push them until they’re lost. A well designed question should have a couple of workable solutions that you’ve already recorded in advance.
    • Adding arbitrary specifications as you go to make the question harder can make the experience more confusing and especially so if the specs end up describing something completely different by the time you’re done. One of my questions started as a simple counting exercise that quickly turned into a multi-parameter search instead. The last bit of added functionality was a pretty strong pivot from something similar to count the occurrence of a thing in a string.
  3. While scheduling sometimes makes things hard and tech companies can be the worst about randomization; please read the resume before getting into the room.
    • We’ve only got a short amount of time to talk and having you spend 5 of those minutes reading me the resume I wrote and sent in isn’t the best use of that time.
    • If you really can’t squeeze it in just ask me to tell you what I did. You’ll get more out of it and it’s much less awkward for me as the candidate.
  4. Try to be language agnostic even if your workplace isn’t.
    • Expecting a candidate to pick up Golang over the weekend before the interview is just unrealistic. Even if they mostly pull it off they won’t be comfortable or fluent.
    • If you know the candidate is strong in Java and Python but you happen to be a Go or Ruby shop try to find someone on the team that knows one of those languages to do the coding questions. This can help the candidate feel more comfortable and makes it easier for you to let them use their preferred language while still having someone that is familiar with it look it over.
  5. Focus on solutions and structure rather than memorization.
    • The candidate is going to be nervous. They’re going to blank on the exact right method or library name that does the thing they did that time that makes the problem you’ve asked easier. If it doesn’t compile or it would stack trace due to a missed character somewhere that’s something they’d find through their own local testing anyway. Pay more attention to their ability to solve the problem reasonably even if they have to pseudocode some pieces they can’t recall at the moment.

My turn, yeah?

It’s really about time I started blogging all these interesting things I find and review in the security world.  I’ll be sharing information and articles I find interesting and adding additional commentary or analysis to them when appropriate.  I’ll probably post some code snippets from time to time as well.  I’m not primarily a developer but some knowledge and understanding is obviously part of the field.