Like many programmers and people exposed to Silicon Valley culture, I’ve noticed an emphasis on accelerated learning techniques, and “hacking learning.” Today, I was watching a webinar by Zach Evans and it impressed upon me the difference between performance and creation. Most of what we do as programmers is based on patterns we have seen before, but not something we have practiced before. However, many of the practice and learning techniques have their basis on performance, or in learning classroom material for the purpose of student acheivement.
While I think there is great overlap for learning techniques, we aren’t being tested for what we know on a daily basis. Getting better as a programmer looks like it has little overlap with a recital, game, or test, so we need to think about that in the way that we approach learning or refining our craft. However, there’s a giant exception to this: the technical interview.
The irony of the technical interview is that it is performative in a way that programming rarely is. (Pair and mob programming is performative, as are whiteboarding sessions, as a major exception.) So, this tells us that we should treat getting better in interviews as a different skill than programming itself. As someone who is preparing for technical interviews, it means that we should break down the performance components of technical interviews and train those separately. As someone who is evaluating technical interviews, it means that we face a dilemma: are we evaluating their ability to program, or their ability to train in the skills of technical interviewing?
Others have encapsulated the problems of coding interviews better than I have, but I have seen that most people have given little thought to practicing technical interviews using the research. Cracking the Coding Interview, for example, gives an algorithm for running through a technical problem. However, it gives little other than drilling the problems themselves. Elements of Programming Interviews in Java gives a nice set of strategies, but again, relies on drilling as the preparation method.
Here are a few observations from both sides of the interviewing table:
People, when they are tripped up, are often because they are not used to verbalizing the problem and walking the interviewer down their path of reasoning. This is obvious - it’s hard to have a line of reasoning when we don’t know it ourselves! This tells us that we should practice verbalizing our thinking when we are trying problems, and that we should treat it as a separate skill. To prepare, take FizzBuzz-level problems to start, and practice verbalizing your algorithm to solve the problem, smiling, and engaging with an imaginary interviewer.
Listen to interviewing.io exercises and think about how you would discuss the same problem. Then, watch the interview and actively engage with how you would revise the same explanation as you watch someone else.
In piano, there is a practice concept that you can learn each hand separately and then put the hands together. There is also a practice concept that you should not practice the easy parts, but repeat practicing the hard parts instead. As such, break down all of the individual components of an interview, and drill the parts you have difficulty with. For example, I can take the first ten minutes of an interview problem - that is, the panic of reading a problem, coming up with test cases, and running through questions to make sure I understand the problem, and go through that repeatedly until it doesn’t make me nervous.
Your programming language has some basic classes that are commonly used in interviews. Strings, Hashes, and Arrays are very common. Take time to memorize these functions in particular.
These problems can be thought of as lego blocks, as Zach Evans talks about within the piano sphere. If you can deconstruct the problems such that you don’t need to think about the mechanics of constructing the actual program, you can spend more time in dissecting the problem, feeling confident that you will have time at the end to finish it.
The three most effective strategies I have found in learning are interleaved practice, distributed practice, and the power of consistency. (I would like a link for the power of consistency, but it seems like it has become such common sense that nobody questions it.) Spaced Repitition is a learning super power, but I haven’t found a way to make it valuable in this context.
As I deconstruct this myself, I will post the different skills we can practice while interviewing, breaking them up into chunks we can learn, then put it all together. My goal is to place them in the same structure as a piano practice.
In the end, I am far more interested in helping others become better programmers than better interviewers, but understanding the differences between the two helps us to focus on what makes us good at each.