It was a little intimidating going in with no real reference frame, but mock interviews are absolutely worth doing for nontraditional programmers.
As a mechanical engineer, I’ve done technical interviews before. In my experience they’ve always had two parts, the first coming in the form of glorified homework packets where I do calculations for angular momentum or shear strength or oscillation to show I haven’t forgotten everything from school. The second, equally important part was then describing my calculations to one of the engineers at the company to show that I know why I’m applying those formulas to those problems, and what assumptions I’ve made.
Explaining my assumptions and decisions in this mock technical interview felt very familiar, but the rest was entirely new. Of course the questions were very different, but the format was switched up as well – I had to explain my thought process while solving the problem live rather than having time to myself to work through them. That was the most intimidating element for me, but I came away with more confidence and with several lessons:
1Grinding through problems on sites like Leetcode and Interview Cake is, as advertised, a great way to prepare. It helps you experientially learn algorithms and gets you into a problem-solving groove. It’s easy to get into the right mindset for the mock interview if you’ve been seeing and solving similar problems all week. When I was given a problem that didn’t relate to what I’d been practicing, I used Interview Cake’s advice: start with the brute force method and refine from there. Getting *a* solution out is better than nothing, and detailing why the brute force method is inefficient can give you a clue as to what could be a more efficient solution.
Using algorithms in a project is also an excellent way to prepare. I wasn’t confident in my proficiency with string manipulation, so I wrote a CLI “decoder ring” program that encodes and decodes messages with pre-modern ciphers. They’re all pretty easy to put into code, but ciphers are still algorithms and it was interesting to translate quill and parchment tactics to programming instructions.
2While it’s important to have some knowledge of algorithms and it’s definitely important to be familiar with Big O notation, problem solving skills were what the interviewer emphasized the most. I had no clue where to start with the first question other than an O(n2) brute force method, so I wrote that solution out and then refined it. It took me several iterations, but I was eventually able to produce a neat little O(n) solution.
At the end of the session I let the interviewer know that I was nervous about that first problem. It was in my practice problem list and I’d stopped just before I’d gotten to it during my last study block. He told me it was actually better that I hadn’t done the problem before because he could get a much clearer picture of my problem solving process.
3It’s important to have good problem-solving skills, but it’s equally important to explain your thought process and communicate what you’re doing. The interviewer wants to know why you’re choosing that method or that data structure or that strategy over another. On any project you’ll need to make decisions and communicate your reasoning to your teammates and your boss, and that’s exactly the skill they want to see in an interview. Even if you’re not 100% sure that what you’re doing is the right path, thinking out loud can help the interviewer steer you in the right direction because they’ll know where you’re going wrong. Just like in math class, show your work!
4Another reason to think out loud and describe your decisions is that you’ll be able to get unofficial hints from the interviewer. Mine explained that it’s good to take pauses both to let yourself think and to allow the interviewer a chance to react to what you’re doing. Watch to see if an interviewer nods or says something in the affirmative as you’re describing your process – that means you’re on the right track so far. If you’re seeing a poker face and hearing nothing, you might need to try a different strategy or algorithm.
5Another important piece of advice from my interviewer ties back to my comment about seeing an interview question straight from my practice set. I hadn’t heard this before: you need to tell your interviewer if you’ve already done an interview problem (or a problem that is extremely close to it). They want to see your problem solving skills, not your algorithm memorization. Knowing algorithms is great and important, but being able to apply different modes of thinking to a problem is higher on their list. It’s also a question of character – it’s a giant red flag to not let the interviewer know you’ve gone through that problem before. He explained that on the easier problems it’s not as obvious, but on medium and hard ones it’s very clear to interviewers if a candidate has previously worked that same problem.
This is not to discourage candidates from doing practice sets, of course – he recommended I continue to work through more algorithm problems. It never hurts to have a broader knowledge of theoretical concepts, and as algorithms get more complex it’s harder to derive them if you haven’t seen something in the same family before. As ever, the main idea is to show how well you problem-solve, not how well you memorize.
Doing a mock technical interview has increased my confidence and also helped shape my job search and my interview prep going forward. One of the biggest personal takeaways was that my interviewer gave me an idea of where I stand in terms of knowledge and ability. I’ve been practicing with easy problems, but he told me that I have a very firm grasp on the fundamentals and should move on to medium problems and reinforce my knowledge with more advanced data structures like trees and linked lists.
