[eschutte2]

We may be on the same page here. I don't like the way dev interviews are run and I think the focus on textbook algorithms is misplaced. I would say if your interview process can be aced by somebody hitting the books for a month, you're not testing for hard enough things.

I was just a little surprised about those particular items because I feel like they're such an essential background for all software development. But I don't think they should be quizzed for in an interview.

[jrumbut]

So, so many people do things the hard and reliable way, or don't do them at all and sacrifice some desired feature, because they don't recognize a well understood computer science problem lurking underneath a business problem or a UI implementation.

I'm not saying that's what anyone in this discussion is doing, just that I see it everywhere (and have done it myself). 1000s of lines of incomprehensible code because no one realized that this drag and drop flow chart creation interface can be understood as a graph.

[jon-wood]

> I would say if your interview process can be aced by somebody hitting the books for a month, you're not testing for hard enough things.

I'd say if someone can independently learn the things you think are important enough to interview around in a month then they're the sort of person you should be hiring, unless you don't expect new problems to ever emerge you'll need people who can develop their knowledge anyway.