Photo by ThisisEngineering RAEng on Unsplash

Hiring a software engineer is hard. It can take months to meet candidates that have the skills and strengths that will grow your team. Convincing them to join is an even heavier lift, often with huge price tags. As interviewers, we often make both challenges harder by chasing after qualities that don’t build strong productive teams.

I want to share what I think a technical assessment interview is supposed to do, and what makes for great technical assessments for businesses of all scales.

Why should you listen to me

I am a seasoned software engineer that has worked in the heart of the San Francisco tech industry building products with startups, and international corporations for over a decade. Primarily bringing apps to peoples iPhones.

I have interviewed with countless companies from FaceFlix giants, to WeWork nomads. I have designed and given technical assessments for the last 5 years, and built candid friendships through out the industry while working with hundreds of brilliant people throughout my career.

Interviewing is a frequent passionate topic of discussion for me - and while it may not be my favorite work activity - I have enough experience to share perspectives I think can improve the interviewing experience and outcomes for those in any industry.

What a technical assessment is supposed to do

Technical assessments first and foremost goal is to evaluate a candidates technical merit. If you yourself have technical merit, this is trivial. You can tell when you are talking to someone that knows your business.

Harder to answer, but more importantly:

What can they add to the team technically? And is it what we need?

Sometimes that means a specific fluency in a technology. Sometimes it is general knowledge of an entire suite or “stack” of technologies and how they work together. Sometimes it is a background in something your team wants to do over the next year or two.

An interview should be designed to answer some reasonably obvious questions. Breaking it down, some of the things I consider when assessing technical ability is:

Code Competency

• Do I believe this person could take the work I see every day and do it to our standards? How confident am I in that?
• Do they understand computer science fundamentals and data structures?
• Do they have experience with the platform/framework/stack we use? How deeply?
• How well do they apply concepts and data structures as tools to approach a problem?

Technical Communication

• How do they get thoughts outside their head? Did we understand each other?
• How did they break down a problem, discuss goals, risks, quality assurance? Will they be productive in technical meetings here?
• How confident am I that code from this person will be what the team considers to be “good code”, and reviewing it will be comfortable and productive?

Teamwork

• How did they respond when I asked them something they didn’t know? How about when I asked for a recommendation, decision, or made a suggestion?
• How on time were we? Did we complete our objective in the allotted time? How easy was it staying on time?
• Was the interview enjoyable? Stressful? Awkward? Did anyone genuinely smile or casually curse?

Level

• In all of the categories how advanced was the performance?
• How well did it meet the needs of the role?
• How much is the team going to succeed or fail by this roles influence compared to my confidence?

I argue that a good technical assessment will leave an interviewer able to speak to these sort of questions if the interview was designed and given well.

Common Anti-Criteria

I have been in a lot of interviews that work against common growth objectives and even feel adversarial at times. While they demystify the recruiting process for interviewers by providing standards to follow, they completely miss out on gaining true understanding of a candidate and using the hiring process to strategize your team growth.

Success (Binary) Measurement

• A task was completed
• The candidate possessed _______ skill or demonstrated ______ ideal

IQ Measurement

• The candidate answered trivia facts correctly and uses idiomatic code
• The candidate solved a riddle, puzzle, algorithm challenge

The Grit Measurement

• The candidate succeeded under stressful conditions
• The candidate did not fall for a trick

These are all interesting things to have happened during an interview, and often would fit into a debrief, however I believe that an interview _should not be designed__to take their measuremen_t.

I often start interviews by explicitly stating that I’m not measuring these things. They are obviously noted, but they aren’t being compared to a standard. This sounds like it would be a big disclaimer but it’s as easy as:

“We want to make progress, but most importantly I want to hear your thought process and get a sense of working together.”

“The project we are going to do is the topic of the interview, but getting to know how you think and work is whats most important here.”

“We want to get to a working solution as quick as we can, but I’m not as worried about how smart you are as how well you can think and learn”

This has a powerful effect of de-escelating the interview and often makes a role more interesting to a candidate having had a comfortable experience that they can mentally map to a daily environment.

The most compelling interviewers I have worked with are able to make candidates forget they are interviewing — Not because of charisma, or co-working chemistry — but because the task that was presented was topical, and the interviewer was engaged not a challenge to be overcome.

#recruiting #interview-tips #software-development #interview #software-engineering #interview-questions