Technical interviews tips

Technical interviews are evil

Reasons to rethink your technical interviews.

Intro

To attract top talent, companies of all sizes aim to establish a fair process for hiring. However, let’s focus on one aspect of the process: testing candidates’ essential skills. Technical interviews are widely disliked, and attending them is a skill that requires continuous development, with some developers making it a habit to attend interviews every few months to stay proficient.

Companies view candidates’ resumes as evidence of their skills and experience and want them to prove it within a limited time and narrow context during the interview process.

But how effective are technical interviews at testing skills and experience? For instance, can an exam like a driver’s license test identify qualified drivers? How many lorry drivers with 10 years behind them will actually pass the driver test today? Similarly, how can someone with a decade of experience fail basic interview questions? Is it due to poorly formulated questions or unclear expectations for answers?

Perhaps using an interview as an exam to evaluate experience levels is not the best approach. Experience is a journey filled with stories, and seasoned engineers have plenty to share, whereas recent graduates may not. Algorithmic questions do not require work-life experience, only study.

Problem

Candidates possess a diverse range of personal skills, such as code-oriented, architectural, eagle-eye view, jack of all trades, and more, which can be valuable depending on the hiring requirements. However, it’s crucial to avoid searching for “ninja” or “rock star” engineers since these terms are too ambiguous and may not accurately reflect the required personal skill set for the job.
By introducing an exam that doesn’t account for the variety of personal traits, the company may introduce trait bias, where strong candidates cannot showcase their strengths and are forced to balance between the requested traits and their real potential. Consequently, the company may miss out on valuable human resources.

A standardized, one-size-fits-all approach is not suitable for the nuanced nature of human beings, as none of us is prepared machines that work on input/output on defined requirements. It’s not effective to treat candidate requirements like a configuration file for launching a virtual machine. While you can take mechanistic action on these, the interview process should prioritize the candidate as a person who meets the criteria, providing them with the opportunity to showcase their thought process without being redirected towards a different mindset.

Setting up technical interviews is a challenging task that primarily depends on the structure of the company. Whether it’s centralized or distributed, the interview process will be aligned with the broader company management. This raises the question of who makes the final decision: management or the team? This decision-making process is the first glimpse that a candidate may have into the company’s core values. The candidate can sense from the perspective of interview motion: steps, descriptions, levels, and talks from hiring managers and developers. It’s very hard to hide the true nature of the company. A company can’t make distributive software when the management is running as a monolith.

During the interview process, the 80/20 law applies, meaning that the candidate performs 80% of the work, while the interviewer’s 20% involves deciding which parts of the candidate’s performance are valuable. However, if the interviewer is influenced by noise, such as having a bad day, feeling tired, or lacking sufficient experience, they may make poor decisions and overlook a strong candidate, resulting in a missed opportunity for the company. {This is a very pertinent point — I would go further and recognize that their unconscious bias on the basis of gender, ethnicity, disability, etc. is also liable to influence them}. Therefore, the hour-plus session should provide the candidate with as many opportunities as possible to showcase their skills, while also offering the interviewer the best possible view angle to make informed decisions.

Using big, complex questions as an indicator to evaluate a candidate during an interview is not necessarily effective. Such questions often stray from the day-to-day work of engineers and can feel unnatural for both the interviewer and interviewee. Engineers’ daily routines typically consist of small victories and frequent minor decisions. As such, the interview process should reflect this reality and focus on questions and tasks that more accurately reflect the job requirements and responsibilities.

During an interview, the interviewer doesn’t need to demonstrate extensive skills or knowledge. However, it’s crucial for them to exude confidence, as even the slightest hint of doubt can cause nervous reactions from all participants. One way to boost confidence is to shift your mindset from that of a judge or examiner to that of a cheerleader. Although you’re present during the interview, you’re not actively involved in the candidate’s performance.

The assessment stage can be particularly challenging, especially when the interviewee encounters a roadblock for any reason. As the clock ticks away and progress slows to a halt, the candidate may begin to lose confidence and motivation. In such cases, how can the interviewer evaluate the candidate’s potential when their credentials seem to be a perfect match on paper?

Solution

Providing candidates with ample time to complete tasks is beneficial. Interviews that focus on low to medium-complexity tasks can increase a candidate’s confidence and allow them to showcase their skills in greater detail. This is particularly true for experienced candidates, who may have more stories to share and insights to offer. As candidates delve deeper into each solution or issue, they can provide more interesting and detailed responses. By observing and learning from these candidates, interviewers can gain a better understanding of their capabilities and suitability for the role.

Let’s assume, the solution is not important, solving everything is not crucial, and the journey that makes it counts. Decision-making, changes in the chosen direction, and even googling might take a candidate’s assessment to a different route.

Low to mid-level complexity questions don’t require the interviewer to lead the candidate towards a specific solution, as the answer is often apparent from the outset. Instead, you can observe the candidate’s journey from start to finish.

Many companies have role descriptions outlining the expectations for different levels of seniority. However, these descriptions may not be fully applicable until an employee has worked in the company for a substantial period of time. In addition, it can be challenging to evaluate a candidate’s performance during a single hour-long interview.

One way to address this is to develop expectations based on observations of your fellow team members and your own performance. For example, if you are interviewing a principal engineer and currently work with one, you likely have expectations regarding the types of problems they can solve and their level of expertise. This is an opportunity to assess the company’s internal environment and methodology to determine whether they are effective or not. A positive environment can lead to more accurate evaluations of job candidates.

Some concrete ideas for solutions:

• Give choices:
  Choices should be made as a cost-based decision.
  Although home tests may come at a higher cost (more time-consuming), they offer the advantage of granularity and asynchronous review, with more flexibility in terms of rules, tasks, and expectations.
  On the other hand, pair programming is a less costly option that lacks granularity and flexibility, but enables real-time interaction with the candidate.
  Make a technical session a window of opportunity, and let the candidate choose their best side.
• Make complexity up to 5 in a range of 10:
  Don’t make technical sessions too complex, the candidate should accomplish more, the more the interview sees, the better the assessment will be.
• Give confidence to the candidate:
  The calm and talkative candidate is easier to assess. It’s enough for one nervous interviewer to seed doubt.
• Be a spectator, watch and learn yourself:
  It’s easier to assess the candidate’s train of thought when you’re not interfering with it, leaning toward your own optimal solution — PP is more of a journey than an exam.

Conclusion

Technical interviews have been deemed a necessary evil in the tech industry, but they can also be a journey when approached correctly. Good engineering requires both learned skills and earned experience, and any interview process that fails to consider this misses the point of hiring for potential. Complex algorithmic-based tests can limit a candidate’s skill range and create bias, especially when fresh-out-of-college candidates may have an advantage.

To improve the interview process, candidates should be given choices, and the complexity of pair programming sessions should be limited to allow for better assessment. Giving candidates confidence and being a spectator during the process can also help to assess their skills more effectively. By reframing the interview experience as a journey instead of an exam, candidates can be evaluated more accurately.

Want to work alongside some great humans and inspiring leaders to solve big problems? We’re hiring! Click here to join the #BeamTeam and change the future of work.