> who do you want to hire, all else being equal?
That's the point. It's freezing out people who are equally competent, but can't perform as well at this arbitrary step.
That's the point. It's freezing out people who are equally competent, but can't perform as well at this arbitrary step.
That's not the same as being equally competent.
Do not hire the smart ass. Take the person who lives in the real world.
(If you want a disclaimer, I'm not really sure which side I come down on with this, but:)
Knowing how to model something abstractly, and what known good algorithms might be applicable, is exactly not 'rushing into coding'.
What brianpgordo is saying is that algorithms and data structures are an important quality in addition to those.
Here's another: the founders already coded all the brute-force versions of everything. Now they want their software to scale. You will use your knowledge of algorithms and data structures (and distributed systems) to turn their one node that handles 10 events per second into a cluster that handles 10 million per second with low latency across several geographic regions.
If you don't, either look for someone who's done something like your problem before, and ask about resume/experience instead of whiteboard gauntlets. Or acknowledge that it's a research&implement position, and... again, skip the gauntlet.
the question is asking if you seen that before, period.
"They're equally competent except that they didn't go to a school like MIT or Carnegie Mellon known for the highest quality CS departments. They obviously would've been accepted if they were top-tier grad material, so they are qualitatively not the same as being equally competent to someone who graduated from one of those programs".
I do agree with you inasmuch as they need to be able to speak intelligently about CS. Whether or not they can recite some textbook taxonomy of algorithms, they need to know how to describe and critique an algorithm or describe how a program works.