Ten years of experience, still failing phone screens

I still recall an interview I did at a recently public company in New York, for a DevOps position. 4/5 of the interviews went sailingly, with heavy emphasis on networking, scripting, and AWS knowledge. Then the lead engineer sailed in, five minutes late. He gave me an algorithm question straight from the Google playbook (I don't remember the question, sadly), then after I asked for a few minutes to ponder, proceeded to smirk and interrupt me every 30 seconds to ask if I needed help. In between he was chatting on his phone with the audible keybord ticks enabled.

> 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.

Sounds to me that the author likes to program by "sketching". I do too! Paul Graham recommends this in Hackers and Painters.

> 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.

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.

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.

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.

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.

> I often make trivial mistakes just trying to get a "first draft" of a program out

In my experience, it's helpful to add simple tests as you go. I have done some live coding tests in Python recently, which I'm not super familiar with, and the first couple I did, I made a lot of trivial errors that caused my solution to fail until I went back and cleaned them up. Luckily the interviewers kept their mouths shut while I was coding, and I was able to clean up quickly afterwards, but I could tell it wasn't a great look to say, "Okay, I _think_ this solution is correct," only to have it flame out spectacularly.

After those first two, I started writing simple tests for everything I did. Not only did it avoid embarrassing fails when the solution was supposedly complete, not only was it quicker overall, but every interviewer I've done this with has commented approvingly about it.

They could just need training and feedback. A lot of places just throw any rando engineer into an interview with no coaching on how to behave, how to set guide rails for the candidate, how to empathize and pace the interview, what the evaluation criteria and rubric is. And then after the interview, the person has no idea if he conducted the interview properly. Totally open loop. Just yeet him at candidates untrained and then wonder why he can’t interview effectively.

At last company we used an online tool to screen junior/intermediates and the whole point of that tool was "Here's the task, here's the tests that need to pass when you're finished, feel free to write more", and someone writing more unit tests to exercise their code was a big positive.

Asking someone to implement stuff without running it sounds counterproductive to me. About as effective as asking them to write syntactically valid code on a whiteboard.