Post contents
Tech recruiting is difficult. Interviews are tricky for candidates - and for interviewers. One of the untold challenges of interviewing is knowing how to set up good candidates for success. After all, you want a process that tests the right skills, and filters out the noise that is not helpful to evaluating candidates.
This can be done in many ways, but let’s talk about a few today.
Don’t Be Afraid To Help
Something to keep in mind while interviewing candidates is that they’re just like you and me: people. People that make mistakes from time-to-time or might get stuck on a certain phrasing of a question.
Oftentimes, lending a gentle helping hand can be the ticket to a successful interview. It can be as simple as rephrasing the question in a way that points towards the solution, or providing a structural bit of code that needs tweaking in order to be solved.
This is particularly beneficial for junior engineers, who’s interviews should focus more on “thought process” and “ability to learn and communicate” than existing skill sets. However, even senior engineers can have the solution escape them until it finally clicks with some small assistance.
While this all might seem counterintuitive to assist a candidate (even in small ways) during an interview, you have to remember that they need support. In their future role with your company, they won’t (and shouldn’t) be working in isolation. Instead, they will have a team to lean on. By giving a small hint here and there, you’re able to understand how they receive feedback and when they need help.
Allow for Resources
As mentioned earlier, candidates are just people. Because of that, you will never find an all-knowing candidate who only ever relies solely on their existing knowledge to fix an issue (no matter what big-ego Jim says). Time-and-time again I’ve heard from seasoned developers that research and cheat-sheets are part of their daily engineering work.
While it might not be immediately obvious, knowing how to search for and find the relevant content is incredibly important. Not only that, it’s something that’s developed gradually alongside a developer’s journey - just like any other skill.
After all, the point of coding interviews is to see how capable a developer is at the job they’re applying for. You want to test in real-world situations, not in an isolated environment that doesn’t represent the daily aspects of the job.
Less Algorithms, More Demos
Speaking of representing a job in a more realistic light: think about the last time you had a ticket in your backlog that required discussion of tree reversal (or similar algorithm). Now think of the last time you asked a question like that in your interviews. See where I’m going here? I’m not implying that algorithm questions are inherently bad for every position, but in this industry they’ve been used as a stop-gap for more relevant questions.
Many engineers can attest to being asked algorithmic questions in an interview - only to be working with styling and application state management in their day jobs. The usage of complex algorithms are far-and-few between - especially in front-end engineering.
Even when algorithms *are* relevant, there’s usually a team to discuss with, research to be done, and benchmarking to verify the usage of a given algorithm for key application logic. These discussions can take significantly longer than an hour long interview.
Not only are these questions rarely representative of the actual job, they’re also easy to cheat with someone with enough free-time to dedicate towards algorithm memorization. Googling “interview algorithm questions” provides over 17 million results. Even the first page of results promises to teach you how to instantly solve dozens of common algorithm questions.
Not only is possible cheating unhelpful in reflecting a candidate’s problem solving skills, it actively biases your results towards those who’ve put more time into interview prep (which may discourage those who’ve been long-term employees for a single employer). It actively harms those with children or other time constraints that limit their ability to continually practice algorithm questions.
Even with all of this, I’m only scratching the surface of the issues with algorithm-based “whiteboarding” interviews that’ve been written about before.
Fixing the Problem
That said, interview questions are important, so what should we be replacing these algorithm questions with technical assessments?
Ideally, we should be asking questions based in the real-world. For example, if you’ve got an older class-style React codebase that is being rewritten into functional hooks components, let them do that for the interview!
In other scenarios, where styling is important to the role, you might want to provide a functioning app and ask the candidate to match an existing design.
While real-world code samples provide many upsides, setting up a real-world example may take a candidate a little longer to read through the code and orient themselves. How can we reduce the dead-air for interviewers and candidates alike?
Take-Homes
We at CoderPad are *strong* advocates of take-home interviews for technical assessments. While we’ve written about many of the benefits of take-homes before, we’ll touch on some of the advantages here:
- Lower stress environment for candidate
- We’ve heard a lot from the autistic community and those with anxiety that this helps a lot
- More flexibility and creativity in candidate solutions
- Removes biases
- Kills dead air while candidate is doing initial thought process of a problem
Level the Playing Field
As mentioned previously, time isn’t the same for everyone. Some folks look for work while they’re still working full-time for another employer. Those same people may have kids or other priorities in their lives. This makes time a rare commodity for some.
A good solution of this can be setting a time limit for take-home projects. However, if a time-limit is softly set and on the honor system, engineers may feel the pressure to go outside of that time-range to add “polish” in order to compete with other candidates. This places us back at the original problem without much done.
CoderPad allows you to limit the amount of time a candidate is able to spend in assessment. the interview pad Once the timer is done, the candidate is removed from the take-home and their work is submitted.
I encourage you to keep the time limit to 2 hours max. Any longer and you risk alienating the candidates without that much time to do assessments. Keep in mind - you’re likely not the only role that candidate has applied for.
Find Their Speciality
Not only do take-homes improve the balance of “stress” vs “capabilities” you look for in an interview, they also allow candidates with specialties focus on their strengths and show you what they’re most capable of.
Think about it this way: You’re hiring for a team - ideally a team should have a good balance of skills. Even in small-scale applications, there are lots of jobs to do: styling, internal documentation to write, code organization, boilerplate writing, application logic, testing, etc.. While it’s possible to have someone capable of doing more than one of these - it’s impossible to be a true universal expert at all of them at once. Engineers are likely to lean more in some directions than others. Don’t discourage this - it’s what allows a team of diverse people to build a better product through combined individual expertise.
Wrap Up
Most of these tips are meant to make your technical interviews more representative of real-world experiences and enable a more diverse pool of candidates to succeed in your process. I hope these tips help give you better insights into your candidates and enable a team that’s more well-rounded, ultimately bringing more value to your company and teams.
Hungry for more interviewing tips? Check out CoderPad's blog about 3 other tips for technical interviewing.