DEV Community

Cover image for Programming isn’t about being right but fixing what is wrong.
Bruno Noriller
Bruno Noriller

Posted on • Originally published at linkedin.com

Programming isn’t about being right but fixing what is wrong.

TLDR: Automated hiring doesn’t test what you’re actually looking for.

What do we, programmers, spend the most time with?

All meetings aside, is it with programming new things from zero or giving maintenance and new features to “old” systems?

When you start from zero, you don’t need to “care” about anything.

You just need to code and hope it works.

When you’re working with anything else, you need to know what you’re doing.

More than making new or old things work, you’re trying to make sure you don’t break anything.


“Automated hiring” isn’t that automated

I mean, so far I’ve never seen one process that is 100% automated, you always have to take the human factor into consideration.

I understand using tools like Hackerrank to filter people, some big companies must receive thousands of applications and you can use that to start somewhere.

Barring that, what do coding challenges actually do?

Code quality, tests, debugging, working with legacy code, the why of something... none of that matters, all that matters in the coding challenge is passing as many tests as possible.


Is there an alternative?

That’s why I started with: Programming isn’t about being right but fixing what is wrong.

And to fix what you have to know and understand what's happening.

So here’s some food for thought: the good ol’ open-ended questions.

Questions about code snippets

  • What could possibly cause an error when you pass such and such value?
  • This code takes too long to run... can you tell me why?
  • What would you test in this function?

Questions about important concepts

But not those that you need to give the textbook definition.

  • Why use one thing over the other?
  • Given this scenario, what are the possible advantages and disadvantages of the decision?
  • What is, and why, the best data structure for a podcast playlist?

With open-ended questions, you can test more than just code. And allied with an interview, you can certainly learn more about a programmer than just from the few lines of the code challenge.

And before you ask, no, multiple-choice questions can be even worse than coding challenges! They test that you can mark exactly what the programmed answer is, be it by actually knowing or by luck. They test that you decorated a lot of stuff that is more important that you know how to use than the actual name.

Wouldn’t it take too much time from the company?

No!

Coding challenges are easier for both sides, sure.

But if that’s the only filter, the next step usually takes someone talking with them, probably for an hour or more... And wouldn’t you say that reading through the answers takes far less time than that?

Not only that, the answer sheet could be the first thing the recruiter sees, and then if the answers are good, then you, a human, check the resume.

Far too many places rely on scanning resumes and end up finding people who are good at showing what the machine wants to see while declining people who could be a better fit.

The only thing you could say is that it does take more time to come up with... but it does come with the advantage of asking about things that are important to the role you’re hiring.


Your turn, what do you think? What were your experiences?

As for me, few and far between, but I believe I did have some interactions like that, but more than that... I had interviews where I had to do just that! To answer open-ended questions.


Cover Photo by Ben Mullins on Unsplash

buy me a coffee

Oldest comments (0)