|
I'm outside the SF startup bubble, and I interview a lot of mostly recent college grads. I like to ask theoretical questions, especially of college grads. It's not because I expect that they'll need hard CS skills, but it's because I want to know the following things: Can they effectively break down a hard problem into sub-problems?
Can they compare the difficulty of sub-problems and prioritize?
Can they, while working on one sub-problem, think about the effects that their solution will have on the other parts of the problem?
Can they keep track of the big picture of what they're trying to solve while working on a small part of it?
Can they translate their ideas into code fluently?
Can they adapt to change and fix their system cleanly?
Are they interested in computing? Have they spent their own time on learning? These are not theoretical results - these are the qualities that make or break an entry-level engineer. I ask formal CS questions because formal CS is a context that the candidates should be comfortable in, and thus I can ask a hard question quickly. However, I'm far more interested in the meta-questions than if they can get through the solution to Problem X. I try to avoid measuring a candidate with a single question: if I'm doing a phone interview, I'll try to hit many areas (I'm sure you're familiar with Steve Yegge's post on phone screens), so the formal CS part is rarely more than 20 minutes. On the other hand, for an on-site interview, we tend to each focus on specific areas, so I can happily spend an entire hour on one or two hard theoretical questions (if I get to cover the algorithms/data structures section). So - your mileage may vary, and given that you have a significant track record, I don't think that hard theoretical questions would be the best way to measure your ability. But for some categories of candidate (mostly recent college grads), I think that formal CS questions are a good meterstick. (Edited for formatting) |