I don't understand this. Why would you want to work with someone that doesn't have a basic understanding of computer science?
I work with a bunch of people that wouldn't know a tree if it fell on them, and it's amazingly painful. They write amazingly slow-running code simply because they don't even know that there's a such thing as an O(n^2) algorithm.
I've interviewed at Google and the problems they ask are great. They don't care about trivial minutia like what programming languages you know. They care that you can approach a hard problem, apply your knowledge of computer science, and generate a solution that's simple and efficient. That's the kind of codebase I want to work on, so that's the kind of interview questions I would want to ask.
I don't think the above commenter suggests you want people who DON'T have a basic understanding of computer-science at all. The problem is that the traditional 45min-per-interviewer style of interviewing really isn't sufficient to know if someone is a viable candidate or not. You don't know until they actually work on something.
That's what is refreshing about Pulse's process: you actually work on something and present it to them. This is very practical approach, and requires the use of the candidate's facilities which include, but are by no means limited to, computer-science understanding.
As an aside, I've also worked with people who have good technical skills but had serious attitude problems. Those people tend to have a very negative effect on company culture.
What I've found far more lacking in my colleagues over the years is an ability to create clean abstractions and to think architecturally. In most code this is far more important than the ability to roll basic algorithms from scratch.
The Google approach is like unit testing only one specific feature of a candidate. Pulse's approach is more like an integration test.
I've had the exact opposite experience. Everyone I worked with was pretty good at all the software engineering stuff, but mostly have been average-to-bad with algorithms, math, thinking outside the box, optimization, coming up with clever solutions, etc. Maybe it depends on where you're coming from.
When I interviewed at Google, one hour was about abstractions and architecture. You can ask a bunch of CS questions AND architecture questions when interviews are a day long.
I work with a bunch of people that wouldn't know a tree if it fell on them, and it's amazingly painful. They write amazingly slow-running code simply because they don't even know that there's a such thing as an O(n^2) algorithm.
I've interviewed at Google and the problems they ask are great. They don't care about trivial minutia like what programming languages you know. They care that you can approach a hard problem, apply your knowledge of computer science, and generate a solution that's simple and efficient. That's the kind of codebase I want to work on, so that's the kind of interview questions I would want to ask.