Technical Assessment Best Practices

Of all the phases of the interview process, technical skills assessments are perhaps the most universally feared by candidates. No one likes an audition, and even the most seasoned candidates worry that they might choke when asked to demonstrate their skills beneath the pressure of a ticking clock. What’s more, coding assessments are often poorly aligned with both the requirements of a job and the experience of the candidates under review. Why would you test a candidate on a skill they most likely haven’t used since they were in college?

A poorly designed technical skills assessment can fail in two ways:

  1. It can fail to judge candidates appropriately, filtering out your most talented applicants while admitting those who have memorized certain skills by rote.
  2. It can demoralize your most talented applicants. Even if their skills are correctly measured, a long, drawn-out, and grueling process can cause candidates to decline their job offers.

You want to make sure that your best candidates rise to the top of the pile—and you want to make sure that they’re eager to accept their job offers once they make it to the top. Here are some best practices to ensure that your next round of coding assessments achieves both of those objectives.

Why are technical skills assessments important

Coding assessments serve two purposes. First, they’re designed to make sure that the skills on an applicant’s resume are the skills that they possess. In other careers, some candidates win out over more talented applicants because, for example, they went to the same college as the CEO. If you’re doing a coding assessment correctly, however, a candidate’s ability to network becomes less relevant.

Coding, like playing an instrument, is a talent that is sometimes disproportional to one’s level of education—a graduate from a 12-week code boot camp might have more coding skill than a graduate from a four-year university. When properly conducted, the technical skills assessment represents a level playing field where true talent—divorced from one’s background, upbringing, and personal connections—can shine unencumbered.

This is where the next purpose of the technical interview comes into play. You don’t just want to identify who the most talented candidates are—you’re not conducting the SAT, after all. Rather, you want to make these people want to work with you. This means ensuring that your technical assessment challenge appropriately reflects the reality of their everyday work, providing examples of the problems they’ll face and the tools that they’ll use. A candidate who navigates the technical skills assessment with aplomb should leave excited about the career they’ll soon enjoy.

Technical Assessment Process

We recommend that a technical assessment should proceed in four phases.

First, you should cast a wide net. Your recruiters will funnel candidates your way, but you can also put public coding challenges on your website and social media pages. Anyone who solves these challenges moves forward in the hiring process. This helps you find talented candidates who may not have robust networks yet.

Second, you should conduct a basic phone screen. This will avoid all technical topics but should help you understand whether your employee will be a fit for your organization. Because a technical interview can be a bit in-depth, it can help to screen out candidates whose personality, experience, or salary expectations might make them a mismatch for your team.

Third, the technical questions begin with a technical phone screen. This is a simpler interview that lasts between 30 minutes and one hour, and should involve a collaborative coding session on a technical interview platform. The problems should be difficult enough to screen out people who are lying on their resume, while still giving you a look into a candidate’s abilities and thought process within the allotted time.

The final “on site” interview will most likely take the form of another remote session but will involve a more complex set of problems. The idea here is to emulate a challenging workday, to the extent possible. Your candidate should be able to demonstrate creative solutions to interesting problems, collaborate with team leaders, and use the whole breadth of their skill set.

Many interviews aren’t necessarily up to this ideal standard. They test the candidate using inadequate tools (a whiteboard as opposed to the IDE they’ll be using at their job), they test for skills that aren’t relevant to job requirements, or they just take too long. What follows are a few remedies for these common errors.

Matching Technical Assessment to Skills Needed for The Position

When technical assessments are mismatched to job requirements, it creates annoyance for job candidates—and it increases the likelihood of a hiring mismatch. What’s more, not all hiring managers have years of technical skill. They might not truly know whether they’re administering a good test.

Ultimately, it’s important to build out a library of coding questions and challenges that are specific to your company, your team and the skill sets you need for success. Though you

may all use products similarly to other companies, you’re all different. Generic, canned, CS 101 questions won’t help you find or entice the talent you need to come work for you. Consult with your in-house developers to create a test that will reflect the realities of the day-to-day job. Then, use a platform that can be easily personalized (like CoderPad) to help you create an effective process and hire the best candidates for your team.

Technical Screening

Technical screenings are supposed to be short and simple. They’re designed to check whether a developer can do what they say they can do. Testing them on more challenging problems comes later. Ironically, this means that the biggest pitfall when it comes to creating a technical screening is making it too difficult.

For example, many interviewers force applicants to use a generic text editor, rather than a full-featured IDE, during a technical assessment. There’s no reason for this—they’ll be using an IDE during their day-to-day job, which means that they should be assessed using an IDE during their interview.

In-Person Vs Remote Interviews

It may be awhile before in-person interviews are back in fashion, but whether you’re in-person or remote, a second-round coding assessment can usually be expected to take a while longer and be more difficult than the first.

  • The interviewee will most likely report to more than one person if they’re hired, so they’ll be interviewed by more than one stakeholder
  • The questions should be less generic and more focused towards what the applicant will be doing in their day-to-day role.
  • Hiring managers should consider a more tailored assessment, one that takes the applicant’s background and previous projects into account—especially when hiring for higher-level jobs.

Almost every applicant in the tech space has a horror story about an interview that was totally disconnected from the position they were hiring for. Don’t be that company. Bad interview stories can circulate a lot faster nowadays, and they will absolutely dissuade top-tier talent from applying to your company.

Technical Assessment Tools

Your technical assessment tools can be as simple as a text editor and a whiteboard, or as complicated as a full-featured IDE. We strongly recommend the latter.

IDEs are the way that software developers work. Developers may have trained using simpler tools, but they use IDEs in their professional careers. Basically, forcing an applicant to use a text editor or a whiteboard is a way to make an interview more difficult and stressful without revealing any useful information about your applicant.

Meanwhile, allowing your candidates to use IDEs will let them work faster and in a more relaxed manner. This can shorten a grueling interview process while allowing you to understand how they’ll use the tools you provide in their day-to-day jobs.

Candidate Experience and Giving Feedback

Lastly, one thing that applicants complain about is the radio silence that often ensues once the interview process is over. Nobody likes being left in limbo! After the coding assessment is finished, interviewers can differentiate themselves by giving even a small amount of feedback along with their job offer or letter of regret. By making the interview process more positive—even for failed applicants—you’ll gain positive word of mouth that will help you gain even more talented candidates in the future.