Mastering the Tech Interview
You want your dream job, and I want to help. I have access to some proven strategies. They’re proven because of the source. My friend, Eugene, has held a lot of jobs and hired for a lot of teams in the tech industry. These are his interview strategies. I’m sure he’d love answering questions you have about them. Let me know. I’ll put you in touch with him.
He outlined Four Pillars of Success in mastering a tech interview.
His suggestions are refined from a couple of decades in tech. They’re meant to serve as a starting point for your continued research into your interview prep.
Preparation is Key
According to Indeed, candidates spend an average of 5–10 hours preparing for a technical interview. At least candidates are preparing, but that’s not enough.
It could be good news for you. If the average preparation for a tech interview is 5–10 hours and candidates think they’re good, then you know the benchmark for being over-prepared. That’ll stand out by itself.
Instead of thinking about interview preparedness, think instead about industry preparedness.
And the fact of nearly every industry is that, as much as possible, it is valuable to you to keep across the state of your art, no matter what industry you’re in. If you devote time every month to continuing education, whether you’re actively job hunting or not, you’re already better prepared than the average job hunter on Indeed.
Disclaimer (stolen from Eugene): the third and fourth of these “Four Pillars of Success” are for software engineering. Pillars one and two, though, apply to any technical interview.
Pillar One: Soft Skills
Practice your thoughts aloud. Any interviewer needs to get a handle on your thought process, how structured it is, how you come to logical conclusions. So practice describing processes, systems, problem-solving, out loud.
Speaking clearly and without filler words.
Practice comfortable pauses.
If you want to get serious about it, try finding groups like Toastmasters, AI-powered tools, or companies that provide mock interviews for a fee.
You need to reach a level of conversational fluidness that meets your comfort level. That level will be higher with practice.
Timeframe: months. Plan to spend months on interview soft skills. Even if you’re already confident about speaking on your subject, it’s still wise to practice regularly. Soft skills like this take a long time to master and require tons of practice.
Pillar Two: Stories
People connect with and remember stories. Connecting and being memorable are some of the most essential goals in a job interview.
Stories illustrate the levels of your technical skill better in a lot of ways than data. Make a library of stories. 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. Just for example, Amazon focuses on stories in their technical interviews, where the stories demonstrate Amazon Leadership Principles. (There’s a wealth of information about Amazon’s interviewing tips on their site.)
If that sounds daunting, and you don’t think of yourself as much of a storyteller, you can follow something like the STAR format:
Situation — Describe the situation.
Task — Explain the tasks and obstacles and challenges you faced.
Action — What did you do?
Result — And tell them about the result. Good or bad.
Try to think of between ten or fifteen stories. In standup comedy, we call that a Tight Ten. Choose situations that show off how you contributed to projects in the past.
Try to think up stories that fall under common leadership principles as well (like Ownership, Deliver Results, Dive Deep, etc.)
Even if you feel confident memorizing them, you should bring notes about the stories to interviews. Everyone uses notes. Notes demonstrate seriousness.
Timeframe: a week. Brainstorm notable events from your experience. Pick the strongest ones. If you’re struggling to find ten or fifteen, consider asking your current or past teammates. Sometimes our teammembers have more stories about our work than we do. Do yourself a favor too and revisit your Tight Ten on the regular. Keep your material fresh.
Pillar Three: System / Architecture Design Skills
If you’re interviewing for any job other than a job as a software engineer, you have now reached the end of the information useful to you in this blog. Good luck, and watch this space for more hot tips!
If you’re a software engineer preparing for the job market, read on.
Okay, System/Architecture Design skills splits into class-level design and system-level design.
For class level, nothing beats knowing and understanding Design Patterns. Eugene 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, Eugene recommends 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, Eugene recommends 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.
Pillar Four: Technical Skills
Technical Skill is just the brute-force ability to code up a problem on a whiteboard, whether in-person or shared virtually. Eugene would again recommend AlgoExpert here; they have two separate products dedicated to coding, one for general, and one for frontend.
Eugene knows quite a few folks use TopCoder to practice. We’ve found several issues with TopCoder:
- The problems are usually harder than what’s given in interview settings.
- 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, Eugene recommends 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 some people, technical skill demonstrations are the hardest part of interviewing. 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. The advice in this blog assumes you’re not spending the full day at this prep, assuming you already have a fulltime job. Instead, we figure you’ll be doing your preparation over time. On the other hand, if you can devote all your time to prep, you can probably shrink the timeline down to a couple of weeks.
