Today I’m excited to share with you a post from a close colleague of mine. Tom is a software engineer, team lead, and frequent interviewer at Yext. I’ll let him take it from here.

I enjoy giving interviews. My experience suggests I’m an outlier. Many developers I know see interviews as a distraction at best, and a chore at worst. So this may be an unpopular opinion: I believe that all developers should give as many interviews as possible.

Specifically, I’m talking about technical interviews. Algorithms on a whiteboard, a shared online coding session, debugging on a laptop, these all give valuable experience in an often underrated skill: reading someone else’s code.

Technical interviews are like pair programming on steroids. Within the space of an hour, you have to brief the candidate on the problem, ensure they have all the required information, and then interpret their solution well enough to grade them. This is all with someone you’ve never met before. You get something of a leg up by knowing the problem inside and out, but you could easily be faced with an approach you’ve never seen before. You might see a brand new, novel and elegant solution, or excessively complex spaghetti code with a very hard to find bug that you may need to hint the candidate out of.

Until recently, I was convinced I was terrible at pair programming. I had the idea that I lacked the patience, or would be too easily distracted by outside questions or automated alerts. But then I tried it. It turned out that pair programming can be exactly like a technical interview. I found myself using the same process for understanding my colleague’s code, taking the same cues for what could be improved, and using a similar personal approach when making suggestions.

Granted, the dynamic is different, you being peers rather than having the huge imbalance of power that you’ll find in an interview, but there’s a lot to learn from that imbalance. As an interviewer you want to see the other person’s skills, so you don’t always give the answer. When pairing, you want to make sure both viewpoints are represented, so you can step back a little, even if you know “your” answer.

The benefits of regular interviewing

This brings us to the more “human” side of the equation. Regular interviewing will bring you into contact with a large number of diverse people – and if they’re not diverse, you might want to have a word with the recruitment team! One thing I really enjoy about interviews is hearing about something the interviewee is passionate about, technical or not. It can be highly rewarding to connect with so many different people, but also challenging. You may need to tailor your explanations for example. Someone may use different terminology to you due to their career background, and you may often encounter someone speaking to you in their second language. The more situations you encounter, the more effective you can become at the familiar, and the better equipped you will be to work with the people you do hire.

The skills you gain through interviewing also may not be apparent immediately. As you grow as a developer, you’ll gain more and more responsibilities that lean heavily on exactly these kinds of skills. The more experience and seniority you gain, the more often you’ll be expected to guide your colleagues through technical challenges. As your tenure at a company grows, you’re likely to become the “go to” person for more and more aspects of a product, and be expected to be able to answer complex questions about code that was already there and working when you joined. You may also end up going down the leadership or management track, requiring you to flex your people skills and empathy. All of these are skills you exercise during the technical interview process.

There’s so much to be gained from the experience of conducting interviews, that I believe they can be a crucial part of every developer’s ongoing learning. Not only that, but HR and your fellow interviewers will be eternally grateful for spreading the workload.

Interviewing won’t be for everyone, but if you’re fortunate enough to feel comfortable with the process, I’d recommend you sign up!

Tom is a software engineer, team lead and frequent interviewer.

An on and off blogger for over a decade, he posts on topics such as programming, public speaking and leadership.

You can read more of his writing on Medium.