I was all ready to criticize the premise itself rather than the solutions. (For example, I could not give someone a poor rating if they used a mutable implementation. For all I know the interviewer did not make it clear whether maintainability or performance was a pre-eminent concern, so the candidate had to guess.) But after looking at the code, there appears to be a solid basis for comparison.
I did not test whether these have been verified to work. I'm assuming they have. My ratings are in order.
4 is the most easily understandable. There are some minor issues with formatting (i.e. lines too long).
To me, 3 and 2 are tied for 2nd, each for different reasons.
3 requires light math to understand how it deviates from the original the algorithm. So it will be slightly less readable. I doubt there will be any significant performance savings to offset that. Code may indicate an inclination toward math (to be verified by resume/interview) which might be desirable depending on the position.
2 is nice and brief, but the collection operations make it a slightly slower read versus what is expected based on the problem. The code hints to me that the developer is more advanced, but perhaps also "clever".
1 and 5 are overwrought for the problem at hand. I didn't bother to read through them.
None of these functional algorithms are going to be particularly high performing, so I didn't go into a comparison on that basis. It might be interesting to ask the candidates to write two versions of the algorithm: one focusing on ease of maintenance and another focusing on performance.
I should also note that I would probably hire any of the authors of any of these solutions, so long as I had a sense that they were good to work with. That is the far more important consideration for me. Programming skills can be honed much quicker than "good to work with" skills.
I should also note that I would probably hire any of the authors of any of these solutions, so long as I had a sense that they were good to work with. That is the far more important consideration for me. Programming skills can be honed much quicker than "good to work with" skills.
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.
I was all ready to criticize the premise itself rather than the solutions. (For example, I could not give someone a poor rating if they used a mutable implementation. For all I know the interviewer did not make it clear whether maintainability or performance was a pre-eminent concern, so the candidate had to guess.) But after looking at the code, there appears to be a solid basis for comparison.
I did not test whether these have been verified to work. I'm assuming they have. My ratings are in order.
4 is the most easily understandable. There are some minor issues with formatting (i.e. lines too long).
To me, 3 and 2 are tied for 2nd, each for different reasons.
3 requires light math to understand how it deviates from the original the algorithm. So it will be slightly less readable. I doubt there will be any significant performance savings to offset that. Code may indicate an inclination toward math (to be verified by resume/interview) which might be desirable depending on the position.
2 is nice and brief, but the collection operations make it a slightly slower read versus what is expected based on the problem. The code hints to me that the developer is more advanced, but perhaps also "clever".
1 and 5 are overwrought for the problem at hand. I didn't bother to read through them.
None of these functional algorithms are going to be particularly high performing, so I didn't go into a comparison on that basis. It might be interesting to ask the candidates to write two versions of the algorithm: one focusing on ease of maintenance and another focusing on performance.
I should also note that I would probably hire any of the authors of any of these solutions, so long as I had a sense that they were good to work with. That is the far more important consideration for me. Programming skills can be honed much quicker than "good to work with" skills.
I couldn't agree more :)
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. 🤐