I lost my job in December, and since then I have been looking for a new opportunity and interviewing at different companies. This got me thinking about how interviewing has changed over the past two decades.
This article is a quick review of the different types of interviews I have faced during my professional career, and how the format and questions have evolved over time… and not always for the better.
Some background on myself: I am a software developer who started in back-end development (C/C++), transitioned to what is called now full-stack (mainly with C# and .Net), and currently work as a front-end (using various technologies and frameworks.) Most of my career has been in the USA, with some time working in Europe. This context is important, as it may explain some of the trends I’ve observed.
I understand some of these changes were due to my growing experience and the different roles I applied to, but there was a general shift in the interview process at all levels across the industry.
These are the types of interviews I found over the last 20 years.
Technical Problems
When I started looking for jobs in the early 2000s, technical interviews focused on practical technical problems. The questions were based on the company’s programming language, and covered real situations they encountered almost daily. Candidates solved on paper or just discussing them with the interviewer –using a white board if they were lucky. No computers were involved at all.
This approach makes sense for early-career roles, but my friends and acquaintances at higher levels faced the same type of interviews. The main difference was the complexity of the questions, but they were always strictly related to the role and the tasks at hand.
The entire process typically consisted of one in-person session with the hiring manager and, sometimes, a developer.
Questions of Logic… and the Absurd
Then, in the late 2000s, there was a short(-ish) phase logic questions were added to the interviews. It was an early attempt to evaluate the candidate’s thought process, possibly inspired by big companies like Google, IBM, or Microsoft, who were looking for more creative developers and “out-of-the-box” thinkers.
Some real questions I was asked during this time:
- How much does a Boeing 737 weigh?
- How many light bulbs are there in the city of Houston?
- You are in the side of a gorge and want to go to the other side. There isn’t any bridge, how would you do it? (Extra points for creativity)
- If you were on an island and needed to send a treasure to a princess on another island, how would you do it if you didn’t trust the barge captain? (I liked this question because it was a classic logic problem directly related to software security)
Around this time, someone decided that asking questions like “What animal would you be?” or “Which is your spirit animal and why?” was a good way to assess a candidate’s worth. I was never asked those. The weirdest request I got during this time was “Tell me a joke.”
The process expanded from one to two sessions: the first with the hiring manager and the second with a board of developers who would basically grill you with questions and problems to solve on the dreaded whiteboard.
Bring in the Theory!
By the early 2010s, interviews shifted from practical to theoretical, focusing heavily in concepts like MVC (Model-View-Controller) and Design Patterns. The interview wasn’t complete if you didn’t get a question about singletons and their pros and cons.
Practical problems were still there, but peppered with tons of theoretical discussion and Big O questions. It wasn’t just “Is this solution efficient?” or “How would you improve it?” You were expected to answer directly “What is the Big O for this solution?”
This emphasis on theory was evident in the interview process, that now included at least two to three sessions (if not more!):
- Screening with Human Resources (HR).
- A theory interview with a manager or developer (often on the phone).
- A practical in-person interview using whiteboard or computer.
Big companies moved to “full-day” interviews: an exhausting day filled with 6–7 one-hour interviews with multiple developers and managers. The goal wasn’t just to test technical knowledge, but to see how candidates performed under stress and fatigue.
The Era of Algorithms: LeetCode Takes Over
The mid-late 2010s saw the dawn of algorithms and “LeetCoding” (and we are still here… for how long?) Companies began asking questions that, while “practical” from a technical standpoint, were still highly theoretical and often unrelated to the job itself.
You could be applying for a web developer position and still get questions like “How would you implement a red-back tree?” or “Code a skip list.” No peeking online –You were expected to know it by memory! (from a nicely interview preparation package they sent at the beginning.) This filtered out good developers that could be great matches for the job, but who were not LeetCode or HackerRank masters.
Big companies introduced more structured behavioral questions into the interviewing process. “Tell me about a time when you…” became (and still remains) a common question candidates need to prepare for.
Advances in technology and communications made interactive interviews a real possibility. The whiteboard lost popularity, and solving problems on the computer became the standard, with take-home assignments on platforms like HackerRank being increasingly common.
Smaller companies followed suit and (mostly) dropped the panel interview format in favor of multiple 1:1s on the same day. However, they reduced the number to 3–5 interviews versus the customary 6–7 in big companies.
The Pandemic
COVID-19 changed the technical hiring landscape completely: video-conference interviews became the norm, take-home assignments and HackerRank tests gained even more traction, and behavioral questions became more important than ever for companies.
With remote work, companies needed to assess that the new employee would be reliable, work nicely in a remote team, and have excellent communication skill. Also, the development world was remote now, but would it be in the future? How would this person behave in an office environment when the time to return arrived?
Common behavioral questions during this time (and even now):
- Tell me about a time when you disagreed with a coworker.
- Tell me about a time when you found a roadblock in your project.
- Tell me about a time that you failed in a project.
However, things are shifting again, and everyday more companies announce that they are going back to the office. And going back (slowly) to the old hiring ways, too.
Combined with the fact that behavioral questions are “easy” to prepare for, their overall value goes down. While their impact at the beginning of the pandemic was unquestionable partly because of their novelty and depth, that’s no longer the case.
System Design or the Whole-Department-Developer
And now, in the early-mid 2020s, interviews are shifting back toward being more technical and practical –Thanks! But at the same time, they are becoming broader and sometimes unnecessarily complex.
You are not only expected to lnow about your day-to-day tasks. You must be the Swiss Army knife version of a developer. A walking IT department with knowledge on development, back-end, front-end, APIs, databases, cloud solutions, load balancers, caches, frameworks…
The best example of this is the growing popularity of system design interviews, which usually complete the now-almost-standard hiring process of: HR screening, hiring manager session, 1–2 technical interviews, and the system design interview, spread across several days.
The system design question can be a great differentiator, but in my opinion, it has gotten a little out of hand. It can be an incredibly useful interview tool for mid- and senior-level developers, but it’s been asked even to junior candidates. Development paradigms have moved in that direction, but asking this deeply architectural questions to early-career developers without much (or any) experience doesn’t make any practical sense. –Again, in my opinion.
Making a candidate jump through that hoop just to have them run a quick query in the database or tweak a website’s layout once hired seems like a big waste of talent.
It’s the eternal debate of specialist versus generalist developer, turned into an interview question. And in some cases, it may be a sign that the company hasn’t clearly defined the role or knows what they are looking for.
Final Thoughts
As mentioned above, many of these changes aligned with my experience and role changes, so they may be anecdotal. However, the shift happened at all levels, in part as an attempt to fix a flawed system: people learn how to perform well in interviews –even if they may not perform well in the actual job–, so companies must continuously update their hiring methods.
Additionally, smaller companies often mimic the process from large corporations like Google, Facebook, or Apple, without considering if those methods suit their specific recruiting needs. (Spoiler alert: they don’t!)
It seems like there is a movement back toward more practical technical questions (a good move, if you asked me) and take-home assignments (a doubled-edged sword that can quickly turn into a poisonous apple for companies). Behavioral questions are still popular, but who for how much longer? And with the rise of AI, the hiring process will definitely change once again.
I wonder what’s next. How will interviews be in the next 5–10 years?
What about you? Have you noticed the same shift in the interview process? Or have you had a different experince? What’s the weirdest question you’ve ever been asked in an interview? Leave a comment and share your story!
Top comments (1)
This was an interesting look at hiring trends over the years! I've done a couple of take home assignments, a live coding session, and answered some theoretical questions. (Fun fact: my first web master job... part of my take home assignment was to design a tattoo in addition to designing three cattle-themed websites. It was the wild west in the early 00's) Now that I'm a manager, I'm not sure what the next interview will be like. Will they grill me on theory, system design, conflict resolution, still have me do a live coding exercise to prove I haven't lost my chops? And will employers start looking for skill using AI to speed up development time with an AI IDE? Thanks again for this article!