I understand your criticism of the premise, but I think the scenario is not unthinkable. I didn't won't to define the things you mention on purpose.
I guess I could have worded the scenario in a way that there's this super important part of your code that management wanted to get right. 5 devs created their on versions and you're on a board to choose the best one and give feedback to the devs.
And yes, all 5 of them return the right result, but they don't perform the same. I could have added some performance hints but it would have taken away a bit of the fun. I think it's easy to see that #4 is the most elegant, but it's not among the better performers. ;)
In the real world, I usually understand the constraints I'm facing when I write a piece of code. I know the code will need highest performance or I've come back to rewrite it because perf was a problem. By default I assume maintainability is highest priority. The last sample might be a valid starting point if I need to explain how I got results. There is no "best" solution without knowing the constraints.
Asking for a solution without telling the person the constraints you need, and then judging them on those constraints, seems like it will miss the point of finding great developers. Besides if perf was really important the dev would use an imperative solution. I recall seeing a video where an Apple engineer used the sieve as performance justification of why they made Swift an OOP language instead of a FP language. Fortunately F# is multi-paradigm so we can choose the best one for the job.
Edit: Sorry for obsessing. I observe this kind of process used in hiring quite a bit nowadays, and it irks me. I assume the setup in the article was fictitious, so my complaints are probably a bit misplaced here. 🤐
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.
Thanks a lot Kasey!
I understand your criticism of the premise, but I think the scenario is not unthinkable. I didn't won't to define the things you mention on purpose.
I guess I could have worded the scenario in a way that there's this super important part of your code that management wanted to get right. 5 devs created their on versions and you're on a board to choose the best one and give feedback to the devs.
And yes, all 5 of them return the right result, but they don't perform the same. I could have added some performance hints but it would have taken away a bit of the fun. I think it's easy to see that #4 is the most elegant, but it's not among the better performers. ;)
In the real world, I usually understand the constraints I'm facing when I write a piece of code. I know the code will need highest performance or I've come back to rewrite it because perf was a problem. By default I assume maintainability is highest priority. The last sample might be a valid starting point if I need to explain how I got results. There is no "best" solution without knowing the constraints.
Asking for a solution without telling the person the constraints you need, and then judging them on those constraints, seems like it will miss the point of finding great developers. Besides if perf was really important the dev would use an imperative solution. I recall seeing a video where an Apple engineer used the sieve as performance justification of why they made Swift an OOP language instead of a FP language. Fortunately F# is multi-paradigm so we can choose the best one for the job.
Edit: Sorry for obsessing. I observe this kind of process used in hiring quite a bit nowadays, and it irks me. I assume the setup in the article was fictitious, so my complaints are probably a bit misplaced here. 🤐