Agreeing with and expanding on the interview studies... In most cases, the job that one ends up doing has very little to do with what you were tested for in an

Agreeing with and expanding on the interview studies... In most cases, the job that one ends up doing has very little to do with what you were tested for in an interview. Languages usually have some sort of approved/well know implementation of common data structures and algorithms. When you are asked to do some BFS/DFS/binary tree work in 45min or less you are unlikely to do that for the job. Someone has already provided an implementation. I venture, you are most likely to see it bought up in your next interview (whenever that is). The question is how can you test for experience in writing code that is maintainable, readable, 'instrumentable' and contributes to a better system. How often does a candidate refer and defer to a decent third party library instead of feeling they need to (re)implement a well known data structure or algorithm? What have they done to help automate things so they can free themselves and their peers from minutae (aka how willing are they to put more work on machines?). What more do they think they can do. How well do they mentor or are ready to be mentored? Given a sample project, how would they go about running the technical side of things. If they focus on code, you should try to motivate them to expand to other areas (without telling them what they are). How cognizant are they of the ecosystem; or does their vision end at coding + unit test. Lots of intangibles that cannot be measured with a github profile or a white board interview but probably contribute more to picking out better candidates.