A Freelance DevOps doing container stuff and automating unhealthy amounts of software.
Need something automated or containerized? Feel free to hit me up :)
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.
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.
A Freelance DevOps doing container stuff and automating unhealthy amounts of software.
Need something automated or containerized? Feel free to hit me up :)
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.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
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 :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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'ssort.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.
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.
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.
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 :)