> I'm not fast at reasoning about code, and I often make trivial mistakes just trying to get a "first draft" of a program out. If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code.<p>Sounds to me that the author likes to program by "sketching". I do too! Paul Graham recommends this in Hackers and Painters.<p>> For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
>
> For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.<p>On the other hand, as the post describes, interviews are geared towards a more waterfall-y approach. I find this frustrating as well, but I think that there is something really important to keep in mind that this post misses, and that most conversations about coding interviews miss. The question is whether something is _predictive_ of job performance.<p>For example, consider the question "What is your favorite number?". Imagine that the larger the answer to that question, the more likely you are to perform well as a developer. You might object "But I'm never doing anything relevant to my favorite number on the job!". IMHO, it doesn't matter. The goal is to predict who will perform well on the job, and if having a large favorite number does this, it should be incorporated.<p>Now consider the question of how well you perform on waterfall-style interview questions. Like "What's your favorite number?", it isn't something that you will find yourself doing on the job. But that isn't the right question. The right question is whether or not it is predictive of job performance.<p>Of course, it seems unlikely that "What is your favorite number?" would predict job performance. And it seems unlikely that if you never code in a waterfall-style on the job, that coding in that style during an interview would predict job performance. But maybe it does. I'm skeptical, but who knows. More importantly, I think that this is the question that needs to be asked. And without strong data, it's hard to be too confident in the answer.