i am not advocating hiring purely on potential. and of course i view it from the employer's point of view as well. you simply can't hire well if you ask what a

i am not advocating hiring purely on potential. and of course i view it from the employer's point of view as well. you simply can't hire well if you ask what amounts to puzzle questions in interviews. it doesn't address what a person does know. so in my opinion, an interview should be about finding out what a person knows, and in the event that it doesn't overlap with what the employer true needs, then some extrapolation or further digging is needed. however, even when a person's skills do overlap with the needs (whether the employer knows or it or not), it is my opinion that much of the overlap is often ignored (architecture, organization, perspective, personality, design skills, api philosophy) in favor of the more "hardcore" stuff (algorithms, data structures). we all know that even in the with the most efficient algorithms, software can be a mess if employees lack the former qualities. but software that is well designed can get away with less efficient algorithms except in extreme cases and niche contexts. tbe problems faced in a software company are rarely of the form "tell me the big-O behavior of this algorithm". rather, it's much more about how to manage large amounts of complexity, reducing complexity, designing flexible architectures, well-defined APIs, etc.