Holding wholesome tech interviews [part 4/7]

Benefits of modeling an interview’s information: the employer’s requirements

This article is part of a series on how we can further improve the experience and the outcome of technical interviews, from the side of an interviewer.
For a centralised table of contents for the whole series, check out this Github Gist

TL;DR: a clear mental model of an interview’s information can grant us more flexibility steering the discussion and making it a natural one, and also help set up the foundation for another essential item.

_

+2 more tools to our [batman] belt

Everything proposed in the chapters so far aimed towards making the technical interview less of a rigid interrogation and more of a natural flowing, well, interview.

We discussed an overall format, a way to initiate, and then a set of mindful approaches that help with formulating questions and receiving answers.

These following 2 chapters will focus on 2 more essential building blocks:

1. our ability as an interviewer to discretely steer the discussion, and navigate the potentially vast amount of topics, in a seamless manner
2. expanding our attention, from solely what we need as interviewers, to also include what the candidate needs.

I invite you to grab a coffee/tea and join me as we put together one solution for these 2 items and assemble the information design behind a technical interview ^^

.the solution, .the-root-of-the-problem {

&& — stemmed from the first time I realised that I needed a better way to organise an ever growing list of technical interview questions.

As I was pursuing a higher flexibility of navigating questions and topics as an interviewer, that list could no longer be strictly ordered to the most granular level, and it could also no longer be a single, long, flat, scrolling-festival list of notions.

}

The first natural upgrade was to think of each question/topic as a module, having related sub topics grouped together in child/nested modules.

This would implicitly form the structure of a tree of information, where each larger topic forms a branch of subtopics.

On a tangent but somewhat parallel thread, with time I had also realised that while this structure is helpful, that main area of an interview’s technical questions should actually not be the sole central entity of an interview.
This goes even more so with higher seniority candidates, and especially when we also have additional goals in mind, like the principles proposed throughout this article series.

With that in mind, rethinking its very purpose while also paying higher attention to both the involved actors, I’ve reached this simplistic start for the information structure of an interview (formulated/viewed with the first person being the interviewer), and from which we will eventually also circle back to solving that initial root of the problem.

the interviewer requirements

Further unpacking the first of those 2 main branches, we have 2 direct requirements for what we need, as the employer side, the first of which being our very own requirements, as an interviewer:

the interviewer requirements/non technical

In an age where we’re very gradually starting to compete with automation, I think it is just as gradually becoming more and more important for us to become more and more human at work.

So then, the following traits will go a long way for people holding the interview:

• Actively assessing an interview’s flow and energy in real time,
• actively listening, reading and hearing also what’s not being verbalised;
• being kind, actively fostering a light and relaxed atmosphere,
• maintaining a professional setting which is also open for humor;
• saving and gently deviating an uncomfortable situation,
• encouraging, helping, and so on.

In 2 words: being human.

Genuine curiosity is also an important dependency we need here.
To help that flourish, even with the risk of seeming a bit less professional, but with the equal “risk” of making the interview more friendly:

• mentally try and frame the interview like you’re enjoying a coffee with an acquaintance that you haven’t seen in a long time. As a direct result, besides toning down the formality levels this should imply a degree of genuine curiosity that goes beyond the interview’s goal.
• Next, around the nonverbal and paraverbal language parameters, you wouldn’t be a full on straight face in that kind of context right? our posture would be open, our mind relaxed.

_

the interviewer requirements/technical

Now, for going about the technical ones. With our main goal of technically validating a hiring match, we in turn, also need to fulfil certain requirements, as an interviewer:

1. a mastery of the topics
2. a clear information hierarchy of our own, for those topics
3. a flexibility regarding the order of the technical questions

That first point pretty much rules out the scenario of having an interviewer that has to read each question and then depend on having every single answer written down, to check against a candidate’s answers.

That can be fine for a few or for a small segment of the questions, but if that becomes the norm for all/most questions for a role opening, especially with more experienced candidates, it can lead the entire interview towards a negative path.

Directly linked to that first point, we will further unpack the 2nd and 3rd criterias, and explore how they also affect the way the evaluation takes place, as they map onto the 2nd sub-branch of what we need:

_

the job opening requirements

The job opening requirements list describes what traits and skills are needed for an open role, and they also further expand into technical and non technical requirements:

Since non-technical requirements are usually more thoroughly assessed in a round that precedes (and perhaps also another one that follows) the technical interview*, we’ll once again keep our scope on the technical requirements.

*That said, if time allows it, and the technical recruiter also has such inclination and/or is in the people context of the team/project of that role opening, this can be very fruitful to at least touch on, during the tech round.

Now, returning to that initial challenge, we’ll open the following scenario as we unpack the technical branch to traverse its notions with a candidate:

_

traversing technical requirements: challenge

When asking technical questions as an interviewer, I usually try not to jump from category to category more often than needed. A general order and intuitive hierarchy of the topics usually helps everyone.

But sometimes, while a candidate answers a question, they also touch the surface of other topics, which we wanted to go through later on anyway.
I always somehow felt that a great amount of good could come if that would not be swiftly interrupted, in order to fallback to our exact order of questions; or at least not every single time.

After testing just that, I’ve quickly come to realise that we should not only be able to sometimes temporarily deviate from the next specific questions that we wanted to ask, and instead invite them to share more and expand also on those touched topics, but that it is actually beneficial to do so.

Issue is that trying to achieve just that would usually mean renouncing a previous structure and order that we had in place. And attempting that when/after using solely a simple, long, flat list of technical questions as our interviewing tool, can lead to a bit of chaos.

traversing technical requirements: solution

Especially when we have a long list of notions to go through, we should be able to

• navigate through that list very easily,
• mentally checkmark answered questions very quickly,
• and implicitly try to not overlook or miss any notions.

This is the first of the 2 areas where further building onto our tree-like information structure really shines through, inherently encouraging a stricter order only when traversing categories of topics, and not necessarily also on the most granular topics:

Merely a more accurate mapping for the skeleton of how most of our technologies are structured anyway, the idea is meant to bring us into a mindset that is open to a more flexible navigation of topics.

Because if we think of all notions as modules with submodules, and we shift our mental model away from a single, very strictly ordered list of questions, and more towards a tree of information that we aim to traverse branch-by-branch, we should then able to be able to do a few exceptions for that order effortlessly, whenever needed.

This will unlock a greater degree of freedom and flexibility for us as an interviewer, and in turn enable a seemingly inconsequential detail:

allowing for even a few such unplanned small detours throughout the course of a discussion can play a massive role in making an interview flow more naturally

As we are basically renouncing some of the discussion steering towards the candidate, and enable them to go deeper on some related topics they are thinking of, before moving on to our next, instead of indirectly asking them to ‘hold that thought’ as we enforce our order of questions, to only then come back to those same topics later, as we reach them in our list.

When for a specific reason we do need to do just that, we can verbally asterisk that we’ll return to the topic, and/or initiate the later question (which returns to that postponed topic) by also acknowledging that they had started mentioning the notion earlier.

In a nutshell — a specific dialog aspect that would also occur in a normal life conversation, when we would want to reopen or revisit a topic that the other party had mentioned previously.

So far, we’ve explored how this approach can help us accomplish that first of two goals: paradoxically (or is it), showing that with more underlying structure comes even more freedom.

In the next chapter we explore how further extending this same structure in a specifically emphatic way, can also put more focus on several, often overlooked, yet critical elements of any interview: