Kyle Shevlin

A few days ago, I came across a tweet by Stephanie Hurlbut, a software engineer and entrepreneur who uses her influence to help other engineers out. Allow me to share that tweet with you:

If you would be up for giving someone a mock typical whiteboard interview to help them pass those (Skype or in person), reply to this tweet.

— Stephanie Hurlburt (@sehurlburt) June 8, 2017

I was really intrigued by this idea and was hoping someone would rise to the occasion. As it so happens, a few awesome people offered to give mock interviews. In particular, I came across Senior Software Engineer at Google Rick Altherr’s offer.

I’m waiting for my first taker

— Rick Altherr (@kc8apf) June 27, 2017

Well, as you can guess, I took Rick up on his offer and setup an interview with him.

Some Context

I think it’s appropriate to provide some context to why I was so interested in this opportunity. I reveal this with some apprehension. It’s not really culturally acceptable to admit that one is interviewing with companies (even though, realistically, we know it’s happening all the time and we might be better off if we could all be a bit more open about it), but I hope my honesty is appreciated by those who are interested in what the mock interview process was like.

For the last four to five months, I have been interviewing with companies for senior front-end JavaScript developer/engineer positions. I’m looking for the next challenge in my career and hoping to join a solid engineering team for a company with a great product. This season of interviewing has been challenging and, at times, even disheartening.

I’ve had a lot of interest, more than I expected and from bigger companies than I had even thought were available to me before. Companies like Stripe, New Relic, Amazon and others. I must be doing something right with my career for this to happen.

I have gotten to a final interview with every company I started the candidate process with, used quite a bit of PTO to get to these onsite interviews, but thus far, haven’t been able to get over that hurdle of getting an offer.

Companies have a legal incentive not to provide feedback. As a developer, I find this frustrating. We’re used to our code telling us why it isn’t working and making changes. Interviews don’t work like that. The feedback is often non-existent, and when it is provided, it is so vague as to be practically useless. So the opportunity to participate in a technical interview with no real pressure and guaranteed feedback was a perfect opportunity for me to learn if there’s anything I can adjust moving forward in my search.

The Interview

After responding to Rick’s tweet and getting the affirmative, we messaged each other a few times to set up a time for the interview. I handled this as I would any normal interview. We discussed times that would be a good fit for both of us and then hammered out a few of the details we wanted to cover in the interview. When the time came, we used a Google hangout and a Google doc to share the code. I’ve not used a Google doc in this way before (and I certainly missed some nice features of a code editor while coding), but it worked just fine. As Rick said, it had the added benefit of him highlighting some of my code if necessary. After some brief introductions, we dove right into Rick’s problem.

Now, I won’t share any details of the problem because, to some degree, the problem itself is irrelevant, and I wouldn’t want to burn one of his questions. He told me later that he has used this question for four and a half years. I wouldn’t want to be the reason he had to stop.

He described the problem. I made some quick notes of details I thought were important to finding solutions. I like to do this for two reasons. First, I don’t like working through a solution only to realize I forgot a key part of it. Second, I think it’s my first opportunity to show my thought process and what it would be like working with me on a problem. I think it indicates I can pay attention to details and summarize problems into their most salient parts. I asked some questions about what assumptions I could make and then focused on writing the code for the two main parts of the problem.

I solved one part of the problem relatively quickly, but it was the smaller of the two parts. The second, bigger part involved recognizing a key element of the problem (which I did). However, I wavered on what was the best strategy to solve it. This wavering slowed me down a bit and became a focal point of our discussion afterwards. After deciding a path ahead, I spent a little more time coding, about 15 minutes in total, before Rick cut me off. He cut me off so we would have more time to chat and that it was apparent I would solve the problem eventually.

The Feedback

Right away, Rick asked me a question I wasn’t quite expecting, “How do you feel you are doing?”

I answered with some moderate confidence, but also with a hint of apprehension. I was confident I was on a good path to a solution, but I was uncertain that I was heading towards an optimum answer. I took some time to explain that this has been a common feeling in the interviews I have had. I don’t have a background in computer science, so the more technical aspects of data structures, Big O, and algorithms is fairly new to me. I’ve only been studying these things for a short while (6-9 months). I can find solutions, I’ve yet to be completely stumped by a problem given to me in a technical interview. But I often get the sense, or know, that there is a more optimal solution that I am not coming up with.

His response was that he has seen hundreds of engineers attempt this problem. Of those many engineers, including those who work at Google, I was doing “average to above average” on solving the problem. I’ll take that. That’s a big win in my book.

He said it was clear I understood my language and that I did a good job describing my thought process as I worked. His main concern was my speed, that I needed to go faster.

I tend to be a methodical, slower coder. I get things done on time, but I get them done by thinking through my problem and then coding. Maybe you’d call me a “measure twice, cut once” kind of coder. This isn’t normally a problem because I do think of solutions relatively quickly, but when I hit a place of uncertainty, I slow down and think through options. I question myself. I waver.

This wavering isn’t serving me well. First, it makes me slow. I had never considered just how important speed might be to the culture of a company. Rick said that my speed might be acceptable at this company, but “it would never fly” at that company.

Second, I am a verbal processor (and an honest one), so while it serves me well in describing my thought process, it also means that I describe those moments when I’m uncertain and unconfident as well. This isn’t likely to help me in an interview. An interviewer might think I’m trying to fish for an answer, or look for some kind of visual cue to indicate I am on the right track.

I took from this that I may have to push myself to code with a bit more speed. I think I also need to make decisions confidently, or at the very least, act like my solution is solid. If I discover there is a better way, I can simply state that fact, and refactor my code. It does happen. I have to signal less that I am unsure, or that I want affirmation I am on the right path. I have to have more belief that I am on the right path already.

Conclusion

Having done quite a few of these interviews now, I can say that this experience was very similar to the real one. It was so helpful to be able to talk immediately with my interviewer about how I did instead of trying to infer the feedback based on subtle social cues like speech, tone, and body language.

I really enjoyed this process. I think it should be a more common practice among aspiring and ambitious developers. It can be a great benefit to interview, even with friends, frequently. Practice will make the real thing much easier.

Personally, I thought it was great to get some feedback, and frankly, some affirmation that I am doing well with my chosen focus and that I am on the right path. Going through these really challenging interview processes has occasionally left me wondering if I’m not ready yet, or I’m not good enough. I don’t think that’s the case. I think I am really close to getting to my next goal.

So that was my experience doing a mock interview with Rick. I want to publicly thank him for taking the time to help out engineers this way. I also want to thank Stephanie for her part, creating an opportunity for people to connect. Thanks to both of you.

I know that this was a very personal post, but I hope there was something you could take from it. Feel free to ask me more questions in the comments if you have one. Having done this experience, I think I may have to offer some mock interviews for the junior developers I meet. If you’re a mid-to-senior level developer, consider offering mock interviews, too. Or maybe trade them with a good friend. Either way, we’re all bound to learn a little something more about being better at interviews.