DEV Community

loading...

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

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.