Stop me if this rings a bell: How would you move Mount Fuji?
At the risk of dating myself, this interview question takes me back to the start of my career in the mid 2000s. This was before Facebook was publicly available, when Gmail was in invite-only beta, and Amazon's Simple Queue Service (the first AWS product) was still brand new.
Like most other recent CS graduates I knew, I had been finishing my degree while frantically preparing for interviews. I spent most of my free hours reading books and working on sample problems (these were the days before resources like LeetCode or Grokking the Coding Interview).
As I reflect back on that early stage of my career, I see a clear inflection point in the standard interviewing philosophy — with companies shifting away from brainteasers like Mount Fuji and instead placing a greater focus on designing and programming scalable web applications dependent on large-scale distributed systems.
So today I thought I’d provide a quick software development history lesson. And along the way, we’ll even try to predict the future of engineering interviews.
Let’s jump in the time machine!
Until the early 1990s, the average person likely didn’t have any hands-on experience with computing.
Prior to the mass adoption of the graphical user interface, anyone with a personal computer was likely to be a coder of some kind. Why? The command-line interface demanded it.
Microsoft was in the process of building their first consumer-friendly, GUI-based operating system on top of DOS. First came Windows 3.1, followed by the more mainstream Windows 95. Concurrent with the Windows 9x development – still based on DOS – Microsoft was developing Windows NT, a completely new kernel and file system for workstations and servers that would eventually underpin all of Microsoft's OS development. Linus Torvalds published the first version of the Linux kernel in 1991, building on the instruction set of Unix and the efforts of Richard Stallman's GNU project.
Meanwhile, Jon Bentley's Programming Pearls (1986) taught an entire generation how to think like a programmer, and to do so in the popular languages of the day: C and C++.
Suddenly, the need for programmers expanded, transforming what had been a niche field just ten years prior. So what did all of this mean for the evolution of developer interviews?
With multiple competing operating systems (*nix, DOS-compatible, NT, Mac OS) and competing instruction sets (x86 hadn't yet become commonplace), these early developer interviews focused on two-lane programming and kernel development, relying heavily on lower-level languages like Assembly and C.
The mid 1990s marked the start of the browser wars.
Netscape distributed a consumer web browser, while America Online entered with the gateway model. As consumer demand for computers increased and the web became the primary platform for consumption, companies struck gold. The dot-com bubble spawned many massively successful companies — plus many more massively unsuccessful ones. And all of them needed talent.
Microsoft was the standard at the time. Compared to hardware and services companies like IBM or Apple, Microsoft was unique, building only software for other hardware, and even software for other operating platforms (Microsoft Office and Internet Explorer, for example, were ported to Mac OS in 1997). For the next 5-10 years, the massive rush to harvest developer talent was based on Microsoft's model. A large emphasis was placed on string processing, with a continued investment in C and C++. Meanwhile, many developers began to find career paths in HTML, CSS, JavaScript, and Java — the dominant languages of the web.
How did developer interviews evolve with these trends? One word: brainteasers.
Inspired by Microsoft's culture of the time, books like How Would You Move Mount Fuji? by William Poundstone. Subscribe to the belief that creative thinking and problem-solving skills map directly to coding and career success. (When I prepared for interviews during this era, brain teasers stressed me out the most — I never felt very confident with them).
I would describe this era of interviewing as a bit of a fad. Why? Anyone with enough time to think about it could deduce why manhole covers are round. Someone who is familiar with urban living and the size of American cities might be able to estimate the number of window washers in New York City. Anyone who passed high school geometry can figure out the volume of a 747 and approximate the number of tennis balls that could fit onboard.
The unfortunate truth is that most of these questions require familiarity with real-world scenarios (often containing cultural bias) that don't reflect applied programming issues.
When the dot-com bubble burst, there were survivors who would go on to become monoliths in their own right (think Google and Amazon), and survivors who would limp along as a shell of their former glory (think Yahoo! and AOL). What did not go away was the awareness that the Internet was the next great leap in human communication and business.
In the mid-2000s, many asked what the world wide web would be like if it wasn’t just a digital mall for dot-com storefronts. Enter what commentators called "Web 2.0" and the rise of social media.
As Internet use became mainstream, the connectivity of global networks laid the foundation for emerging large-scale systems (more on this later). It also exposed millions of home users to malicious software that could spread through a simple email.
Michael Howard and David LeBlanc addressed the emergent security issues in their book Writing Secure Code. Meanwhile, Microsoft released Windows XP on the NT kernel, and Apple switched from Mac OS to OS X, a fork of BSD Unix. This created only two mainstream OS and instruction sets: *nix and Windows NT.
Though the iPhone was still a few years away, the development of consumer-facing applications moved increasingly toward the web and cross-platform operations. This phenomenon appeared in the explosion of Java, Adobe Flash applications, and Microsoft's .NET framework.
I entered the workforce as part of this wave of hiring. Joel Spolsky's “Guerrilla Guide to Interviewing” blog post taught a new generation of technical leads to focus on hiring smart employees who deliver results. He'd later publish a book about this hiring practice called Smart and Get Things Done.
Google had killed brain teasers in favor of applied engineering practice, (i.e. actually solving problems with code). Candidates countered with books like Programming Interviews Exposed, which walked developers through comparing strings, handling buffer overflows and injected executable code, and working through real-world problems like conversions between decimal and hex.
However, this was a transitional time more than anything — a lull between the dot-com bubble's burst and the explosion of scalable services.
When I entered the field, distributed systems existed in various organizations. That said, there wasn't a body of work establishing best practices. Someone at Amazon was working on an Amazon solution; someone at Google was working on a Google solution; Facebook was scaling rapidly and figuring out how to handle the addition of millions of users (effectively network nodes) on an almost daily basis. Scaling issues were handled organically, not algorithmically.
That meant that System Design as a dedicated engineering discipline was only just beginning to emerge.
Distributed systems were getting too big and too fast for this transitional lull to last.
Amazon launched SQS in 2004. S3 became AWS in 2006. Meanwhile Google had started publishing papers in 2004 to establish consistent practices for large systems. (Google introduced MapReduce, now a standard programming model in data engineering, and then Bigtable and scalable data management.)
Microsoft, who had predicted the web as the next platform in the early 1990s, were scrambling to catch up. Their eventual answer was Azure, which started as internal vaporware in 2005 with the acquisition of Groove Networks. (I actually worked on Azure when it was still referred to internally as “Red Dog,” helping guide the product from its 2008 launch through the addition of virtual machines, locally redundant storage, and other SQL reporting in 2012.)
As my own career scaled, so did the demands of interviews.
Around this time “toy problems” started to dominate coding interviews. Interviewers would borrow questions from real-world issues and entrust them to applicants to solve in an hour or two.
Meanwhile, the influx of "big data" in the cloud – along with cloud-side processing and shared uses for that data – led Facebook to add System Design to their interview cycles in 2012. As various platforms faced similar problems scaling, these toy problems almost became standardized, to the point that Cracking the Coding Interview (first published in 2008 by Gayle Laakmann McDowell) helped thousands of software engineers land jobs.
This takes us more or less up to the present moment. But I would argue that a new interview paradigm is starting to emerge.
Cracking the Coding Interview is now on its 6th edition as it attempts to keep up with software companies that constantly update their questions in order to weed out rote answers and easy prep work. In fact, a cottage industry of dedicated interview preparation platforms has sprung up to meet this increasing demand.
If you head over to sites like Reddit or Stack Overflow, you’ll find large online communities revolving around the interview cycles for major tech companies. LeetCode has been cataloging coding interview exercises from real interviews for almost as long as I've been in the field. Educative has plenty of interview prep resources to apply the frameworks and technologies you can learn from our courses in an interview setting.
So what does this all mean for the future of developer interviews?
Like the software field itself, interviewing is a living practice, constantly evolving in response to market and product needs.
The reality is that the LeetCode library is in an arms race against tech interviewers. The hiring organizations at FAANG and Microsoft know these exercises are out there, and they create new questions all the time to try to test developer knowledge and willpower. This rapid churn isn’t just to stay one step ahead of the interview prep curve — at least in theory, it’s also to prepare software engineers for the demands of a constantly changing market as product architecture evolves with the times and customer demands.
Candidates today must go back to the basics of software engineering and interviewing. That means understanding underlying data structures and algorithms, preparing general-purpose skills that can be applied to unique problems, and understanding how various components relate to each other in object-oriented programming and multi-entity systems.
Similarly, with more intricate systems, there will be a continued focus on code efficiency. Complexity analysis is a key focus area to keep operational costs down, especially for companies that buy their cloud processing from providers like AWS or Azure.
Finally, System Design will continue to remain a huge factor (especially when it comes to determining a candidate’s starting level and salary). API Design & Product Design Interviews
are growing in popularity as well. Most engineers aren't actually building the functional building blocks of a system. Instead, they are expected to design APIs that leverage the existing system in a modular and efficient way.
In response to growing demand, Educative published a new course on Grokking the API Design Interview — the first of its kind in the industry.
There is one more important thing to note: So much of your success in the market today depends on finding the right fit.
When you're a small company like Educative, company culture develops organically; our US office is only one floor, and there are about 40 of us. But when you're running thousands of engineers across dozens of offices, maintaining corporate culture means hiring engineers who have already bought into the philosophy of what you’re building.
Amazon, for example, heavily evaluates their leadership principles during the interview cycle. Facebook hires top talent, but every new hire is still thrown into their engineering "bootcamp" where they learn the processes, products, and find a strong fit within various teams. Microsoft relied on cultural questions in their interview process when I first joined, and Google looks for qualities that they simply refer to as "googleyness."
At the end of the day, these companies have a lot more similarities than differences: they need competent code, exceptional problem-solving skills, a working knowledge of System Design & product design, and a rock-solid cultural fit.
As a tech founder myself, I would actually argue that all of these hiring factors are highly interrelated.
Competent code produces fewer bugs. In a local product, a few bugs might be fine, but when you have a product running across thousands (or in the case of Big Tech firms, billions) of instances, those few bugs add up. Scalable systems rely on clean code and problem-solving, which depends on cohesive teams that work well together. Preventing bugs in code becomes just as important as preventing bugs between people and teams. Try out Educative’s System Design Interview Prep Crash Course or Prep Handbook to start grokking the system design interview prep. For a complete interview guide, we have prepared software engineering interview prep for our learners.
I wish you luck in your interviews and hope this guide helped. As always, happy learning!
Free Resources
