[baobabKoodaa]

> In this example, the missing skillset is not memorizing a book of algorithms as you seem to imply.

No it's not. As I said in the sibling comment, competitive programming (or algorithm skills in general) isn't about memorizing algorithms, it's about developing skills that allow you to understand and create algorithms to solve problems. In this case, it would be sufficient to understand why looking up a phone number in a phone book should inherently be a O(log n) operation, not a O(n) operation.

> I don't want to hire software engineers who have memorized the algorithm book, that's not useful to me. I want to hire those who can apply discipline to the work, such as (in this example) be aware of performance and know how to analyze it and find solutions.

So we're discussing a hypothetical developer who has "no interest towards algorithms", and you're imagining that this person is going to run a profiler to troubleshoot a performance issue and subsequently optimize algorithms to fix said performance issue? This sounds like a fantasy to me. If you want skilled software engineers who have the ability to troubleshoot and optimize algorithms, you probably need someone who has some kind of interest towards algorithms.

[jjav]

> So we're discussing a hypothetical developer who has "no interest towards algorithms", and you're imagining that this person is going to run a profiler to troubleshoot a performance issue and subsequently optimize algorithms to fix said performance issue? This sounds like a fantasy to me.

Our experiences are vastly different then. Nothing fantasy or hypothetical about this. Every great software engineer I've worked with is like this.

Profiling and identifying hot spots is an every-week occurrence in the field, very pragmatic and valuable work. Theoretical algorithms only happen on interview whiteboards, not on the job.

[baobabKoodaa]

You're arguing that someone who doesn't care to learn anything about algorithms is going to do a good job at optimizing algorithms.

[jjav]

No, not at all!

I am saying that being able to regurgitate an implementation of quicksort (to keep on the sorting example) onto a whiteboard is not a useful skill. There will never be a need to do this in a real life job.

The truly useful skill is being able (and interested!) in using a profiler to find bottlenecks, identify what is being done there (let's say, sorting) and being able to find a better replacement algorithm in the literature and change to code to use a well-optimized implementation (which exists already in just about every ecosystem, no need to reimplement it from memory).

[baobabKoodaa]

> I am saying that being able to regurgitate an implementation of quicksort (to keep on the sorting example) onto a whiteboard is not a useful skill.

In that case I'm not sure why you're arguing against me, because I've repeatedly expressed my dislike towards algorithm memorization. I don't believe memorizing algorithms is useful at all. It might give a very small edge in competitive programming, but it's not what competitive programming is about either. The best competitors have amazing skills at creating algorithms to solve problems ("create" as opposed to "memorize").

If you look up the parent thread, you started arguing against me when I said "Developers who have no interest towards algorithms will not [be good at some things]".