←back to thread

Please stop the coding challenges

(blackentropy.bearblog.dev)
261 points CrazyEmi | 2 comments | 15 Nov 24 15:32 UTC | HN request time: 0.4s | source
Show context
braza ◴[15 Nov 24 16:14 UTC] No.42148226[source]▶
I had a very bad experience at a company that did not conduct any coding tests; there were just 2 or 3 interviews, and that was it.

The issues began when we started working together in a Data Engineering team. Most of our stack was based on Hadoop, Kubernetes, Ruby, Python, and several other technologies that required a basic understanding of cloud computing.

However, since we had such a wide range of work experiences and backgrounds, I often found myself not doing the work I was hired for but instead covering for others. I ended up doing a lot of "glue work" to compensate for the fact that some colleagues couldn’t even handle basic tasks, such as Python CLI packaging using Docker or inspecting jobs in Hadoop. After some time, I decided to leave—not because I thought I was special, but because I was fed up with spending 80% of my time providing support for people who were hired at the same level or even higher than me.

I recognize that the company had very poor hiring practices, but some form of basic technical testing is necessary.

replies(1): >>42148427 #
1. fluoridation ◴[15 Nov 24 16:33 UTC] No.42148427[source]▶
When you say they "couldn't even handle basic tasks" do you mean they were completely unfit to complete their assigned tasks, or that they were getting hung up on simple tasks, while otherwise being independent and capable? The other key question is whether you had to explain the same things to the same people again and again. Being ignorant is excusable, but being unwilling to learn isn't.
replies(1): >>42149203 #
2. braza ◴[15 Nov 24 17:53 UTC] No.42149203[source]▶
> they were completely unfit to complete their assigned tasks, or that they were getting hung up on simple tasks

They were unfit to complete the tasks. But again was not their fault, I think was the hiring that failed.

One concrete example was the fact that our pipelines was quite straightforward for data engineers: packaged Ruby and Python CLIs that runs commands. The runtime was k8s. One of the biggest issues were when something broke in production, none of the people couldn’t go to the container, check the logs and understand the failure.

There’s one situation where I think makes sense to hiring without a test: if the company has the resources and money to provide levelling training for all new hires with no exceptions. I do not know how practical it is.