Mastering the Art of Interview Preparation: The 4 Pillars of Success

In our last article on interviewing, we discussed the mindset necessary to get into in order make a positive impression during your interview. Today I'd like to expand on that with a very tactical article on how I do my interview prep. I've refined this technique over the past couple decades and find it quite effective in getting me the results I want. If you’re serious about landing that dream job, I would suggest you correlate my advice with other online sources and design a preparation strategy that best suits your personality and needs.

Preparation is key (duh)

Let's get to the meat of the matter. According to Indeed, candidates spend an average of 5-10 hours preparing for a technical interview. Personally, I believe that’s laughably little. But 5-10 hours? Come on! That’s a day’s worth of binge watching. If you want a positive outcome, you’ve got to put in more effort than that. Do you want that job, or not?

In this article, I’ll be focusing on preparing for a software engineering interview, but the study approach applies to any white-collar job. The first two sections below are directly applicable, the last two are specific to software engineering; substitute your domain-specific topics for those.

Finally, in the following sections I’ll mention rough timelines. Another successful approach can be to always be prepared. In other words, develop and maintain the skills you’ll need for interviewing. The advantage is you’re ready to interview at any time. The disadvantage is, of course, the time needed. These skills will degrade without structured practice, so you must be willing to invest time monthly to keep them up to date.

Disclaimer: in the following sections I’m going to recommend certain books and products. I’m in no way affiliated with these, and don’t get a commission should you decide to invest. I have simply used them to great advantage myself and am hopeful they will hold value for you as well.

Soft Skills

Our last article on interviewing covered this topic extensively, so I won’t belabor it here, other than to mention it’s important to practice talking your thoughts aloud without losing them. Remember, the interviewer is trying to get a handle on how you think, how structured your thought process is, how logical the conclusions. The best way to give them this information is to speak your thoughts aloud.

Practice speaking clearly, without filler words. Practice comfortable pauses. Here you can use groups like Toastmasters, or AI-powered tools, or even one of the several companies who set you up with mock interviewers from the company you're meeting.

The point is to get comfortable talking, and to make sure your ideas flow smoothly, that you have the right amount of eye contact, and so forth.

Timeframe: months. Yes, expect to spend months doing this if you’re not already skilled at such discourse. Soft skills like this take a long time to master and require tons of practice.

Stories

Make a library of stories you can draw on. Things you've done in your career. If you haven't had a career yet, jot down notable projects at school, notable side projects, and so on. Amazon in particular focuses on stories, where the stories exemplify one or several Amazon Leadership Principles. (There's a wealth of information about Amazon's interviewing tips on their site.)

The stories should follow something like the STAR format: Situation, Task, Action, Result. I won't go into detail on these here; there's plenty of information about STAR online. The important thing is that you have somewhere between 10-15 stories you can draw on related to how you’ve contributed to your past projects. Try to categorize these by common leadership principles. (e.g. Ownership, Deliver Results, Dive Deep, and so on.) I would even recommend having a cheat sheet of your stories that you bring with you to the interview.

Timeframe: a week. Brainstorm notable events from your experience. Pick the strongest ones. If you can’t find enough, consider asking your current or past teammates. Sometimes those around you will have better stories of your work than your own memory will allow. A great practice to get into is to update your stories bank monthly, since the level of detail you’ll need to talk through your story will often fade with time.

System / Architecture Design Skills

This category in turn splits into class-level design and system-level design.

For class level, nothing beats knowing and understanding Design Patterns. I wouldn’t recommend the Gang of Four’s Design Patterns book unless you’re into very dense reading, but Headfirst Design Patterns is a very accessible and thorough book.

For large-scale system design, I would recommend AlgoExpert’s SystemExpert module. They both do a fantastic job covering the major concepts and have a library of questions for you to practice on. Work through these until you feel entirely comfortable not just explaining the material but doing so without filler words and unnecessary pauses.

Once you’ve mastered the AlgoExpert materials, I’d recommend leveraging ChatGPT or another LLM to make up more questions to practice on. This applies to both class level and system level design. Get to a point where you can reliably explain your solution to ChatGPT.

Timeframe: up to a couple of months, depending how much help you need in these areas.

Technical Skills

This is just the brute-force ability to code up a problem on a whiteboard, whether in-person or shared virtually. I would again recommend AlgoExpert here; they have two separate products dedicated to coding, one for general, and one for frontend.

I know quite a few folks use TopCoder to practice, but I’ve found several issues with using TopCoder:

1. The problems are usually harder than what’s given in interview settings.

2. There’s no explanation of the solution.

The point of practicing on a site is not just to solve the problem, but to get into a groove of analyzing ambiguity in problems, gathering the requirements, formulating a plan of attack, and then executing it. All while talking aloud about your thought process and decisions made.

In a real interview, you will want to engage the interviewer in a conversation. This is particularly important in the opening stages as you’re gathering requirements. But a conversation can serve you well even during the implementation stage if you can get the interviewer to adopt a collaborative rather than an interrogative stance. In other words, engage them in a conversation like “I think we should try a binary tree here, what do you think?” Or better yet, “I’m trying to decide between a hash table and a binary tree to store this data. I am leaning toward a binary tree because...” You get the idea.

This is something site exercise can’t help you with, so if you’re worried about this aspect of your interview, I’d recommend one of several mock interview sites like Prepfully, where you can hire a coach to help you. The same goes for practicing system design. There’s nothing quite like putting your skills to the test with a real person.

Timeframe: up to a couple of months, depending on your skills gap here. For me personally, this was always the hardest part of interviewing, and one I still haven’t fully mastered. The mind must be conditioned to both think about potential solutions and communicate those thoughts clearly to the interviewer. That’s hard to do well.

Conclusion

As you can see, interview prep will typically span months of concerted effort. Obviously, I’m assuming that you’re not spending the full day at this prep, assuming you already have a fulltime job. If you can devote all your time to prep, you can probably shrink the timeline down to a couple of weeks.

Do you have a favorite technique for studying for your interviews? Share it here!