This is a real problem in the industry IMO. You do not need to be a good algorithmist to be one of the outstanding programmers in most industries. You just don'

This is a real problem in the industry IMO. You do not need to be a good algorithmist to be one of the outstanding programmers in most industries. You just don't. The most important contributor to being a good programmer is excellent interpersonal communication - something that is unfortunately actively filtered out by many interview processes. Take SOAP for example - that whole "bag of hurt" was created due to a lack of communication between developers (those who created HTTP and those who were developing web-based RPC (i.e. SOAP).) The accidental complexity of SOAP versus the more effective REST (leveraging the existing HTTP platform) and the problems that come with the inner platform effect have cost the industry millions (if not more.) I'm sure SOAP had some super smart guys on the team, but it took them years to speak to someone on the HTTP effort earnestly enough to realise they were replicating features of the platform they were building upon. Or take XHTML vs HTML5 vs HTML 5 (the space before the "5" is important to the W3C apparently.) Just google for discussions about the rift between the W3C and the WHATWG - to me it smacks of "geeks" (and I use that term perjoratively, knowing that I am a geek) not communicating properly. Finally: on spec, on time and on budget software development is far, far from a solved problem. There are so many knarly issues in most organisations - code maintainability, code testability, development process, effective test writing, refactoring, release mechanisms, team work, navigating politics... naming, even. All this, before you worry about whether to use this library (and it usually will be a library) or that because of a slightly different algorithmic implementation. We need the algorithmists - but we also need the guy who can break bad news to the project office, the guy who can construct beautifully simple object models and the guy who really knows what testable code looks like. These are all orthogonal skills.