Technical interviews can often materialize as a game of Battleship. Each side, lobbing over random coordinates of pop-quiz style knowledge tests looking for a “hit”. Will your armada sink in the next interview?

Board game metaphors aside, a well-done technical interview can be highly insightful into the technical skill of a candidate, where resumes and chit chat may not reveal the true nature of someone’s ability to contribute to teams expecting each person to perform highly technical tasks. Conversely, a poorly done interview only succeeds in demoralizing possibly good candidates, with those who pass only showing that they know what you think is important – a risky proposition that threatens to create an environment with low diversity of thought and skill.

So what does a good technical interview process look like?

  • Explain Everything
    • A candidate is in an unfamiliar place with people they do not know, evaluating them in all manners. Go out of your way to explain who you are, the interview process, what is expected, where the bathrooms are, who will come next to talk, introduce them, so on. If a candidate is too nervous from trivial things, they will not be able to give you good readings on the things you care about. Help them out a bit.
  • Measure Strengths
    • A good technical interview should only explore a candidate’s claimed strengths. This is so important. Do not waste valuable time making candidates feel small in things they already said they don’t know well. Move on.
  • Let them talk
    • Avoid standardized testing style questions with exactly one answer. Instead, use questions which let candidates answer in their own words, encouraging them to volunteer their level of comfort in the subject.
    • Positive example: Explain polymorphism to me in your own words.
    • Negative example: If I want to define a class that cannot be instantiated, but define some of the behavior for subclasses, what keyword goes in the class declaration?
  • Enough sorts
    • Do candidates really need to write sorting routines at your company? Can they just use one that was already written? If so, why are you testing them on writing a sort? Instead, prefer a trivial sample to prove they can code, or instead offer them to provide some examples of advanced algorithms they have written outside the interview. Remembering how to quick sort with someone standing over your shoulder should not be a gauge of anything.
    • Instead of asking for route memorization of algorithms, consider replacing these segments with tests that identify that candidates know which algorithms are a good fit for what problems. It is likely this is more important to you.
  • Know it too
    • When questioning candidates about technical subjects, it is important that the interviewer also discretely know the subjects being investigated. If this expertise does not exist at your company, solicit a peer or trusted third party to help you.
  • Be respectful
    • Even if candidates do not make it through your process, make sure they are treated well. If your hiring pipeline has gaps, give the candidate your personal contact information so you can follow up with getting them the outcome of their interview. Press your coworkers to decide quickly about each candidate so they can get the news of what comes next (if anything). You would appreciate the same treatment.

Given these guidelines, most folks should be able to cobble together a reasonable process to evaluate candidates.

How do candidates maintain their composure during this sort of intense question session? A few tips have helped me in the past.

  • Get basic context
    • What job role are you applying for? Is this question abnormal for the role? Ask why this question applies to your role if you do not think it does. It may be a sign you will be doing a different job than you thought.
  • Remember your value
    • The reason most people get hired is because they offer a value greater than the resources they consume (or so it seems). If you do not know the answer, follow up with how you can likely get the answer on your own, or how you would identify who to ask for help. If it looks like this sort of problem would leave you stuck, it is a sign your value generation would stop here.
  • Talk through it
    • There is no problem with thinking a bit before you answer questions, but preface those awkward pauses with a simple statement, “Let me think about that for a bit.” Letting the interviewer know you are thinking, or what you are thinking as often as you are able prevents you from looking like your brain just shutdown.
  • Ask questions
    • Despite being the interviewee, ask questions of your own. Failure to get a single job does not mean you should get nothing from the process. Clarify every question you did not know the answer to, solicit feedback on your interview, ask how the company solves problems, about their culture, about your manager, teammates, break room, everything. At the end of the interview, ask how long it will take to receive an update on the process.
  • Follow up
    • Sometimes companies do their own Human Resources work, but are lousy at it. Help them out by following up immediately after your interview, thanking them for the opportunity to meet. Include a friendly reminder that you look forward to hearing about the result of your interview. If no such contact is made for 3-4 business days, send a short note asking if a decision has been made.
  • Get contacts
    • Networking is a huge value during the job search process. Be sure to continue expanding your network as you interview.
  • Relax
    • If it does not work out, keep trying. If you continue to improve yourself, apply yourself with careful thought towards advancing to the next step, you will achieve your goals.

Hopefully the next time you participate in a technical interview, one or more of these points will help you.

Agree or disagree, drop me a comment.