Do technical interviews scare you?
Have you ever been surprised to learn that you’re going to have do a technical interview for a non-engineering role?
But I’m not looking for a software engineering job….
😱 Immediately, fear and panic set in.
You start replaying back every second-hand horror story you’ve heard about technical interviews. Buzz phrases like binary search tree algorithms, Big O notation, and data structures float through your mind.
You frantically jump to ridiculous conclusions like,
I need to learn how to code in 2 days! I’m going to do every exercise I see on Codecademy!
Wrong!
The reason for a technical interview
The main purpose of a technical interview for a non-engineering role is to evaluate how well you will work with engineering teams.
This is especially important for roles that work closely with engineers, like Product Managers, Product Designers, Product Analysts, Solution Architects, Sales Engineers, and Growth Analysts. Even roles in Marketing, Business Development, and Sales may require a technical interview.
All that to say, if you’re interviewing at a tech company, expect to go through some sort of technical interview.
What to expect for the technical interview
Just to get something straight, a technical interview for a non-engineering role won’t require you to write code.
You don’t need to learn how to code to prepare for a technical interview for a non-engineering role. However, you do need to understand how software products are built.
For non-engineering roles, you’ll be asked a question* like,
Tell me about a technical project you’ve worked on
*As a caveat, some data analyst roles may require a SQL coding interview. You may be asked to write pseudo SQL code to find the answer to a product or business question. You’ll probably be given hypothetical database tables with their schemas and asked to set up a SQL query to help answer the question.
Generally, you’ll be interviewing with a software engineer.
The software engineer will ask you an open-ended question like the one above and probe into your answers to get a sense of the depth of your technical understanding.
Using the technical project question example, the interviewer may ask you to explain all of the technical systems involved and how they all fit together. They may dig deeper into one specific system and ask you how it works. They may also ask why certain technical choices were made, what tradeoffs were considered, or other solutions that were considered, until you reach your technical limit.
For instance, let’s say you’re interviewing for a Product Manager position.
You’re asked about a technical project you’ve worked on. You mention shipping a new user onboarding experience for your company’s mobile apps.
The software engineer interviewing you will ask broad questions and will dig deeper into the answers you give. Here are some starter questions the engineer may ask:
- Walk me through all the technical components involved to build the new user onboarding experience. What client-side and server-side components were involved?
- Tell me how the logic behind the feature works.
- What were some technical tradeoffs you had to make? Why?
(See below for an example technical interview answering these types of questions)
What kind of answers are they looking for?
For non-engineering roles, tech companies are not expecting you to understand every technical detail or how the code was literally written in the technical project you chose to talk about. Rather, concretely, they want to know if you:
- Understand how software products are built
- Appreciate how technical details can impact business decisions
- Are curious about how things work and actively pursue learning new things
Again, the main purpose of the technical interview is to see how well you will work with engineers and your level of technical understanding can signal how well you empathize with software engineers.
For instance, a red flag would be if you can’t even identify the technical components of your project.
Using the product manager interview example from above, it would be critical for you to understand the technical work that was needed in both the mobile app itself and the server. Also, it would be important to highlight the critical pieces of information that needed to be communicated between the mobile app and server to build your feature
If you can’t explain the major technical components involved and how they fit together, the software engineer interviewing you won’t have confidence that you know how technology products are actually built. They want to be wary of people joining their team who will blindly say things like,
It’ll be easy, we’re just changing that one button, how hard could it be?
and
I don’t understand why the engineering team is taking so long to make such a simple thing, why can’t they just get it done?
Even if there’s a small change to a feature, there may be complicated technical details underlying that change. As a non-software engineer, you don’t need to know all of the details, but you do need to be aware enough to know that for any project, there may be potential technical dependencies that require tradeoffs.
How to prepare for the technical interview in 3 steps
1. Select a project
Make a list of projects you’ve worked on that have had technical components. It could have been a project setting up an automated process, shipping a new feature, or building an internal tool.
You don’t have to have been the one doing the programming or the one leading project, but pick projects where you were the main representative from your team. Think about which projects you were most deeply involved with and which projects you have the most details about. Use these guidelines to help you pick what technical project you’ll talk about in your interview.
Resist the temptation to choose a flashy project you were involved with peripherally. The technical interview is designed to get into the details, picking an impressive sounding project that you can’t talk about in depth will set yourself up for failure.
2. Do research
Once you’ve selected a project, review meeting notes, emails, and documentation from that project.
Write down notes about the general overview of the project, answering these questions:
- What problem was the project trying to solve?
- Why was it important to solve?
- What teams were involved?
- What was the outcome of the project?
Then, get more details about the technical components of the project by answering these questions:
- What were the technical systems involved?
- How did all the technical systems connect to each other? What information was communicated back and forth?
- Were there any technical issues that came up during the project?
If you can’t answer these questions off the top of your head, go find the answers yourself by asking other people who worked on the project or reading through any technical documentation from the project.
If you ask these questions to someone from the project, make sure you go one level deeper by asking why certain decisions were made and the reasons behind the way technical solutions were implemented.
This is all of the content you’re going to need to be successful for your technical interview.
3. Practice the technical interview framework
Now that you have all of the content ready to answer the technical interview question, practice delivering your answer.
During a technical interview, it’s easy to ramble about small details that don’t matter and gloss over critical points, making it difficult for the interviewer to follow your story. We’ve all been there. Usually, when this happens, you’re not going to be getting the benefit of the doubt, especially in a technical interview where it’s important to highlight the right details.
Here’s how to frame your answer when you’re asked to talk about a time you worked on a technical project.
Technical interview framework
- Set the context
- Whiteboard or draw out the technical systems involved
- Label how each system connects to each other
- Describe the solution by walking through how it flows through the technical systems
- Ask where the interviewer would like to dig deeper
Let’s run through an example.
Let’s say you selected a technical project where you were the partner manager at an online gaming company and you were responsible for launching a co-marketing partnership with a popular gaming blog, Gamer X Blog.
Interviewer: tell me about a technical project you’ve worked on.
Framework Step 1: Set the context…
I was the partner manager who launched our partnership with Gamer X Blog. We wanted to increase the number of paying users by offering a discounted price for our game to the blog’s readers for a limited time.
I worked with engineers on our team and the technical contact for the blog to launch this partnership. Ultimately, this partnership increased the number of paying users by 5%.
Interviewer: tell me what all was involved
Framework Step 2: Whiteboard the technical systems…
As you’re going over the technical components, draw them out on the whiteboard.
We gave the blog a unique url to our promotional landing page. Visitors could sign up to receive the discounted offer. Once a user signed up using their email address, our server would check if the user was eligible for the promotion.
If that user was eligible, they would receive the discounted offer and be able to buy right there. If they weren’t, they would see a different page letting them know they weren’t eligible for the discount. If an eligible user hadn’t purchased the discounted offer in seven days, they would receive a reminder email.
Then segue into a specific flow by saying, “let me walk you through a specific user flow”
Framework Step 3 & 4: (3) Label how each system connects to each other and (4) Describe the solution by walking through how it flows through the technical systems…
Write on the whiteboard how everything fits together:
Our partner, Gamer X Blog, wrote a post that included the custom URL to our promotional landing page.
If a visitor signed up for the promotion with their email address, that information would be sent up to our servers, along with the current date, IP address, and “blog ID”. The blog ID was a unique identifier that we stored in our backend to attribute which partner was driving us new user sign ups and new paying users.
We tracked IP address because this promotion was restricted to users in the U.S. Also, we tracked the date because in order to be eligible for the promotion, you had to have been a new user who signed up within 3 weeks of the initial blog post publish date.
With this information, our server would determine if the user was eligible. It checked with our user database to make sure the email address wasn’t associated with another user so that we only offered the promotion to a new user.
If the visitor was a new user, based in the U.S., referred to the landing page from the Gamer X Blog post within 3 weeks of its publication date, we would show that user the promotional response page where they could buy the game at a discounted price. Otherwise, we showed a response page to let the user know they were not eligible for the discount.
In the user database, we kept track of the new users we acquired from this blog. Amongst other pieces of information, the user database had fields for email, geography, blog id (to identify where these users came from), if they were paid users or not, and the payment date.
Using those fields in user database, the server would communicate with our email system to email eligible users who signed up through this partnership but hadn’t purchased the game within 7 days of signing up.
Framework Step 5: Ask where the interviewer would like to dig deeper
After running through the example flow, ask the interviewer,
Is there a specific area you’d like for me to explain further?
After asking this, the interviewer will continue to probe either on specific details or ask about how you worked with your teammates to get this project done.
Once you get this far, you’ll be in good shape as you’ve demonstrated a solid technical understanding of a real, live project.
Practice, Practice, Practice
These technical interviews aren’t easy. It will take practice to get comfortable using the framework to walk through a technical project in an interview setting.
Practice by yourself.
Talk through a technical project out loud and in front of a whiteboard if you have access to one. If you don’t, just use a sheet of paper to draw out the technical components.
Practice with a friend.
Do mock interviews. Show this framework to your friend and run through a simulated interview together. Even if it’s awkward, power through, you’ll learn where you need additional practice.
Practice by recording yourself.
Voice record your practice sessions and listen to them. You’ll hear if you ramble, have nervous tics (saying “like” all the time or “um”), or if your answer just doesn’t make any sense. I highly recommend you do this, you’ll be amazed at what you learn about your interview style!