Does having a very low TopCoder rating make someone unemployable?

[MrGrj]

Am dat peste un raspuns destul de elaborat si bine construit / argumentat si m-am gandit sa il shareuiesc pentru ca poate schimba perspectiva multor useri de p-aici. ( asta daca stiu engleza, desigur )

Argh. No. We really need to stop with the current internet-penis-size mentality around algorithm skills. Yes, testing for basic algorithmic knowledge is an excellent interview shit-test to weed out people that have absolutely no business writing code, but other than that has very little to do with the job of being a software developer.

You can spend all bloody day churning out bug-free code with perfect linear time complexity at laser-finger speed, but you might still be a totally shitty developer.

We are not athletes or musicians that perform on stage - we are engineers.

Our job is to build things. More specifically, (1) build the right things, that (2) work as expected, are (3) easily maintainable for a year or two, and (4) built within reasonable time-frames.

This is sort of how I spend my time at work:

• 40% Talking about WHAT to build. Communication about requirements is by far the most complex, important, and time-consuming aspect of software development. This includes negotiating them, measuring success of them, preventing feature creep from entering the backlog, prioritizing work, how to evolve the architecture instead of just welding the feature on top of it, convincing your product owner that you need to deal with technical debt, and another billion things. If you don't get this right, it will fail your project no matter how good you are at the other stuff.
  
• 
  
• 40% Diving through other peoples code. It is absolutely crucial to be able to absorb other peoples code correctly and quickly, so that you'll make changes that fit (1) in the architecture and (2) don't break existing functionality. It's even more important that you are able to GENERATE code that is easy to understand and absorb, or you'll be a sort of "time cancer" for the team that constantly produces more and more code that wastes more and more time for people to read and understand. I don't care if a programmer has 200 in IQ - if she neglects writing unit tests (the best kind of code documentation), he's GOING to be a detriment for the team, not an asset.
  
• 
  
• 15% Hunting down existing bugs and performance bottlenecks. This has very little to do with algorithmic skills, because humans cannot "look" at 500 000 lines of code and see what is wrong. You need the skillset to methodically narrow down your suspects until you've found the offending method, which usually takes a lot of methodical patience. Once you actually find WHERE the bug/bottleneck resides, it's almost always easy to fix and doesn't require algorithmic genius.
  
• 
  
• 4% Writing actual, new functionality.
  
• 
  
• 1% (and I'm being generous here) Thinking about the time complexity of things.
  

In conclusion: When interviewing, by all means, do a little bit of algorithms just to make sure that the candidate can code, but primarily look at if the person has actually gotten shit done, in a team, in the past.