DEV Community

Discussion on: What are your biggest frustrations in the hiring process?

Collapse
 
habereder profile image
Raphael Habereder

I for one absolutely hate "reinvent the wheel" questions. Like "implement a sorting algorithm to sort this array of numbers ascending". Great. In Java that would be array.sort(), in go it's sort.Ints(slice), and so on.

Why would I do that for an interview, if I wouldn't do it on the job? I just don't see the point of doing things that have been done by language engineers already.
It would be stupid to think that my "5-Minute-Algorithm" is better than theirs.
Let's just solve real problems..

This particular opinion cost me about a dozen interviews already, but I stand firmly behind it.

Collapse
 
anders profile image
Anders

The reason is most likely that they want to make sure you actually know how to code, not just how to cobble pieces of code that somebody else wrote together. Although the latter may be a relevant skill set in some roles as well ; )

When we hire though, we always do a work sample that is representative of what we actually want to achieve. That kinda feels like the best way to do it. But our work sample is quite time consuming, which is a big downside.

And I can see where they are coming from with that kind of question.

Collapse
 
habereder profile image
Raphael Habereder

Knowing how to learn, use and adapt an existing framework is, in most cases, many times more valuable than creating your own half-assed algorithm for a fake problem.
We are teaching DRY, KISS and many more paradigms of that sort, only to say "scratch that for a hot minute" in an interview. That is absolutely mind-boggling to me :D

Give people a real problem with real technological boundaries and see how they adapt and solve the problem. I don't care if someone can implement a bubble-sort or knows how HTTP internally works. It has zero practical value, since it can be memorized and mindlessly repeated on a whiteboard.

But if someone can take a look at <any framework>, one that is actually of practical value for you in the field, to solve a real problem? That's a keeper.

To be honest, when I look for employees, I don't even care if they "know how to code", as you called it. I want to know if they can learn. Knowing how to code today is easy, still knowing how to do it in years to come, that's important.

IMHO thinking "I can do better than <insert any Framework here>!" is wrong at best, and a waste of time and resources at the worst.

Collapse
 
jmfayard profile image
Jean-Michel πŸ•΅πŸ»β€β™‚οΈ Fayard • Edited

I also find it pointless. What I do in this case is that instead of showing my frustration, I ask calmly the question :

"I see. (Silence) Can we take a step back ? (Silence) (Yes, go on). What is your goal with this question ? What are you trying to achieve ?"

Then either a good answer comes or not. If they thought about it, I'm fine. If they didn't, they will remember it for next time and maybe do it differently :)