The point of these tests is not to see who remembers their CS. The point of these tests is to have an opportunity to see how candidates go through the process of solving problems by approaching a problem that is well-understood by the interviewer. Good interviewers pair with the candidate and help to coach him/her towards a solution. This is a carefully crafted simulation of two people working together in which certain variables can be controlled. It's also time-limited because most interviewers have to go through dozens of candidates to find someone who is a good fit for a particular team and culture. It's economically infeasible to hire a bunch of people on a per-trial basis. It's also hurtful to bring someone in for a few days, and then tell them that they aren't working out.<p>Normally, when I heard this whole "I don't do coding tests" attitude, it comes from a candidate who thinks that he/she is so amazing that the rules don't apply. If such candidates flounce out of my tech screening because I dared to give them a problem, then my tech screening has worked. In my experience, most good engineers have tempered their egos with a dose of humility. They have hit the wall of their abilities, and they understand that they aren't nearly as amazing as they thought they were when they were younger. They are more careful, and they are open minded. I won't dismiss a candidate for lacking humility if I believe that he or she can grow, but if given the choice between a good candidate with humility and a stellar candidate who is too good for a test, I'll pick the good candidate every day. I'll let that stellar candidate be someone else's management nightmare.