Understanding the Technical Screening for Software Engineers

The technical screening phase of the interview process has always been a debated subject. No one can agree on what the best strategy is for screening candidates. We must understand why this stage in the process is necessary however. Software engineers are paid very well for their time and experience. And most highly paid jobs do have screening some process to filter out people that can talk the talk, but can’t walk the walk. This is a safety precaution for companies.

Why is the Technical Screening So Important?

The company has to pay your salary, and benefits. And they also pay your taxes as well. So a single software engineer is a very large expense for a company, much less an entire team or organization. The largest expense for most companies is payroll. So companies have to ensure that they’re not wasting their time or money.

You also have to understand that both hiring and replacing a person is very expensive. Just hiring a new engineer can reach up to $50,000. And replacing a software engineer can cost a company up to 1-2x their salary as well. It’s not just the salary and benefits of the new person. It’s the time lost in productivity, meetings, screening people, discussions, negotiations, onboarding, and more.

With all of that in mind, we agree that it’s crucial that companies find the right person for the job. And that requires diligence in the screening process for hiring engineers. You simply can’t take the resume as fact and hire someone. There’s the whole process of evaluating fit, and soft skills. But the person has to do the work too. Teams, peers, and companies need that person to be productive.

What Options Exist to Evaluate Engineers?

There are many options companies can use to dive into a person’s technical capabilities to see if they’re a good fit or not. Not all are good, and many are misused.


Leetcode is essentially an online tool to quickly assess someone’s ability to understand and use data structures and algorithms. You are given 1-2 short problems and are given a small timeframe to solve the problem and meet the requirements. This can fortunately be done in the interview timeframe itself. And many people opt to screenshare and watch the candidate work. This is the most pervasive option right now.


  • Easy for companies to implement
  • Easy for candidates to study. Just grid leetcode exercises.
  • Short timeframe
  • Moderately gives you an understanding of the person’s ability


  • Most questions are odd and not close to reality of what the person does on the job
  • The candidate is in a stressful situation to understand the requirements, build the solution, and complete the work in a really small timeframe, while being watched by someone
  • Has the risk of candidates studying solutions and have already completed the exercise given, obscuring the results
  • Have to use the website and their UI and tools to write the code, so you don’t have the luxury of using the setup that most engineers configure for themselves to work optimally

Take-Home Exercise

In this scenario, a candidate receives an assignment to complete independently over several days. Typically, these assignments entail a larger scope of work compared to a typical LeetCode question and are completed outside of an interview setting. However, this approach is also flawed as it is often misused and misunderstood. Many companies underestimate the time required, claiming it will only take a few hours when in reality, it takes days to complete. To produce work that impresses the hiring panel, candidates must excel in communication, documentation, testing, code coverage, proper abstraction, attention to detail, and other essential aspects.


  • Provides the candidate an exercise that would be the most realistic to their actual work. It would include “real” requirements, and they work on their own time, with their own setup.
  • It’s not done within the stressful situation of an interview, and no one is watching you work
  • The candidate has the luxury of time to think about the solution, and ask questions


  • Most of the time the scope of the exercise is too large. I’ve personally built exercises that took me days because I was building end-to-end solutions and custom UI with high test coverage, and more when the instructions said it’d only take 6 hours. I’ve also been given requirements to build a whole product and the company said it’d take weeks to build.
  • It’s a large time-sink for candidates, and they must use their personal time to do it
  • Most of the time it’s unpaid
  • If the candidate has multiple interview processes happening, it could be too much to balance
  • It’s more work for the interview panel as well to communicate with each candidate, and then carefully review each submission

Lengthy Technical Interview

Another option is to simply have a lengthy technical call with someone. This is where you’d ask DSA questions, probe their experience in debugging something complicated, ask about classes and APIs, and more. The difficulty is that each person is unique, so you’ll get varied answers. And there’s way to much to possibly cover in a realistic interview timeframe, which is usually an hour. And it’s difficult to avoid it simply being a Q&A session and not really an interview where you have a proper conversation with someone.


  • Less demanding of everyone’s time
  • Easier to prepare for the hiring panel. You can simply have a sheet with questions and follow-ups and go down the list


  • You’re more likely to get bad candidates this way as it’s too difficult to properly evaluate someone with the breadth and depth required
  • Without careful planning, you end up with people recommending to hire or pass based on gut feelings and reactions instead of objectiveness
  • Easier for the candidate to study for. They can usually simply study common questions and answers, which there many lists out there, and likely cover most of what the panel will ask
  • In general has the highest risk for bad hires

What Should You Do When Screening Engineers?

Most engineers consider whiteboarding sessions and a 1-2 week trial period, where the candidate works on-site, as the worst choices. Engineers do not typically utilize a whiteboard in their regular job tasks as they would in an interview setting. Trial periods pose difficulties for all parties involved. If the person cannot quit their current job for the trial, the company needs to arrange accommodations for their existing employment. Additionally, the company must address considerations such as hardware provision, task assignments, collaboration arrangements, and legal requirements. Determining the appropriate compensation and establishing clear metrics for success or failure are essential. Overall, there are too many barriers for this option to be feasible.

As you can see, there’s no perfect answer. That’s why we’re in the state that we’re in. However, my personal recommendation is simple: Ask the candidate what they prefer out of your preferred options.

This will enable you to work together with each candidate and still strive to get what you need. Whatever you and your team chooses to do, at least acknowledge what you’re doing and why you’re doing it. And communicate it clearly to your internal hiring teams and the candidates.