As a student who will soon graduate this is a real dilemma. Do i learn and practice more algorithmic problems to get better at that side, or learn and work with as many technologies I can to get some 'real world' experience.
This just seems like a better way to evaluate candidates even though we rarely have difficult algorithmic problem in our daily work.
I say this with some specificity to Amazon (I did ~200 interviews while I was there), but it would apply equally well to every other tech interview I've done.
Top Coder will change the way you think about problems (in terms of what primitives you'll bring to bear against them). I would say the same for mastering another framework that has a different model than those you've used before, but that both takes a lot more time and is nearly impossible for an interviewer to evaluate unless they've achieved the same mastery.
Algorithms are in some sense a least common denominator proxy metric for "can this person solve problems?" Usually this is followed by "can this person string three lines of code together and perhaps use a for loop?"
When these interviews go well it's usually a pretty accurate indicator that the candidate is technically capable of doing the job. The contrapositive is not always the case -- when the interview goes badly you're sometimes left with a nagging sensation that because you did a crappy interview you're going to miss out on a good candidate. That's just the way (many) hiring systems are biased, though -- it's better to say no to a good candidate than say yes to a bad one.
The belief is it is easier to train a computer scientist to be an engineer than the other way around.
Additionally, in fast-growing companies (such as Amazon and Google), it's usually the case that candidates are measured against a hiring bar and, if they exceed, they are presented with an offer, independent of other candidates. That is, there are more openings than can be easily filled, so any candidate who meets the bar can be hired, rather than being explicitly in competition with each other.
We'll said. I think this is an important thing to note for any new grads looking to interview at these companies.
...and yet it still seems to take a lifetime of effort, discipline, and study.
I prefer the candidate who can comfortably talk about algorithms, data structures, algorithmic analysis, theories of programming language, and theory of computation, and then discuss how they implemented the areas of interest to them.
I have no need for someone who can't write code to implement the theory they know.
Part of this focus is my belief that software engineering is not teachable in college; the projects are too small and the social dynamics don't carry over to the work environment. I am fine bringing an intern or new grad along and teaching them configuration management, practice & theory of testing, code reviews, etc. These things can be taught to someone of reasonable social capability who has already learned coding and algorithms, something I am not really willing to teach new grads.
Algorithms only come up in job interviews just to check basic understanding of computer science, but most of the discussion should be on what tools, protocols, and services are you hands-on experienced with, and it doesn't matter if you were paid for it.