Ten years of experience, still failing phone screens
&gt; I&#x27;m not fast at reasoning about code, and I often make trivial mistakes just trying to get a &quot;first draft&quot; of a program out. If I get behind or the interviewer starts interrupting to ask about the bad code I&#x27;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 &quot;sketching&quot;. I do too! Paul Graham recommends this in Hackers and Painters.<p>&gt; 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.
&gt;
&gt; For a long time I felt bad about this, just as I once felt bad that I didn&#x27;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&#x27;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 &quot;What is your favorite number?&quot;. Imagine that the larger the answer to that question, the more likely you are to perform well as a developer. You might object &quot;But I&#x27;m never doing anything relevant to my favorite number on the job!&quot;. IMHO, it doesn&#x27;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 &quot;What&#x27;s your favorite number?&quot;, it isn&#x27;t something that you will find yourself doing on the job. But that isn&#x27;t the right question. The right question is whether or not it is predictive of job performance.<p>Of course, it seems unlikely that &quot;What is your favorite number?&quot; 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&#x27;m skeptical, but who knows. More importantly, I think that this is the question that needs to be asked. And without strong data, it&#x27;s hard to be too confident in the answer.