The Proven Method to Technical Interviews

2020-06-12 | BY Chelsea DeRose | IN Free Resources, Job Seekers, Resume & Interviews

The Proven Method to Technical Interviews

It’s daunting to think about how many hundreds of ways you can prepare for a whiteboarding challenge or a coding portion of an interview. Of course there are practice problems and examples online, but how are you supposed to prepare your mind?

Most technical interview questions can be approached with a reliable system for success. If you have a system to fall back on, you’ll find it much easier to focus on your conversation with the interviewer(s). While it’s not a sure science, we’ve seen other software engineers succeed by following this system and wanted to share this straightforward, replicable formula. The approach below will help you simplify the challenge and eventually arrive at a creative response in five steps. 

Before You Begin, Know Your Audience 

It helps to think of your interviewer as your customer. As they lay out the initial problem, imagine that you’re sitting down with a potential client who is seeking your help with a specific challenge. Your goal is to solve their problem. It’s as simple as that. There is a tendency to overcomplicate the problem you are asked in an interview, but framing the conversation in this light can help you keep the right challenge in front of you. 

A) Keep it simple and efficient

B) Solve the problem they asked you to solve

Moreover, the more you know about your interviewer(s) in advance, the better you’ll be able to design to their needs. This means understanding the goals and motivations of each person on the hiring panel. Glassdoor recommends learning as much as possible about your interviewers (search they’re LinkedIn, Google them, get a feel for what they’re working on) so that you can better tailor your answers to their specific areas of interest. They are your customers, after all. 

5-part formula to ace technical interviews

1. Understand the SCOPE of the problem

Take the first few minutes to talk to your customer and get a better understanding of the problem, its limits, and its applications (use cases). If there are multiple people in the room, consider each person as an individual customer with a different agenda. What do they want to get out of this? How can you meet their needs?

Google Engineer Anthony Mayes suggests repeating the question (in your own words!) back to your interviewers to make sure you are on the same page. Ask questions, listen intently, and pay close attention to details. I recommend starting with use cases; outline on the white board the use cases you’ve come up with. Document everything very carefully; you’ll want to refer back to these tests and use cases down the line. So much of the technical interview is actually about communication, so don’t forget to turn back around to your customers and check in with them regularly. 

2. Make Reasonable ASSUMPTIONS

Before diving into code, develop a set of assumptions. The more you can get your interviewer(s) to agree with you, the better – their buy-in will help make your life easier as you design and iterate based on these pre-approved assumptions. Again, document everything. If you aren’t physically in a room with a whiteboard, document on a screenshare or notepad.

3. DESIGN a working version

Your design and the assumptions that support it need to be simple but comprehensive. Though you want to keep things as clear as possible, you’re not trying to deliver an elementary version of what you’re capable of. Think simple, elegant, but thorough.

Begin by drawing out the major components, with the assurance to your customer that you will iterate more targeted versions. The key is to make this as easy as possible for you to succeed; don’t over design, balance tradeoffs to best satisfy the set of requirements, and avoid one way doors. Don’t back yourself into a corner. 

Once you’ve laid out the key components, start to elaborate your design strategy and clarify interfaces. Keep your scope tight for this initial version and plan to iterate in the next steps. Stick with simple data structures for a one-computer version before moving on. 

4. IDENTIFY your design’s current limitations

At this point you’ve mapped out your idea, ensured buy-in, and are on your way to a working solution to the problem. It’s time you identify and share any limitations, weaknesses, or potential pitfalls with your customer. Don’t shy away from confronting where your system can fail – it’ll show that you understand the process and are willing to correct/iterate. Start laying out a list of things to fix, one by one. 

5. REDESIGN (iterate) to address those limitations

Once your “fix-it” list is complete, start knocking items off as best you can. Iterate and elaborate. While you should definitely discuss the pros and cons when making tradeoffs – to clue the customer into your thinking process – it’s important to be decisive. Every project will have limitations and the customer knows that. They want to see you reason through a complex challenge before coming to a final, conclusive decision. 

Even without knowing the exact coding challenge you will be given, you can still complete the interview successfully by looking at the process as a simple system. Remember, hiring managers aren’t only searching for technical experts – they also want professionals who can clearly explain themselves, follow direction, and work under pressure. 

I’ve worked with hundreds of tech professionals as they pursue their dream jobs. If you have any more questions about the interview process, or if you’re looking for your next tech opportunity, please feel free to send me a message!

Recent Posts