5 Tips for Better Tech Recruiting

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 lets talk about a few today.

Dont Be Afraid To Help

Something to keep in mind while interviewing candidates is that theyre 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.This should never leave your mind while tech recruiting.

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, whos 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 wont (and shouldnt) be working in isolation. Instead, they will have a team to lean on. By giving a small hint here and there, youre 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 weve 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 relevantcontent is incredibly important. Not only that, its something thats developed gradually alongside a developers journey - just like any other skill.

After all, the point of coding interviews as part of tech recruiting is to see how capable a developer is at the job theyre applying for. You want to test in real-world situations, not in an isolated environment that doesnt 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 Im going here? Im not implying that algorithm questions are inherently bad for every position, but in this industry theyve been used as a stop-gap for more relevant questions. This is the number one complaint I've heard against most tech recruiting.

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, theres 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, theyre 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 candidates problem solving skills, it actively biases your results towards those whove put more time into interview prep (which may discourage those whove 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, Im only scratching the surface of the issues with algorithm-based whiteboarding interviews thatve been written about before.

Fixing the Problem with Tech Recruiting Questions

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 youve 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 weve written about many of the benefits of take-homes before, well touch on some of the advantages here:

• Lower stress environment for candidate
  • Weve 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 isnt the same for everyone. Some folks look for work while theyre 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. Good tech recruiting should take this into account and help level the playing field.

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 - youre 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 theyre most capable of.

Think about it this way: Youre 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 its possible to have someone capable of doing more than one of these - its impossible to be a true universal expert at all of them at once. Engineers are likely to lean more in some directions than others. Dont discourage this - its 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 tech recruiting 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 thats more well-rounded, ultimately bringing more value to your company and teams.

Hungry for more interviewing tips? Check out our blog about 3 other tips for technical interviewing.

Have more youd like to add? Join our Slack, where we talk about interviewing and programming. Were curious what your tips and tricks are!