Is Cracking the Coding Interview still Relevant?

This week I had my first interview for a developer position. Since Graduating Flatiron, I’d dove in to learning algorithms, Big O notation, all the advice on passing coding interviews on YouTube I could find, and have been reading the holy grail of coding interview help, Cracking the Coding Interview. Up until last week, I felt like I would be pretty prepared for a coding interview.

But then, one of my peers, another Flatiron graduate, had a technical interview. Several of us get together on Zoom calls in the mornings to practice algorithms from Leetcode.com and Cracking the Coding Interview. This day, the day after his interview, he told us his interviewers didn’t ask any algorithm questions. In fact, they looked down on interviews that do that, and said it didn’t teach them anything about his ability as a developer.

This led all of us that day into a discussion, where several other of my peers noted people they knew who had recent technical interviews did not get algorithm questions. Instead, they just discussed coding practices and talked about why they built code the way they did. No one among us could think of anyone we knew who had any recent algorithm questions outside of lead developer positions.

Now, all along since I have been studying to pass a technical interview, I’ve also come across several blogs and videos of developers saying that current coding interview practices are broken. Even proponents of using algorithms, stated that much of the problems were not ideal or practical in the real world, but that they were still necessary for interviewers to see that the person they were interviewing could problem solve on the spot. And, I’d heard, there were problems with giving others a normal component to build, as they could just memorize some basics without understanding how they work or be able to implement them in any creative or meaningful way. I subscribed to this belief to a point. Algorithms do at least test problem solving logic.

So, back to my interview this week. Like I said, up to the last week, I felt prepared going into it. Now, I also knew this was an initial interview and not “The” technical interview. But other than that, I didn’t know what to expect. I ended up reading up on the company more, reading some of their blogs, and going over some of the technologies I knew they used.

During the interview, I was asked a few questions that Cracking the Coding Interview helped me to prepare for, such as explaining Big O. But at the end of the interview, I was told what to expect in the technical interview. They don’t focus on algorithms, they don’t use a whiteboard, but instead provide some code with bugs included, in real time through an online shared code box. They want the applicant to then use Google, and work with the interviewers, to solve the problem, because that’s what we’ll do as developers. We’ll run into bugs, we’ll Google possible fixes, and we’ll work with other developers to fix them.

I love this approach. It gives the interviewers real world examples and gets them the opportunity to see what it would be like to work with the applicants. And it gives the applicants a chance to see what it’s like to work with developers in that company. It’s a great way to test the waters and see how people problem solve. It makes me wonder why we didn’t think of this sooner? Why did we think we had to rely on whiteboards and algorithms to see how we problem solve? We are developers after all. Using programming to solve our problems should be second nature to us.

The developer world is pretty large, there are plenty of positions that algorithms are useful. And understanding and thinking about complexity in code like what Big O gives you is a good tool to have in your belt. So I don’t think that Cracking the Coding Interview is irrelevant in today’s world. But I am hopeful that more companies seem to be focusing less on its weight, and more on the specifics of the role.