> I mean you should know how the basic data structures work Oh I'm not discounting that. I'm just saying that off the bat binary-tree traversal don't really te

> I mean you should know how the basic data structures work Oh I'm not discounting that. I'm just saying that off the bat binary-tree traversal don't really test my understanding of the data structure. Recently in an interview I was asked a problem which eventually required using a binary-search-tree to improve the running time. This, I believe, is the right way to test but it requires the employer to spend more time designing interview questions rather than relying on a problem bank[0]. (which is a strong filter for good companies in itself) > But they completely ignore the other 80% of the job which is design, soft skills, estimates, timelines, code reviews etc... This is true but this is really really hard to test. In the interviews that I've been giving, I've indeed been asked design questions. I assume soft skills are implicitly tested while speaking to the interviewer (to some extent, at least). But other factors, AFAIK are very hard to test. Also, I would argue that a candidate doesn't need to know everything coming in. Estimates, timelines etc can be learnt on the job. IMO, if somehow employers could find a way to reasonably trust that the code I have on my Github is indeed written by me then I think that should be strong indicator of my competence. Evaluating candidates who don't have any code in the open is a different matter altogether to which I have no solution. [0] - http://leetcode.com http://leetcode.com