Honeypot Cult Article: The Ultimate Guide to Passing Tech

Today is the day! I can finally share the tech interview guide I contributed to Honeypot's awesome new Cult community! Check it out below!!

A few months ago, I made the decision to begin looking for a new role in New York City.

I knew that this meant venturing into the world of competitive tech interviews so I immediately began researching how to be prepared by attempting to find guides or training courses that would help refresh and learn new skills.

Throughout the months of studying, I was able to pass Google, Facebook, Bloomberg, and Disney Streaming Services phone screens and eventually land a job at Disney Streaming Services as part of one of the Disney+ tech teams!

Below are my findings throughout that I believe will help you land that tech job too.

The State of Tech Interviews

The current tech interview process has varying viewpoints on the effectiveness and processes to find top candidates with the following topics:

  • Data structures and algorithm
  • System design
  • Behavioural and culture fit

Note: I’ll talk more extensively about the interview structure later in the article.

There are debates on how solving LeetCode programming correlates to deep CS knowledge or expertise in real-world job responsibilities. Some say our current interview structure is inherently flawed and needs revolutionising, as many topics tested are not used in our day to day work. Questions have been raised such as do we need these types of interviews and have we reached a level where too much is being asked of candidates?

No matter your view, the reality is that most interview processes have turned to using this structure, and if you want the job, you must adapt.

Such is the life of a developer :)

General Interview Information

Purpose

There are three main reasons an interview occurs.

First, the company with the job opening has a need to fill a position in the company with specific responsibilities. Second, the applicant has decided that the role could be exciting for him or her to pursue based on career interest, experience, and company mission. Lastly, with the role open and candidate being interested, both parties are using the time for evaluating the potential fit for the given position.

It boils down to this: interviews allow each party involved to ask questions and determine whether or not there is a potential fit. If there is, then an offer is made and accepted!

Biases

Unconscious biases when interviewing are a huge challenge for both the company and candidate because as humans, we make split-second impressions on one another that can be totally off-base. These biases can be based on wardrobe, diction, race, and more - making it tough for interviewers to give impartial feedback.

It’s been said that even at Google, it’s possible for every person who currently works there to find a group of hiring committee members who would have passed on your candidacy.

As a candidate, you have no control over this.

The silver lining here is that HR professionals are aware of this and do their best to find processes that help baseline candidates without biases playing into it.

False positives / False negatives

Tech companies have openly admitted to having high standards for their hiring committees. It’s better to miss out on candidates who are close to the hiring standard so they only hire those who are above it.

Luck

There are numerous tech-screen and on-site interview questions that can be asked. It’s not possible to know how to answer each and every one of them. That’s where some luck is involved.

For example, questions are random but you may get one you’re familiar with or you might have an interviewer who knows how to give better tips that route you towards the answer (compared to those who remain silent).

As a candidate interviewing for your dream job - you want the best chances for getting an offer.

That’s where preparation comes in.

Preparation helps combat luck - as the quote goes, “Luck is a matter of preparation meeting opportunity."

Preparation

Interview prep is a marathon, not a sprint.

There is much to study and know, some of which we don’t use on a regular basis. It’s a learning experience to become a better developer and one that if taken seriously, teaches you quite a bit along the way.

There are many topics to brush up on and platforms to help (see resources) - of course, others may have a different opinion than my own. I encourage you all to comment and discuss so we can tackle it together!

The first step in finding a new role starts with detailing out what kind of role you want.

What’s in a Role

You spend a substantial amount of time at work. It’s important to find a role and company that makes the time spent meaningful to you.

The environment, the people, and the type of work heavily contributes to your overall happiness.

At first, when thinking through tech interviews, most of my thoughts were on technical skills. Yes, these are important, but even more important is the environment in which you use them.

We must choose wisely.

It’s said that interviews are also your opportunity to interview the company.

You will take advantage of that if you investigate what kind of work environment you are looking for - ask about the team, the culture, and any other question to get details on parts of the job which are most important to you.

Here are a few example questions to get your brain turning:

Organization:

  • What are the team structures?
  • How are teams aligned?

Performance:

  • How is performance measured? Meaning, how do you know as a team you’re doing well?
  • How is individual performance measured? How would I know I’m doing well?

Workload:

  • How is work planned?
  • How is capacity measured?

Culture

  • What was the last thing that you broke or the last mistake you made?
  • How are design and architecture decisions made as a team?
  • What is your favourite part of the office?
  • What is your favourite part about working here?
  • Is flexible work allowed?

Career:

  • What growth opportunities are there and training?
  • How do developers grow in their career here?
  • When was the last time someone on the team received a promotion?

Dev Mentalities:

  • What version of React or Angular are you using?
  • What ESLint module is used?
  • What styling methodology?
  • How strict are standards?
  • How is tech debt handled?
  • Unit testing requirements?

Tech Study Guide

In the tables below, you can see the process I tried to follow during my studies. I didn’t follow it 100%, but it did help give some organisation on my progress.

My research informed me that before taking on practice problems, a better approach is to first learn the data structure itself.

For example, you can learn how Linked Lists work and their structure in memory, implement one in CodePen, make flashcards for them, then practice linked list questions on LeetCode.

This really helped solidify the learnings, because as you go from easy to more challenging questions on LeetCode - you quickly notice that the harder problems require base knowledge of multiple data structures to solve.

I’ve created an Interview Training Guide for you - check it out!

Soft Skills / Behavioural

Not only are tech employees required to know technical topics, but soft skills are also recognised as an important skill set in Software Engineering. Developers collaborate and talk to each other all day.

Every company looks for people who fit their culture, so researching a company before the interview can help you tailor answers to them. Remember - we all have unique experiences that make us strong candidates

Here’s how I advise preparing for situational and behavioural questions:

  1. Create a list of situations your proud of, using your resume as a baseline to help remember them
  2. For example - contributing to a team project that refactored 80% of the code base
  3. Put each situation into STAR format with bullet points
  4. Situation
  5. Task
  6. Action
  7. Result
  8. Practice saying those situations in the mirror
  9. Practice answering common situational questions (see resources below) and applying those situations to them

Applications

There are so many different opportunities in the market today! Finding a role you are interested in and applying isn’t difficult, but getting your application viewed and accepted can be. That’s why referrals and utilising LinkedIn can be very helpful to getting through the competition. I’ll share a video from an interview with a Google Recruiter where she details the process of reaching out to recruiters in more detail.

I won’t go into detail on making a resume for this article, but did link a resource below for creating one.

Further, if an online application asks for an optional cover letter, and you have doubts on whether to complete one or not - ask yourself this: if you were evaluating between candidates for a job, and only 1 of the 10 who applied took the time to go the extra mile and send the cover letter, which one would you think of hiring first?

Typical Interview Process

Throughout my job search, the interview process typically followed this pattern.

1. Recruiter Call

If a recruiter has reached out to you about the job after submitting your resume, it means you have passed the initial resume screen! The next step, talk to the recruiter who manages the process for the role you’ve applied for.

All of my recruiter calls were very friendly and gave me the opportunity to ask some baseline questions about the company, learn more about the job responsibilities, and tell the recruiter about myself.

If the call goes well, the recruiter will tell you the process for interviewing at the company and ask you to set up time for your technical phone screen.

2. Phone Screens

Technical phone screens are usually conducted by Software Engineers at the company you interview for. They start with quick introductions and lead into one or two technical questions in Google Docs or CoderPad, allowing you and the interviewer to work through the given problem.

The recommended approach for solving questions during interview settings can be read about in detail below, but my process typically followed this path:

  1. Clarify and re-write the question asked in my own words to make sure we’re on the same page
  2. Talk through data restrictions / constraints and ask questions about input/output
  3. Create simple test cases
  4. Brainstorm a few different approaches out loud
  5. Pick a solution and start with high level pseudocode
  6. Ask for feedback along the way
  7. Code it
  8. Run through test cases
  9. Talk through Big O (algorithm performance)
  10. Wait for next question

3. On-site Interview

On-site interviews are different at each company, but generally have similar sessions. Two coding rounds, similar to the phone screens with a little more difficulty. A system design round, touching on distributed system questions. A behaviour and culture fit round.

The same format can be used for technical questions.

There are various approaches to system design answers, but by looking at the resources below - you can find an approach that works best for you. The high-level steps are:

  1. Clarify requirements and scale
  2. Optional back of the envelope requirements
  3. Create a high-level system design
  4. Revisit and dive into details of each component

4. Offer / Negotiation

If you have reached this stage, you’ve passed your interviews and are now just working through terms that both parties can agree on. I’ve included some resources below for learning more about this part of the process.

Once those are agreed upon, the last step is to celebrate!

Concluding Thoughts

Finding a new job is an arduous process that takes time and focus. We apply to many roles but only hear back from a few, hoping we can muster up the required answers and make the best first impression we can.

In less words - job searching is difficult.

I hope that having this guide will make it easier for you while teaching you a few things along the way.

Good luck!

Resources:

Algorithms

Behavioural Questions

Data Structures

General Information

Platforms to Practice

Salary / Negotiation

System Design

comment

Comments