If you have the skills to make furniture out of wood, you probably have the skills to at least get started in professional carpentry.

Programming is similar in that if you have decent programming skills and a body of work to show for it, you can probably get a job to get your career started with the right references and leveraging your network.

The work of software development just so happens to occur at a desk with a computer solving problems in the digital space as opposed to a physical job site.

The fact that it's a skills trade requires that software engineering interviews actually involve coding. Think about it:

• Would you hire a plumber if you didn't know they could fix a leak in your plumbing?
• Would you hire a carpenter if you didn't know they could build or fix furniture?
• Would you hire an HVAC technician if you didn't know they worked on HVAC appliances regularly?

Software engineering is no different. You have to hire them based on their ability to engineer and implement software.

However, unlike contract work where you can fire the unqualified plumber and look for another one, hiring an engineer often involves bringing them on payroll for several reasons.

• Engineers build robust systems that bring the business value, but these systems must, at a minimum, must be maintained for when something goes wrong.
• If every company constantly swapped out their engineers like in the contract model of other skills trade workers, the system that is essential to the business becomes brittle and harder to maintain as engineers would be incentivized to "get the job done" in a quick-and-dirty manner.
• The value of an engineer's work is extracted over the span of their employment, not by getting them to do a one-time fix for a fixed cost.

This results in businesses bringing on engineers with compensation and perks to match the business' desire to keep them around.

This means that there is an inherent risk in hiring the wrong engineers. It's an expensive mistake because

• Firing someone is also often a lengthy process.
• The business is paying extra in the form of perks and benefits during employment.
• It's just generally a stressful experience for everyone, including the manager who has to do the firing which ultimately affects morale across the team.

Hiring managers need to rely on coding interviews to asses the skills and general cognitive ability of candidates.

I have heard of interview processes that don't involve coding, but I would venture to guess that such a process yields unreliable results.

Source code itself is just text so it can easily be forged. Ones ability is too opaque when looking at their credentials, past work experience, and references. Anyone can lie about those things and have fake references if they really wanted.

It's too much of a gamble to just go by someone's word.

While it's common to actually have to code during an interview process in one way shape or form, there are variations to how this occurs. The various forms of programming as part of an interview process that I have come across are:

• White board programming
• Coding in an online collaborative editor (So the interviewer can see the code you're updating in real time)
• Pair programming with an engineer from the company where you're applying
• Take-home coding assignment
• Paid trial project (essentially a short-term contract work that spans several weeks to see what it would be like working together)

I think each of these target specific skills and favors specific preparation methods over others. While all of them are designed provide signal into whether a candidate can actually solve problems with code, each one has varying levels of human resource cost and effectiveness.

There is nothing more "real" than live coding.

Live coding typically is made up of a series of 45 minute interviews (one or several,) or one longer interview (60 minutes, 90 minutes, or even longer.) White boarding, using an online code editor, or pair programming are all variations of "live coding".

Live coding is by far the most "real" signal in that the candidate can't fake their presence in a live interview and has no alternative but to solve the problems being asked to show their skills. These types of interviews typically favors individuals that are well prepared for the categories of problems that the interviewer will be asking. The questions given are usually small coding challenges that has their solutions rooted in well-known algorithms. These questions are more commonly referred to as "toy problems".

It's also common to be given a question that is reflective of some real-world problem in the domain that is relevant to the job but is appropriately scaled down to be solvable in the allotted time. Another type of problem you may see for live coding is some actual working code with bugs to fix or be asked to implement something using the technologies that the job requires.

Live coding works because it is a complete microcosm of the candidate performing the problem solving process.

For example, Google uses a recruiter call, technical phone screen, followed by 5 onsite interviews (now all virtual due to the global pandemic,) to evaluate a candidate before moving forward in the process.

All of the interviews are typically 45 minutes in length, and the technical phone screen and 4 out of the 5 onsite interviews involve live coding where the candidate is asked to solve one or several problems to help provide signal into whether they have a strong foundation in data structures, algorithms, communication skills, ability to respond to feedback and a challenging problem, discuss trade-offs between algorithmic choices, and the like.

White Boarding

The white board interview, where you write code by hand on a white board, has some advantage and disadvantages.

1. It strongly favors those who have prepared by practicing coding on a whiteboard because this activity is rather foreign when coming from a world where you are simply inputting text with a keyboard into an editor.
2. Because there is some friction to begin coding on a whiteboard (it's just literally not as easy as moving your fingers on a keyboard,) it can promote discussion of how to solve the problem using one's theoretical understanding of the problem before actually writing any code.

The biggest disadvantages to the whiteboard is

• Unrealistic of a real working environment – this is generally not how people actually get their work done.
• It is impractical in today's remote work climate.
• It obfuscates the candidate's actual efficacy working on a keyboard.

That being said, the candidate's efficacy on a keyboard is not a great signal on their general cognitive ability, so all-in-all, it's a fine way to assess someone's problem solving ability using computer science related knowledge.

Coding in an editor

Coding in an editor negates the two disadvantages of white boarding interviews since it's well suited for virtual interviews and it uses related tools (keyboard and some bare bones editor) to actually doing the job, making the signals from the interview closer to what you would see if the candidate were actually coding on the job.

From a candidate's perspective, algorithmic mistakes are less costly in the in-editor interview because you can delete and move code around quicker. This makes it more likely for candidates to begin by "putting something in the editor" to get their juices flowing.

For the most part, I'm receptive to this approach and don't dock points on this when evaluating, but I am wary of someone that pursues the coding part of the interview without any discussion of the algorithmic underpinning to the solution and the trade-offs between different algorithms that solve a problem.

The disadvantage of the in-editor interview is that it promotes coding over abstract discussion around the theory behind a problem, but some would say that this is precisely the advantage.

As for me, despite me seeing this as a disadvantage, I still prefer the in-editor interviews as it's usually the most comfortable way to perform an interview for a programmer – in an editor, actually coding, as opposed to writing on a white board.

One of the foundational principles to good interviewing is to make the candidate as comfortable as possible as nerves can really get in the way of someone's abilities to problem solve, and I think the in-editor interview does this better than using a white board.

Pair Programming

Pair programming is a variation on the in-editor challenge where you and your interviewer are coding together to solve a problem. Pair programming typically involves one person "driving", inputting the code, and another person is the "observer", providing commentary and looking out for any mistakes in the process.

I have done some version of pair programming in an interview where the interviewer was making comments regarding my code as I proceeded to implement something using technologies that the job requires. It was mostly an enjoyable experience because I actually got signal on what I was doing right/wrong throughout the interview and had opportunities to adjust accordingly based on my interviewer's feedback.

The expectation of being able to go back and forth in the interview about the code and design trade-offs felt a lot more like working with someone rather than a one-way performance for the purposes of being evaluated.

The Take-home Coding Challenge

The take-home coding assignment is usually given by employers before an employee has the opportunity to step in the door for an onsite interview. This way, the employer has a semi-reliable signal (as long as the candidate actually wrote the code on their own,) whether the candidate can code or not and what the quality of their work is like.

In theory, this is an effective way to see how the candidate codes but I've seen mixed results in actual practice. This approach has one fatal flaw and that is that the effort it takes to give out these assignments is low but the effort it takes to complete them is very high (the coding challenges are typically non-trivial, as if it's too easy then it doesn't provide good enough signal.)

It's easy to give out these coding challenges, so employers often give them out like candy to help screen out candidates that aren't willing to put forth the work, but the candidates who are busy interviewing at multiple places that have potential leads at other companies simply don't have the time to do very many of these coding challenges for several companies simultaneously.

This leads to selection bias amongst the people who are submitting these completed challenges. The bias makes it so that only the people who have enough time to complete the challenges will, instead of the most competent people.

There's also the logistical problem of the employer being in a bind after enough take-home challenges are submitted and now needs to evaluate and extract all of the qualitative signals from each completed assignment. Every teacher knows that grading homework assignments is not something to be underestimated.

In my opinion, the only realistic way to conduct these homework assignments that is both beneficial to the prospective interviewer and employer is to use the take-home challenge as a supplemental homework to be completed before the on-site interview. This opens up a discussion about the code written during the in-person interview and also gives the interviewer more concrete signal than just a single live interview session.

Filtering candidates based on whether they complete the take-home assignment or not is asking the interviewer to make too much of an investment and swings the effort-to-potential-reward pendulum too far in one direction to make the process fair and mutually beneficial to both parties.

The Paid Test Project

A paid test project where the company pays the potential employee for a short duration is the best way for employers to increase the probability that the interviewer will be a good hire for the company.

1. The interview process is lengthy and provides plenty of opportunities for meaningful signals, like what it's like to actually work with the candidate and the quality of work that the candidate is able to produce.
2. The candidate is paid so the employer is signaling to the candidate that they respect the candidates' time and are invested in the outcome of the interview as much as the candidate is.
3. The spirit of the interview is rooted in one of accurately determining whether the candidate will be a good match for the company in the long term, not whether the candidate is good according to some generic criteria for the type of engineer they are looking for with the hope that it works out long-term. This intent is clear up-front and both the candidate and interviewer have ample time to back out if things don't work out.

After all, a hiring decision has to be mutually beneficial to both employer and employee to produce a meaningful result, and this process respects everyone's time. It just happens to also be the most expensive in terms of time and money for the company as it takes a while to get to a final hiring decision.

If a company can afford to do this, or rather if a company can't afford to make the wrong hire, then this is by far the best type of interview for creating an ideal outcome.

Conclusion

So there you have it – the 3 different types of software engineering interviews

• Live coding (whiteboard, online editor, and pair programming)
• The take-home coding challenge
• The paid test project

In a nutshell, the paid test project takes the cake for being my personal favorite, both as an interviewer as well as the interviewee. There's more signal being provided, the interviewee's time is respected, and it's a win-win for everyone.