What Does a Technical Interviewer Do?

It's more than "a software engineer who sometimes conducts interviews"

Technical interviewing is relatively new, as specialty fields go. It’s transformed parts of the software industry over the past decade, now with its own experts, best practices, and startups. To be honest, I’d put little thought to interviewing prior to starting at Karat in early 2016 - I enjoyed the process as both a candidate and as a software engineer interviewing candidates (I know, I’m that weirdo), but there wasn’t anything particular I prepared for in either setting beyond getting to know the company/role or the candidate, respectively.

A Little History

Early in my software career (which began in 1998) the industry practice was that once you got past a phone screen, you came in for an on-site interview, typically an hour each with somewhere between three and six engineers, managers, and other folks from the company and team to which you applied. Then maybe you got an offer or a rejection, or you might occasionally be asked to come in for a follow-up interview.

It was incredibly ad hoc, even at the larger companies where I worked. There was often no particular rhyme or reason to the choice of which team member was selected for this candidate or that, there was no standard set of questions to ask, no metrics to measure, nothing. “Gotcha”¹ or (if I were to put it far too charitably) “brain teaser” questions (which still plague interviewing) abounded, and in addition, there was no consensus around what a team fit might look like in terms of personalities, office culture, and work structure.

In short, it was a Wild Wild West² of sorts, as haphazard and as inconsistent as it sounds. Outcomes were based more on soft guidelines and gut feeling than any sort of measurable data.

Coding interviews started to become standardized and popular in the 1990s, in no small part thanks to Microsoft making it part of their process, somewhat replacing the ubiquitous whiteboard-based pseudo-”coding” or design questions. There’s a long history of this evolution, chronicled in articles such as this one, but two important things happened.

First was the advent of practice sites such as LeetCode and books about coding interviews, the most famous being Cracking the Coding Interview³, which first came out in 2008. A coding interview became something you could train for. You could practice - knowing the common data structures and algorithms (as well as the runtime and space complexities of each), and then implementing them.

Second was the advent of the third-party technical interviewer - people like me - and the companies that sprung up around what was essentially a new job specialty. Coding interviews became more regimented and score-driven, with an eye toward meaningful metrics and valuable results. A hiring manager could then ask: can this candidate code to some baseline level at which we’re comfortable inviting them to the next steps - steps where our company’s expensive engineers devote some of their valuable time to getting to know the candidate beyond their initial problem-solving competence? Are we confident that they’re really at a certain level of coding ability because of how they did in this technical interview?

Along with that job came new procedures - training interviewers, writing scripts, penning and testing new coding questions, turning a ragtag band of scrappy hackers into well-oiled interviewing machines⁴.

Scrappy hacker? Or well-oiled machine? You decide.

The technical interviewer is trained to conduct the interview so that that confidence level is measurable and consistent. So, who are we and what do we do?

Conducting a coding interview requires, of course, technical competence on the part of the interviewer. First and foremost, we have to be able to read code in multiple languages. This doesn’t mean we have to be able to write code fluidly in those languages, but as I said in a previous post, we do have to spot syntax errors, know language conventions, understand nuances of time and space complexities (“Does Python make a copy of an array when you slice it?”), and generally come across as plausibly familiar with whatever language a candidate chooses. This is both for the candidate’s comfort level and confidence in your ability to un-stuck them as well as how the client holds you in esteem as a seasoned engineer, capable of helping to evaluate the candidates that they’re paying you good money to assay.

An excellent technical interviewer will also have a high emotional IQ. Job interviews can be particularly stressful - maybe the candidate simply really wants this particular role or to work for that particular company, maybe they really need the work ASAP, or for many people, the mere fact that it’s an interview is enough stress on its own.

I’ll go into more depth on this topic in a near-future post, but the number of opportunities to relieve (or better, to prevent the onset of) stress in an interview is massive. A well-timed joke, taking an interest in something about the candidate (a hobby, a shared love of pets, etc.), giving them an opportunity to talk through their implemenntation approach with you - these are all little chances to make the interview more fun and less harrowing. When hiring technical interviewers, the coding ability is almost secondarily important. Loads of people can write and read code, but the empathetic - the ones that can read the candidates’ faces, understand the meaning in their words and actions, and then react appropriately by setting the tone and cadence of an interview - those are going to be the cream of the crop. A candidate who is comfortable and feels good vibes in the interview has the best chance to think clearly, to ask questions when needed, and to demonstrate what they can really do.

A story: some time ago, I had a candidate who, right off the bat, seemed particularly stressed. This person could not describe a project they’d donerecently because they were shaking so badly - a question I used as an icebreaker. The video call went immediately from a job interview into an “are you okay?” discussion; there was clearly no way they would be able to continue at that time.

It was anxiety. They told me that it was a managed thing for them but that that day was bad, and we agreed to try again in a week. I promised that I’d be the interviewer for the reschedule, so that they wouldn’t have to worry about meeting a new person, and that it was totally fine.

That person came back in a week, anxiety managed, and did well in the interview (and, if memory serves, got the job!) It might have been my proudest moment as an interviewer, knowing that I got to help this person in a way that a colder, less personal interview process might simply have led a hiring manager to write them off. You have to care about each candidate as a person.

In a similar vein, clarity is incredibly important. Communication skills, particularly in explaining processes and what to expect (during the interview itself and also while relating the upcoming steps after the end of the interview) and illustrating coding (and other) questions, are enormous. When a candidate grasps a coding question clearly after your succinct initial explanation of it, this is the gold standard - the more quickly they grasp it, the more faith they have in you to explain things well, and the more time they have to implement it, to express their approach, to ask clarifying questions, etc.

All of these things, thus far, have focused on the person that you see face to (e-)face as an interviewer - the candidate. But a technical interviewer, whether in-house or third-party, really serves two entities, the other being the client - a hiring manager, the company itself, the team doing the hire, etc.

Some clients literally watch every interview, and all of the performance aspects of your interviews are clear to them just as clearly as they are to the candidate - in a way, even more importantly so, as you are literally representing the client to the candidate in a very real sense. As such, having a good rapport with each candidate is vital. Candidate experience is far more of a focus today than it has been at any previous point, with services such as candidate.fyi⁵ helping companies to make the process more transparent and welcoming to applicants. Little things such as responding in a timely fashion with appropriate feedback at any stage, or simply detailing the steps in the process and the communication at each step - they all add up when it comes to making that candidate feel like your company (or the one you represent) is a place that cares about them.

Some clients don’t watch every interview, or only scan parts of them. This is where the technical interviewer must also be a strong, clear writer. By giving a clear writeup, with sufficient detail to ensure that candidates are distinct from one another to the hiring manager’s eye within the space of a fairly short read, you present a broad view of the candidate’s personality, how well they worked together with you, and other tidbits that help your client get to know them without spending vast amounts of time doing so.

Serving two entities whose interests overlap but do not match entirely can be tricky. That’s why excellent technical interviewers have to combine technical skills, written and spoken communication skills, and a high degree of empathy and emotional intelligence. These give the candidate the best chance to showcase their abilities, and the client the best possible sense of who that candidate is.

More on what we do, coming soon!

1. Gotcha questions, in my usage here, are “questions which are easy if you happen to possess (or happen to brainstorm by more luck than aptitude) a specific piece of knowledge and otherwise potentially quite difficult to puzzle out”. I hate them with the fiery passion of a thousand ghost peppers percolating through my abdomen.

2. Coulda gone with Escape Club for a Wild Wild West reference here, too. The movie, despite its considerable star power, was terrible.

3. This is an Amazon affiliate link - if you shop there via this link (through the Substack website, not directly from the email), you’ll help support my continued writing!

4. This isn’t really what happened, but I grew up watching movie trailers in the 80s and sometimes it just bubbles through in my writing.

5. I have no affiliation or relationship with them at the time of this writing, I just like what they’re doing.