Reciprocal Technical Interviews: How to Get Started

Reciprocal describes something that's the same on both sides.

In the context of tech recruiting, when you and your candidate agree to an interview, you are ideally entering a reciprocal agreement to ask each other questions to determine if the candidate is a good fit for the open role. That’s a Reciprocal Interview.

It sounds simple, but a lot of companies still get it wrong. Here’s how and why to do it.

Rejection and Reciprocity

Have you ever faced rejection?

Of course you have. We all have.

Rejection is unpleasant. But getting better at accepting rejection and moving on has become a critical part of resilience – a buzzword I remember hearing often years ago that is still making the rounds.

While being resilient is pretty necessary in today’s world, there are at least two sides to every story. Today, I’m here to argue that technical hiring managers need to consider the other side when it’s time to hire developers.

Rejection in America is often talked about as something one receives. How we talk about “dealing” with rejection is usually in the context of how we receive and process it and how we move on from it. It’s how we become resilient.

But the act of rejecting someone should receive just as much or more consideration than receiving it gets.

How do you reject your candidates? In what context are they receiving this unfortunate news? Are you, as a hiring manager or recruiter, doing the best you can to soften that blow? Are you helping your candidate become more resilient? If not, should you?

Rejection in Hiring

Rejection is a staple in the game of hiring. For every single person hired to fill an open role, many more will have received a rejection.

But an inconsiderate rejection will leave a bad taste in the mouth of any candidate who receives it. It’s a memory that stings, and it’s one that shunned candidates will be willing to talk about when the opportunity arises—the type of rejection that motivates folks to leave you a scathing Glassdoor review.

So how do you reject someone gracefully?

The key to this question lies in adopting a truly Reciprocal Interview process.

Reciprocity in this context relates to what we as hiring managers wish to receive from our candidates: respect, transparency, and diligence.

And yet, so often in tech, we hear about the opposite: ghosting (on both sides), inconsiderate requests, unaccommodating schedules, and unclear expectations. Not to mention issues of equity, where underrepresented candidates face all of the above and more.

Reciprocity in Hiring

How does a Reciprocal Interview work in practice? Let’s start with what it includes:

• A written job description without excessive requirements;
• A clearly communicated interview process on your careers page;
• A clear salary band shared in the first interview (or better yet, in the job description);
• A fair and equitable pre-employment assessment (e.g., case study or take-home project);
• A competitive offer letter (not the lowest starting point), and;

For hires:

• An excellent onboarding experience.

For those not hired:

• A respectful, timely, and personal thank you.

I have every intention of writing a post about each of these over time, but for now, I’ll start by defining what precisely a fair, equitable, and reciprocal pre-employment assessment looks like in tech.

Many folks seem to think there is a fine line between the bad tech interview and the good one. Let’s make that fine line a little thicker.

The Bad Tech Interview

First, let’s talk about what often happens before, during, and after a Bad Technical Interview. You may have experienced this yourself.

Before

The candidate applied and made it past CV screening and perhaps the initial interview with the recruiter. They’re told that the next step is a technical interview. They were kind of expecting this and, in preparation, have begrudgingly spent the last month completing questions on Leetcode.

Or...

The candidate applied and received the automated “we’ve received your application” email, but they didn’t hear anything until four months later when someone from recruiting cleaned out the ATS and moved them to REJECTED, triggering The Standard Rejection: “We’re sorry to inform you….”

During

The candidate receives an invitation to a private Github repository and is asked to build and implement a new feature with the existing codebase. They spend the entire weekend and most of Monday evening doing this task, missing their nephew’s 3rd birthday in the process.

Or...

The candidate receives a Hackerrank link to a screening challenge, where they’re asked fill-in-the-blank multiple-choice questions in JavaScript and Python, then asked to reverse a binary tree. The candidate is annoyed because they’re a self-taught frontend developer with 6+ years under their belt who has never had to reverse a binary tree at work ever. They later mention your company by name in a “Why I hate your programming test” thread on Reddit.

Or...

The candidate is informed that they will have a pair-programming session with a hiring manager next Tuesday night. They receive a CoderPad link and are asked to reverse that binary tree live while the hiring manager watches quietly in the video chat and makes indiscernible facial expressions. “Well, at least I’m not doing this on a whiteboard...” The entire experience is stressful and unnatural, and the candidate leaves the interview unsure of how they did.

After

The candidate receives good news, letting them know that they’ve made it to the hiring manager interview, where the hiring manager asks a lot of the same questions that the recruiter asked but throws in some more technical bits here and there. They never brought up the previous technical interview at all since it was just a screening phase.

Or...

The candidate receives the bad news that they’ve been rejected via an automated system. Typically, The Standard Rejection is something along the lines of “We’re sorry to inform you that we did not choose you to move to the next stage of the hiring process. Regards.”

These are bad experiences. But they are the norm.

We initially had Big Tech to thank for this, but they receive hundreds if not thousands of applications a month and have no way of dealing with each of their applicants in a personable way. And to be honest, they’ve improved their interview processes a lot over the last few years. So, we can’t really point the finger at them anymore.

The smaller tech companies who adopt Big Tech’s old flawed hiring processes after perceiving that these strategies “worked” do so while ignoring the fact that they don’t have the same problems Big Tech was trying to solve. Smaller companies aren’t receiving hundreds of qualified candidates a month, so they don’t have the same excuse to resort to the Bad Technical Interview.

As a reminder, a truly Reciprocal Interview requires looking at every candidate and investing the same effort into that candidate as that candidate has invested into applying to your company.

Making steps toward a Reciprocal Interview isn't actually as difficult as it seems on the surface, but what it does require is some thoughtful intent.

So what does it look like in practice? Let’s dive in:

The Good (Reciprocal) Tech Interview

How does a good technical interview process look and feel? If you haven’t asked yourself this before, you should wonder why that is. Let’s workshop it:

Scenario: The recruiter receives a well-written cover letter, but the candidate is a bit too junior for the role and doesn’t have experience building in React.

Rather than send this person The Standard Rejection, the recruiter takes an extra 30 seconds to say:

“We’re sorry to inform you that we did not decide to move you to the next stage of the hiring process. In this role, we are looking for someone who has demonstrable experience building in React. Regards.”

Add that one bolded sentence, and suddenly, the reason for rejection becomes clear. The recruiter’s job is done, and any follow-up messaging from the candidate beyond “thank you for getting back to me” can typically be ignored without the recruiter being a bad person.

Feedback is even more critical during the assessment stage. Let’s take the example of the candidate who received a Github repo with instructions to build a feature.

After missing their nephew’s birthday, they send their solution to the hiring manager and await feedback. But feedback never comes. What does come is The Standard Rejection.

And look, it shouldn’t be that way. There is no good excuse.

A Reciprocal Interview requires that when a hiring team requests work from a candidate to demonstrate their skill set, the hiring team reviews the submission.

To ask a person to do a hiring test and never look at it is entirely unacceptable. That’s a YOU problem, and you’re the bad guy if you do this.

Instead, your team should invest, in a reciprocal way, the time and effort to review that submission and provide feedback.

Why? Because it is the right and respectful thing to do as a human employing other humans.

And second, because doing so allows your team to make data-driven hiring decisions instead of relying on biased-filled “gut feeling” and “culture fit.”

(Hot Tip: If your secret desire is to hire based on intuition, then do us all a favor and skip the programming test!)

I can anticipate the objections already: “But it takes so loooooong to review everyone’s code!”

And if that is your excuse, the answer is also simple: Stop creating days-long coding projects for your candidates. Invest some time in making them short, sweet, and to the point.

Again: A Reciprocal Interview requires that every candidate receives the same amount of investment that they deliver. This becomes more achievable when their time investment is hours - not days.

Nobody wants to spend their weekend building your fake feature anyway. The best take-homes are 4-6 hours long, maximum.

And if you’re wondering how to make a good take-home coding assignment, I’ve already written an entire article on that.

A final note on take-home feedback: it should be positive when it’s a rejection and critical when the candidate moves to the next stage.

What do I mean by that?

Unfortunately, many American employers fear EEOC lawsuits coming back to bite them when they’ve provided negative feedback to candidates. So don’t provide negative feedback when you’re rejecting someone.

Instead, identify a few things your team liked about their submission. Mention those things. Then finish with, “We’ve received a lot of great candidates and have decided to move forward with someone else. Thanks again for investing the time to participate in this interview process.”

That’s really all it takes.

Making the Reciprocal Interview Work for Your Team

Did you know that you can leverage early-stage interview work in later-stage interviews for maximum insight and minimal prep work? That means saved engineering time!

If you’re wondering how, then let’s review the typical stages found in the interview process.

As already mentioned, the hiring process typically starts with the CV screening. The next step for candidates who look good on paper is the “get to know each other” phone interview with the tech recruiter. And after that, we have the hiring manager interview or the work sample/case study.

I advocate for having the technical interview BEFORE the hiring manager interview. If done correctly, this won’t put any of your candidates off.

Layout the entire interview process from start to finish

You need your candidates to buy into your hiring process from start to finish, so it pays to be transparent about what that entails.

Communication is critical throughout the recruitment process. How the hiring team communicates (or fails to communicate) with candidates can make or break the candidate experience.

Plan how you will communicate with candidates in advance. Do you have an email template ready to go at each step of the hiring process? Candidates should receive feedback promptly if they will move to the next stage or not. Have a plan to communicate and stick to it. Don’t leave candidates hanging.

If the candidate is moving forward beyond the initial “get to know each other” screening call, then be prepared to provide them with information to make them feel comfortable in the subsequent phases of your hiring process. Candidates shouldn’t show up to the interview feeling unprepared, and it is your responsibility as their potential employer to help them succeed.

What we’re trying to convey here are transparency and respect. What we’re actively working against are candidate ghosting and inconsiderate wait times. It is simply unacceptable to ghost a candidate in 2021 when communication is easier than ever; there is no excuse. Your candidate deserves to know where they stand with the companies they apply to, and everyone deserves to work for a company that treats them with dignity and respect.

Design a technical interview that resembles the actual programming work done at your company

This sounds simple on the surface, but I have to hit this one home again since developer talent still reports companies asking them to reverse a binary tree.

Here’s the thing. Trees may be the single most important data structure in computer science, and knowing how to balance one may very well be an important computer science skill. But trees are not the single end-all-be-all software development skill, and knowing how to reverse one under pressure is not necessarily a good signal that this particular candidate is or isn’t a fit for your dev team.

The best signal for whether a candidate can do the work you need them to do is revealed by having them do the work.

Does this frontend role require candidates to implement designs on the frontend every week? Probably! Then give the candidate a short project where they implement some designs.

Need to hire a Python developer to build internal tools for the customer success team? Try having them implement a service that parses as a list of customers and returns their names based on location.

Save the binary trees for the data science devs, and if you must use them, camouflage the task in a prompt that seems realistic, like implementing multilevel indexing in a database.

It does take a little creativity on your part to come up with these types of assignments, but the candidate experience alone is a reason to invest the time and effort. Add to that the additional signal you’ll receive from reviewing these assignments, and it becomes a no-brainer.

If you really don’t have time to develop a custom assignment, CodeSubmit has a great library of real-world programming tasks like the ones mentioned above that are easily customizable and ready to go.

Make it clear that candidates maintain ownership of their work

Ask any group of developers about the bad technical interviews they’ve experienced in the past, and someone is likely to bring up a scenario where the company used their coding assignment in the product. Yikes.

Sure, maybe they didn’t use the candidate’s actual code. Perhaps they had the same feature in the works for a long time, and it was a coincidence. But it does seem suspicious when a new feature is launched or a UI change is made right after a series of technical interviews.

The suspicion alone is a bad look, and if you are using your tech interviews as a source of free work, let me remind you that it’s unethical at best and, in some cases, illegal.

As a company, you can avoid all of this by being explicit. Clearly define who owns the candidate’s code (they do) and how it will be used (the correct answer is usually just for review - that’s it).

You should still create a challenge that resembles work they’ll face on the job. But case studies where you ask the candidate to “build a feature you think our app is lacking” are lazy on the employer’s part.

So, pick a creative task similar to what your full-time devs are doing daily, but don’t make it so close to home that a rejected candidate might suspect you used them for free work.

At CodeSubmit, we make this a bit easier by providing hundreds of assignments you can start from and customize to your liking so that you won’t be starting from scratch.

Revisit the candidate’s take-home in the following interview

If you’re looking to get the maximum value and signal out of your coding interview, then a great way to do so is by revisiting the candidate’s submission in the follow-up interview.

You asked your candidates to invest time in a coding project, at minimum probably two hours, so they’ll be more than happy that you valued that work enough to discuss it in greater detail in the next stage.

During the assignment review, have your reviewers take notes. If the reviewer has a question about the candidate’s submission, they should leave that question as a comment for later discussion. The review process becomes a habit over time.

Typically, the tech interview isn’t the final interview. You’ll usually have a hiring manager interview or a small group interview with the potential team members following the programming interview. These are great times to ask follow-up questions about the coding project.

Always provide some feedback

Here is where we bring the concept of respectful rejection full-circle. It is always a good idea to provide your candidates with some considerate feedback.

As mentioned earlier, if you’re delivering good news to the candidate (e.g., they’re moving onto the next phase of the interview process!), you can give constructive criticism as feedback in later stages of the interview. Remember that there is an appropriate time, place, and audience for constructive criticism, and email is often not it. So save the opportunity to provide this feedback in the following interview phase, where the interviewer can deliver it one-on-one, and the candidate can respond.

On the other hand, if you’re delivering a candidate bad news (e.g., that they have not been selected to move forward in the hiring process), then it’s always great to look back at their interviewer’s notes and pass along some positive feedback. Then try to be as transparent as possible about the reason they have not been selected.

Candidates are human beings who very often want to improve their interviewing skills. And while they may not have been a fit for your open role, they will certainly be a fit somewhere else, so try to consider their journey and help them along with it however you can.

Candidates will remember recruiters and hiring managers who treat them well, and the tech world is a small one. You will leave an impression in any case, so it’s your job to leave a good one.

That’s it - That’s a Reciprocal Interview

Now you know what a Reciprocal Interview is and why you should conduct them, so it’s time to take the advice to heart and start doing it!

In the short term, your candidates will thank you. In the medium to long term, the talent you attract will also improve. You might just find that you’ve built a world-class tech team. Godspeed!