Warm-up to Tech Interview Prep

The interview process for software engineer candidates these days is not straightforward. It is derived from the processes used at MANGA(!) companies (Meta, Amazon, Netflix, Google, Apple). Because of the sheer quantity of applicants, the interview process rejects good and even great engineers. The goal was that only the best would make it through this gauntlet, and the companies would be all the stronger for it.

The process is to ask programming questions whose solutions require outside-the-box thinking. While brute-force solutions can solve the problem, brute-force solutions tend to be very inefficient. Arriving at an accurate and efficient algorithm requires a deeper understanding. The process is typically collaborative, and the interviewer sees how the candidate thinks and interacts with others while working.

Sites exist to help developers practice writing these algorithms. leetcode.com is one one example. In my experience, I have found that these sites are fantastic for practicing, but less effective at teaching.

But all is not lost! There is a real benefit to learning these algorithms and design patterns. If candidates approach this with the perspective of adding to their tool belt, it becomes easier for them to adapt the tools to different jobs. If candidates grind out problems, hoping that quantity will be sufficient, they do themselves a disservice. The tools they will have gained are less capable and unable to adapt to similar but not identical jobs. A candidate must approach this learning carefully. The best method to tackle these topics is not the most advertised.

Before You Start

#

The worst approach is to jump in and start solving problems. Far too many hope that they’ll learn a language and learn to ace the interview in one go. This approach rarely pans out.

Competitive coding sites often discourage best practices and readable code for brevity, otherwise known as “code golf.” In a professional environment, unnecessary brevity and poor naming choices are not typical. A candidate who only knows “code golf” methods raises red flags for the employer.

Tackling problems on these sites should be the last step of your journey. There are milestones that I feel are important to achieve before solving the challenges found on competitive coding sites.

Know *A* Language

#

Do not expect to learn how to code while solving algorithmic problems. Study and feel confident in your knowledge of a language first. You don’t have to be a guru, but you should know the syntax, a fair amount of best practices and patterns, and be familiar with the language’s standardized libraries.

Solving algorithmic problems can help you learn a new language, assuming that the other points in this section are already covered. You should have a reputable learning resource on hand as well. Best practices often get ignored in favor of cryptic code. The best approach is to treat these exercises as homework and a method of building muscle memory after learning best practices.

Know About Data Structures And A Couple Of Algorithms

#

Beyond knowing a language’s syntax, one must comprehend the fundamentals of data structures. Arrays, linked lists, stacks, and trees are examples of data structures. They are all different from each other. Some data structures are better suited to specific problems than others. Operations such as insertion have different behaviors. Before you can start solving algorithmic problems, you should be able to identify a data structure that will likely be the best fit.

Learning about data structures and writing them from scratch will provide the foundation you need for some of these algorithms. An easy example is that traversing a linked list prepares you to reverse a linked list in place.

A couple of algorithms to know before jumping into the deep end would be binary search, counting, and two-pointers.

Know How To Determine Runtime

#

Also known as Big-O notation, it’s the way developers communicate about how long an algorithm takes. A quick example would be finding duplicates in an array. The brute force method typically has a runtime of O(n²). As the input grows, the time required for the brute force algorithm grows exponentially with the size. If an array has one million elements (10⁶), it takes approximately one trillion operations (10¹²) to complete. That’s very wasteful! Companies naturally want their code to run as efficiently as possible.

Knowing how to examine code and approximate the runtime is an important skill. It’s also important to know the runtimes of typical operations on different data structures. A quick example is that insertion into a data structure can be O(n) (arrays), O(1) (also called constant time, hash maps), or O(log n) (binary trees), depending on the data structure.

Diving In

#

Now that you’re ready to start learning these algorithms, there is still one guiding principle to remember. Internalize the principles and patterns, and don’t rely on rote memorization. The “sliding window” algorithm can solve many kinds of problems. And it can take on many different forms. Is the window fixed- size or dynamic? Does the window move smoothly through the data, or can it jump? If the window can jump, is there an overlap? The answers to these questions already provide eight ways to implement a sliding window.

Instead of blindly memorizing specific implementations for specific problems, focus on the patterns. There will be wording and requirements that hint at a sliding window being the algorithm to choose. Once you recognize what algorithm is required, you can zoom in on the details to answer the specific questions about how the algorithm can be applied.

Using a pattern-based approach makes your knowledge more flexible. Another way to think about this is that a pattern is like a socket wrench, and variations are the different sockets you can attach. You have one tool that works in many different situations. Rote memorization is equivalent to a socket wrench with a specific socket fused on. A slightly different problem will require a whole new tool with its fused socket. Comparing the two tool chests shows a clear winner.

Both rote memorization and pattern recognition require seeing a large set of problems. The differentiator is the mindset you bring.

“But I Just Need a Job!”

#

Like many things in life, the proper way to do something is not always the quickest. The video below is a bit cheeky, but still offers some good advice for handling technical interview questions. Although it might seem much simpler, properly following the speaker’s advice still requires a lot of practice and study.