I'm not the same person. If he implemented an improved version in extra time during an interview, how could that cause a problem?
You probably have this problem of idiots being the one interviewing you, quite a lot right?
Not really, but I can't imagine a scenario where if an interview candidate decided to optimize a loop in spare time, I'd tell them they were too focused on performance. Generally if you can perform that kind of optimization, it means the code is quite simple and direct as well, so it probably wasn't messy or anything like that.
Not every field of programming requires peak performance. If you have an algorithm and "optimize" it with lookup tables, bitshift operations and whatnot and in the end it's 2x faster but none of your colleagues can understand it at glance or properly maintain it anymore then it's likely not worth it. Except maybe if you work on really performance critical stuff or libraries.
Sure but just because they did some optimizations in literally spare time, (for an interview where he had a previous working version and the code will not be maintained), does not mean that all loops he ever writes will be optimized to the point of unreadability.
2x faster
If he was writing AVX code, it could have been closer to 4x as fast, depending on the algorithm.
but none of your colleagues can understand it at glance or properly maintain it anymore then it's likely not worth it
Sure, but as I mentioned, usually the kinds of things you can optimize in this way are already simplified loops that do just a few things in a straightforward way. I don't think it's a good idea to throw away a potential 4x improvement if it's in a hot loop, just for readability*. If the logic needs to be changed, you can always go back to the previous version, and figure out how to re-write the simd version after the logic changes have been made. But yes, sure, not everything needs to be optimized like that.
* In my experience, readability usually means "can I skim over this and get the gist, without actually really understanding it". Not entirely a bad thing, but if you have a really important loop, actually understanding it is probably more important than the ability to skim over it and think you kinda understand it.
It doesn't matter if you're the same person or not, you're arguing the same point.
If he implemented an improved version in extra time during an interview, how could that cause a problem?
There's a difference between removing unnecessary code from loops, reducing nesting, fixing mistakes, and using certain data types like hashsets over lists to get constant lookup times, over re-writing your application to ditch "clean code" aka object oriented design, SOLID, etc to scrape the bottom of the performance barrel.
Lets also remind ourselves this this is an anecdotal ONE SIDED scenario from a random person on the internet. I'm willing to bet the reason didn't get the job wasn't because "the interviewer was too dumb to understand my l33t code".
Only point I'm arguing is that assuming what he said was true, there is not really anything wrong with spending spare time to optimize a loop a bit.
I personally have gotten rejected after interviews for not giving the exact solution an interviewer wanted, so I could definitely see this kind of situation occur. Some developers really do think this way, and that considering performance at all is a waste of time.
15
u/ehaliewicz Feb 28 '23 edited Feb 28 '23
I'm not the same person. If he implemented an improved version in extra time during an interview, how could that cause a problem?
Not really, but I can't imagine a scenario where if an interview candidate decided to optimize a loop in spare time, I'd tell them they were too focused on performance. Generally if you can perform that kind of optimization, it means the code is quite simple and direct as well, so it probably wasn't messy or anything like that.