It's very refreshing to finally hear of a company that doesn't think that leading a candidate through tree-walking algorithms on a whiteboard is an appropriate test of real-world programming ability. Hopefully more companies follow suit and we can finally put to rest what Malcolm Gladwell would call our "mismatch problem".
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 think that approach used to be more relevant before cheap 100+MHz CPU's, interactive IDE's, and the web. Now days most developers need to focus on API's far more than the language and operate in a more abstract environment. People spend far more time writing boilerplate code to leverage powerful system and care far less about how those systems work. Most of the day to day problems relate more to these systems than the actual problem so people spend far more time reading how other developers solved the same problem than writing code from scratch.
Granted some people are still working on embedded systems and low level networking code etc, but that's hardly the default.
PS: Today I needed to break out a decompiler because a client lost the source code on a small website. When exactly does that show up in an interview?
The position you describe is "support" or, more cynically, "code monkey" rather than "software engineer". Software engineers are the people that are building the APIs for you to use.
No doubt there's plenty of money to be made in putting building blocks together and knowing how to play with some tools, but that's not the kind of employee that Google, etc., are looking for. It's assumed that if you know A* and compilers, you can also download tools from the internet, run them, and see if they solved your problem.
Now days 99+% of all developers incorporate some API as a core part of their software. Take the game industry the number of people writing direct X is tiny compared to those who use it. John D Carmack (http://en.wikipedia.org/wiki/John_D._Carmack) is clearly a "software engineer" yet he spends most of his time working on top of DirectX or some other API. Yet, when you dig into Direct X it's built on yet more API's and at the same time anything written on Direct X has a tun of boilerplate code you need to get right or it fails badly.
PS: Ruby on Rails is a perfect example of what I am talking about. By your definition anyone using it is "support" or a "code monkey" even if they start from scratch and build a billion dollar company simply because they spend more time thinking about the API than pointers.
Making billions and being good at programming have nothing to do with each other. Being rich is mostly about getting the idea right and paying others to solve the real problems. Facebook is a good example; Zuckerberg made a nice prototype, but to scale, he had to bring in the kind of people that write their own compilers. He gets all the money because he came up with the idea. But the people that made it work were the programmers.
Also, Carmack is famous for the algorithms he's designed, not for using DirectX.
