{"id":1572,"date":"2021-05-03T22:00:53","date_gmt":"2021-05-04T05:00:53","guid":{"rendered":"https:\/\/coderpad.io\/?p=1572"},"modified":"2023-05-03T07:22:51","modified_gmt":"2023-05-03T14:22:51","slug":"5-tips-for-tech-recruiting","status":"publish","type":"post","link":"https:\/\/coderpad.io\/blog\/interviewing\/5-tips-for-tech-recruiting\/","title":{"rendered":"5 Tips for Better Tech Recruiting"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

This can be done in many ways, but let\u2019s talk about a few today.<\/p>\n\n\n\n

Don\u2019t Be Afraid To Help<\/h2>\n\n\n\n

Something to keep in mind while interviewing candidates is that they\u2019re 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

This is particularly beneficial for junior engineers, who\u2019s interviews should focus more on \u201cthought process\u201d and \u201cability to learn and communicate\u201d than existing skill sets. However, even senior engineers can have the solution escape them until it finally clicks with some small assistance.<\/p>\n\n\n\n


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\u2019t (and shouldn\u2019t) be working in isolation. Instead, they will have a team to lean on. By giving a small hint here and there, you\u2019re able to understand how they receive feedback and when they need help.<\/p>\n\n\n\n

Allow for Resources<\/h2>\n\n\n\n

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 we\u2019ve heard from seasoned developers that research and cheat-sheets are part of their daily engineering work. <\/p>\n\n\n\n

While it might not be immediately obvious, knowing how to search for and find the relevant content is incredibly important. Not only that, it\u2019s something that\u2019s developed gradually alongside a developer\u2019s journey – just like any other skill.<\/p>\n\n\n\n


After all, the point of coding interviews as part of tech recruiting is to see how capable a developer is at the job they\u2019re applying for. You want to test in real-world situations, not in an isolated environment that doesn\u2019t represent the daily aspects of the job.<\/p>\n\n\n\n

Less Algorithms, More Demos<\/h2>\n\n\n\n

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\u2019m going here? I\u2019m not implying that algorithm questions are inherently bad for every position, but in this industry they\u2019ve been used as a stop-gap for more relevant questions. This is the number one complaint I’ve heard against most tech recruiting.<\/p>\n\n\n\n

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. <\/p>\n\n\n\n

Even when algorithms are<\/em><\/strong> relevant, there\u2019s 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.<\/p>\n\n\n\n

Not only are these questions rarely representative of the actual job, they\u2019re also easy to cheat with someone with enough free-time to dedicate towards algorithm memorization. Googling \u201cinterview algorithm questions\u201d provides over 17 million results. Even the first page of results promises to teach you how to instantly solve dozens of common algorithm questions.<\/p>\n\n\n\n

Not only is possible cheating unhelpful in reflecting a candidate\u2019s problem solving skills, it actively biases your results towards those who\u2019ve put more time into interview prep (which may discourage those who\u2019ve 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.<\/p>\n\n\n\n

Even with all of this, I\u2019m only scratching the surface of the issues with algorithm-based \u201cwhiteboarding\u201d interviews that\u2019ve been written about before<\/a>.<\/p>\n\n\n\n

Fixing the Problem with Tech Recruiting Questions<\/h3>\n\n\n\n

That said, interview questions are important, so what should we be replacing these algorithm questions with technical assessments?<\/p>\n\n\n\n

Ideally, we should be asking questions based in the real-world. For example, if you\u2019ve got an older class-style React codebase that is being rewritten into functional hooks components, let them do that for the interview!<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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?<\/p>\n\n\n\n

Take-Home Projects<\/h2>\n\n\n\n

We at CoderPad are strong<\/em><\/strong> advocates of take-home projects<\/a> for technical assessments. While we\u2019ve written about many of the benefits of take-home projects before<\/a>, we\u2019ll touch on some of the advantages here:<\/p>\n\n\n\n