Coding interview questions: an origin story
Preparing for a software engineering interview is not easy. We’re expected to practice solving dozens or even hundreds of programming problems. We work on problems related to all sorts of data structures. We practice several problem-solving approaches. For many, LeetCode is considered the ultimate resource. We work on problems like “Find the kth largest integer in an array,” “In-place reversal of a linked list,” etc. The list goes on and on. If you’re like us, you must’ve wondered who comes up with these problems, and where these problems come from. This blog is a historical perspective on this topic.
The origin story of coding interview questions#
Place yourself in the shoes of a software engineer at Amazon many many years back. The recruiting team has scheduled an interview for a candidate with you. When you walk into that room, what questions do you ask? Sure, you can ask the candidate about the fundamentals, such as:
What is the time complexity of an insert operation on an array?
What is the space complexity of merge sort?
What is the space complexity of a trie data structure?
While such knowledge is essential to the candidate’s desired role, what’s even more important are their problem-solving skills and proficiency in programming languages. For that, you ask them to solve certain programming problems.
Today, we have pools of popular coding interview questions all over the web. But where did those popular interview questions come from? Who came up with questions like “Find the kth largest integer in an array,” and why? This blog answers this question. Let’s immerse ourselves in a hypothetical situation from the past.
The background#
Suppose you work for the team that maintains the recommendation system. You are presently working on rolling out a new feature. There’s an ongoing promotion under which purchases worth a hundred dollars or more are eligible for free delivery. If a customer is about to check out with a shopping cart containing items costing less than a hundred dollars, you want to recommend to them some products that, if added to the cart, would make their purchase eligible for free shipping. To best utilize the web page real estate, you want to recommend exactly two products. Also, while any purchase above a hundred dollars qualifies, you want to recommend products that take the total bill to exactly a hundred dollars.
You analyzed the problem and concluded that the input to your code will be a list of numbers (representing the prices of items) and a target number (a hundred minus the customer’s total bill). You also realized that what your code should do is find two numbers in the input array that add up to the target.
The interview question#
Since that feature development is at the top of your mind, you ask the candidate the following question:
“You are given a list of integers called numbers and an integer called target. You are required to find the indexes of two numbers that add up to target in the numbers list.”
The bottom line is that a long time back, pioneering interviewers would ask candidates questions based on the problems that they were solving then or had solved in the past because they had analyzed those problems. They knew the brute-force solution to those problems, and they knew the optimal solutions. They knew the time complexity, and they knew the space complexity. They even often knew variations of those problems and how those variations affected the optimal solution.
What happened next?#
Word spreads fast. Candidates coming out of these interviews shared the coding interview problems. Not all interviewers have the same richness of experience. Moreover, good interview questions are hard to design, and interviewers need a big pool of questions in order to ensure that the candidates are assessed effectively. So, other interviewers started using these brain dumps of coding interview questions in their interviews.
Analysis#
Knowing how to find the indexes of two numbers that add up to a specific value is great, but that’s only part of a software engineer’s role. The story above demonstrates that there are two steps to developing a feature:
The journey from a feature request to a coding formulation
The solution to the coding problem
Present-day coding interviews mostly focus on the second step. But the first step is also an integral and key part of a software engineer’s role. Of course, there are time constraints on an interview, so we can’t judge every candidate on all aspects of the role. But from a candidate’s perspective, being prepared for the whole journey is very useful. We’re setting our career up for success from the word go.
What did we do about it?#
We realized that this experience was missing in the coding interview preparation of the average candidate and created courses that cater specifically to bridging this gap. Here’s what we did:
We curated a list of the most popular LeetCode coding interview problems.
We mapped them onto product features for familiar domains, like social networks, e-commerce, video streaming, etc.
We created courses in several popular programming languages in which each lesson presents one of the product feature scenarios above and asks the learner to try to implement it. We also provided guided solutions.
We call this series of courses the “Decode the Coding Interview” series. Here’s the list of the courses:
We hope you enjoy taking these courses as much as we enjoyed creating them.
Free Resources
