Coding Challenges in Interviews are a Loss for Recruiters

Coding Challenges in Interviews are a Loss for Recruiters.

I had a recruiter ask me for an interview for a frontend position, and the first technical question I got asked was to flatten an array. Live.

Live coding challenges are fun, that is true, but they are not qualifiers for whether a candidate should be hired or not. But they are certainly better that take-home unpaid assignments, much better.

Now, I was able to flatten the array pretty easily since I’ve done it before, but many of my sassy boys probably can’t if they haven’t done it before, and that’s completely fine as that’s how coding works. You learn things by doing, you get better at solving a problem by solving the problem, and recruiters do not understand this.

Recruiters, for some reason, love coding challenges and base a candidate’s whole persona based on their performance in a live coding challenge. I do not think this is a good strategy in any way nor beneficial to either parties.

The reason being that you can train anyone to solve coding challenges efficiently and still be a loser in real life problems. You can have 500+ challenges under your LeetCode profile and still not know how to be a good communicator, how to be a team player, how to keep your shit together when times are harsh.

Instead, interviews should test a candidate’s overall adaptability to the team they’re being hired for. This is where things get interesting. Those teams are mostly so disconnected that the recruiters have no idea what it’s like for developers in there and vice versa.

Now, I wish it was only the non-technical people who made this mistake, but it’s not. I was asked by the technical CTO of a team, for a totally UI-oriented frontend position, to solve a LeetCode hard.

Ofc, I got rejected.

I got rejected because LeetCode hards are unlike any challenges you’ve ever encountered, and it takes a deep understanding and multiple hit and trials to get them right, which is not something you can do in an interview.

Now, I do not mean to say that coding challenges aren’t beneficial, they sure are, but real life coding jobs are much more than just writing code. Matter of fact, these jobs are more about reading others’ code, communicating with clients, and finding solutions than writing code.

Here’s what I usually do when I get to interview someone:

• I make sure to have a sure understanding of how the team behind me works.
• I then ask the candidate workflow-specific questions that tell me if they’re a good fit for the team.
• When it comes to technicalities, I prefer a generally better coder than a “Specialized in such and such” guy.
• This allows me to ask them general coding questions about performance and code quality.
• I always ask one technical question that’s so easy to answer yet many fail to do so.
• I ask them to make this bit of code more performant. This tells you enough about a programmer.

const foo = ‘bar’;

if(foo == ‘bar’) {
  console.log(foo)
}

Btw, you can schedule a mock interview with me here.

To wrap up, recruiters need to sit among the developers more and companies need to give their interview strategies a side-eye and then take steps to make them better for everyone, not just for the recruiters.

---

I debunk myths and share insights about the frontend development world, join me as I build a community of Sassy Frontend Developers.

If you found this post helpful, consider sharing it and following me Kashan Ahmad for regular updates.

I also post my thoughts on:

• X: https://x.com/thekayshawn
• LinkedIn: https://linkedin.com/in/thekayshawn