I had a chance to review some tech challenges submitted for developer positions of various seniority in my company. The challenge is to write a simple

You probably don’t want that concurrency for speed in Go

submited by

Style Pass

2021-05-25 14:00:12

I had a chance to review some tech challenges submitted for developer positions of various seniority in my company. The challenge is to write a simple command line utility program, and was in Go. I won’t disclose the details, but it involved iterating over multiple “things” and do something with each.

What surprised me was that so many applicants used concurrency for the challenge, in the effort to parallelize the works. The challenge didn’t ask to optimize for the best runtime, and definitely didn’t ask for parallelism (although we left most of the direction to the applicant’s liberty). This made me wonder, “why is this happening?”.

If the challenge were in Python, would they have used multiprocessing or asyncio libraries? If it were in Java, would they have used ExecutorService? I’m no expert on those languages, but I doubt that.

From the psychological perspective, I could actually understand them. Concurrency is a relatively advanced concept, even in Go, and we better express our knowledge in a tech challenge, right? :) I have also been on that side in the past, and I was also thrilled to have learned such elegance in Go. Unfortunately, it did the opposite of impressing me in this case.