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.
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.
> The point of these tests is not to see who remembers their CS.
The point of these tests is exactly to see who knows how to program. I've seen too many candidates who couldn't program, which I understand as finding code which solves a stated problem. FizzBuzz is only used as a first pass filter. After they solve it and are deemed normal enough to work, they are hired for limited time to really see if they are worth working with.
If candidates can't solve fizzbuzz with a language they're most comfortable with (yep, we don't require you know any of our technology), they won't solve other problems they will be given. All my current coworkers can solve those kinds of tests in reasonable time without any help, even if it's in a language they don't know, I've also solved tests prepared by them.
Being able to reason about a problem and then work towards a solution in code is a more general skill than just programming or CS. I'm assuming that here, "FizzBuzz" is more of an allegorical example than a literal test question, as it would be rather useless in a test. I'd be more likely to ask someone to write and then optimize an algorithm or implement a simple data structure, and then build on this example with additional constraints or requirements. That has merit. A pure coding test is no better than a typing test. Without the problem, it's a meaningless exercise.
You would be surprised how many people which call themselves programmers can't even solve fizzbuzz. This is good test to weed out really bad candidates. As I've said, it's good firstpass filter, not a good hiring test.
"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."
You know, I really don't think that's it for a lot of people who don't like technical "interviews". You're seeing this as an ego issue, when there really are problems with the technical exam/interview, especially when it is abused.
Personally, I think the problems start with the fact that we're calling what is actually an exam an "interview", and it's an exam taken under very stressful circumstances. Think of it this way - I read a blog post about someone who studied for the california bar for 100 hours and passed. The exam itself was 3 days long. Now, 100 hours is notably low, and part of the point of the post was to suggest that you don't actually need to study as long as people often do.
But think about this think about what it takes to prepare for a technical interview. Have you read "cracking the coding interview"? Those are difficult problems, and you need to be able to solve them at a white board within 45 minutes (or at least get close enough that you can do it with some, but not too much, coaching). It's not at all over the top that a rusty person would need to spend 50+ hours to get fluid with this. If your data structures, bit manipulation, tree traversal, dynamic programming, threading, or other topics are very rusty, you will need to study before beginning your study. It's not at all uncommon to spend an amount of time that starts to approach bar exam preparation levels. One interview typically lasts all day. So preparing for and completing three interviews is actually roughly on a par with taking the bar exam.
Unfortunately, you rarely get feedback on your performance (for legal reasons, I understand). You have no idea if your exam was graded fairly or consistently, and you have no idea if your examiners have the credentials and expertise to actually understand a novel solution. Sometimes you get advance warning about what might be tested but other times you are completely blindsided by the questions. Once you pass the bar, you've passed. Software interviews, on the other hand, you have to do over and over. And even worse, we often present these tests as sniffing out frauds rather than looking for exceptional talent (ie., an exceptional performance on these exams rarely get you much above the job offered, so it's more about not losing than winning).
Really, there's a tremendous amount to object to here. You don't have to think you're amazing or above it all to start thinking this is a serious problem that may be driving talented people away from our industry. I've read various blog posts about potentially promising candidates who aren't interviewing anymore simply because they're too intimidated, or because they just can't afford to put 50+ hours of study into something that may be completely capricious and depend purely on what some overworked programmer thinks is important that day. I can't imagine my graduate program's MS exit exam, or the bar, or the state nursing license board, or any respectable exam committee getting away with being so capricious and opaque.
Now, I've hired before, and I'd be afraid to hire without a technical exam. So I hear you, I really do. And I've been on technical interviews, even tough ones, that I actually kind of enjoyed (I so rarely do real dynamic programming or tree traversal, and it is actually kind of fun, under the right circumstances).
But we spend so much time talking about a desperate shortage of software engineers, and so little time actually recognizing some of the things that make our industry really exceptionally unpleasant. I think we should recognize that tech exam/interviews, while perhaps necessary, are also a potential problem, enough of a problem that some people are starting to boycott them altogether (I will do them, though I won't do an unpaid take-home ever again).
It may in fact be an ego problem some of the time, but since there's clearly a more legitimate reason to object to this practice, let's start there, rather than dismissing this as an ego problem.
I've interviewed for top technical companies in Silicon Valley and have gotten job offers. I've never encountered a scenario as dire as the one you paint. Rarely do these problems go beyond something that can be reasoned out on one's feet. If people are studying for 50+ hours to pass one of these interviews, then they are doing it wrong. You can't prepare for one of these by studying. I give problems SPECIFICALLY because I don't want the candidate to know how to solve it on the way in. I want to see how they think on their feet. If they solve a problem quickly, I give them a different problem or toss in a curve ball. I don't care about what they know coming in. I care about how they apply general knowledge towards solving problems that they have never seen. I care about how they interact with someone in a brainstorming session. I'm interested to see how they handle these sorts of problems, because they will be dealing with them every day.
These aren't exams meant to prove that you've studied hard. They are open problems with dozens of potential solutions. These are meant to see how you think and how you work with others.
Agreed, based on my experience, the experience of interviewing at top technical companies was better than what I've described. Those spots are where I actually kind of enjoyed my interviews.
I do think you need to prepare for them, though. Substantial practice and studying made a big difference for me. However, I was very, very rusty on things like dynamic programming and recursion, tree traversal, and so forth.
The solution may not be (probably won't be) eliminating the technical interview. Going about it the "right way" (which is an open question) is important, though.
What you are doing certainly doesn't sound like a bad experience or process.
As for other interviews... yeah, unfortunately, I really do think it gets "that bad" at times. Enough that I can see why people are hesitant to apply for new positions.
Yeah. There can be no doubt that there are plenty of companies that have failed to grasp the point of the technical interview. I've had to coach employees in the past because they often gravitate towards silly questions like "name the 8 primitive types in Java." Who cares? The interview is a two-way street. Not only is the interviewer trying to see if the candidate is a good fit, but the candidate is trying to see if the company is a good fit. Companies that fail to build a good technical interview will lose opportunities to gain good candidates, because these candidates will be turned off by the process.
Ultimately, this is all about building a team that not only works well together, but has the potential for growth. That requires a good culture. The interview process should be the candidate's first introduction to that culture.
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.