About You
Your Needs
Finish

Schedule a demo to learn more.

Please provide your first name
Please provide your last name?
Please provide your company's name?
What is the size of your company?
What is your country/permanent residence?
In which state do you live?
In which state do you live?
By signing up, I agree with Iterable’s privacy policy. I understand I can unsubscribe at any time.
What channels are you currently using? (Optional)
Please provide how many emails are you sending per month
Please provide your primary use case
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Thank you !

Thanks for contacting us, we’ll be in touch shortly.

Technical Interview Tips

4 Tips to Improve the Technical Interview

If you work as an engineer at a fast-growing company like Iterable (we’re hiring!), you’ll find yourself giving technical interviews—lots of technical interviews. Interviewing is hard, but I believe that the process for finding great people doesn’t need to be antagonistic. It’s possible to both improve the quality of information you collect during an interview while also creating a positive experience for candidates.

To this end, here are four practices I’ve adopted to make technical screens more fair, insightful, and collaborative.

Improving the Technical Interview

1. Choose an appropriate challenge

Before choosing the question for a technical interview, consider how it relates to the role that you’re trying to fill. For general hiring, a technical screen is rarely about finding the absolute limit of the candidate’s technical ability. More often it’s about evaluating their general competency— and understanding how well they collaborate, communicate, and approach novel problems.

Some things to watch for in an interview:

  1. Does the candidate understand the question? Do they ask questions to find the boundaries and edge cases?
  2. Before writing any code, can a candidate communicate a strategy for solving the problem? How do they respond when they hit a dead end?
  3. Are they systematic in their approach to debugging? If blocked, how do they break apart code and hone in on the problem?
  4. How comfortable is the candidate with the languages and frameworks in question? Can they express their intentions through concise, idiomatic code? Do their naming conventions add clarity?
  5. How do they incorporate feedback? When given hints, can they quickly course correct? Can they refactor existing code to adapt to a new requirement?

If the role in question requires a specific expertise, you’ll probably want to vet the candidate’s knowledge in that area. Often these kinds of positions are the exception, not the rule. And don’t overdo it—people can learn, and it’s unlikely that you’ll have them working on the exact problems they’ve solved in previous roles.

2. Break the ice

When an interview starts, be friendly and offer up a bit of personal information. For example, I often mention that I live in Hawaii, that I don’t have a CS degree, and that I was never a programmer until I started playing around with HTML in my late 20s. These things humanize me, level the playing field, and build rapport. Five minutes of easy conversation can make an entire interview more comfortable for everyone.

3. Set clear expectations

Every engineer knows the anxiety of jumping into a technical screen without knowing what to expect. What type of question will be asked? How will my answer be evaluated? What happens if I can’t complete it?

As an interviewer, there’s no benefit to being mysterious. After the introduction, I give a clear explanation of the interview format. This helps put candidates at ease, which helps make it easier to evaluate their true ability. I’ll say things like:

  • This is a collaborative exercise—ask me questions!
  • Looking something up is part of programming.
  • This question doesn’t have a “secret trick” that unlocks the answer.
  • There are no trap doors that will automatically fail you. It’s okay to make mistakes, backtrack, and think out loud.
  • Even if you don’t solve the problem, you might still pass the interview.

4. Interrupt the struggle

Even with a perfectly tailored question, a great intro, and a clear set of expectations, candidates still get stuck. When this happens, I’ll only wait a few minutes before offering help. Depending on the problem I might give a hint, remind a candidate there’s no penalty for looking something up, or even reveal part of the answer. I do this because:

  • Maybe they drew a blank: Interviews are stressful, and people freeze up. If you keep things moving, the candidate can shrug off their frustration, maintain their confidence, and move forward without feeling like they’ve bombed the interview.
  • Maybe they just don’t know: It’s critical to differentiate a candidate’s fundamental knowledge gaps from their momentary blanks. If they get stuck, move the interview along— a true deficiency may arise more than once, giving you better data.
  • Real work involves collaboration: Everyone has the experience of being hopelessly stuck on a problem, only to have someone glance at the code and immediately point out the solution. It’s part of being an engineer, and part of being a human. If a candidate takes your feedback and uses it to get unblocked, it can be a great indicator of the humility needed to be a great collaborator.

At the end of the interview you’ll know if you’ve solved the whole problem for the candidate, and the more ground you cover, the more information you’ll have to make a fair evaluation. If a hint or two invalidates the entire interview, you probably need to reconsider your question.

Finding the Right Fit

A collaborative and kind technical screening process not only improves the quality of the information you collect, but in a hot job market it’s also a competitive advantage. These interviews are a chance for your company’s culture to shine, and that’s a big opportunity… don’t waste it! After all, finding the right people is only part of the problem—a great candidate experience makes them more likely to sign those offer letters, too.

Search Posts