Junior vs. Senior Skillsets: The Case for Hiring Juniors, Even in a Bad Market

— by Mate Gelei-Szego

A recent conversation with a colleague sparked an interesting thought about how we evaluate developers at different stages of their careers. It went something like this:

Colleague A: We couldn’t hire anyone for [redacted senior role]. Such basic things are missing that I would expect even from a junior.

Colleague B: What do you mean? That they can’t recite the SOLID principles word-for-word?

This exchange gets to the heart of a common misconception: that a senior developer’s knowledge is simply a superset of a junior’s. We assume seniors know everything a junior does, plus a whole lot more. But what if their skillsets are not just about quantity, but are qualitatively different?

The Two Types of Knowledge

  1. Textbook Knowledge: This is the formal, foundational knowledge often learned from books, courses, and university. It includes things like data structures, algorithms, design patterns, and the precise definitions of principles like SOLID, ACID, or the CAP theorem.
  2. Practical Expertise: This is the wisdom gained through years of hands-on experience. It’s about knowing which corners can be cut and why, understanding the operational realities of a system, debugging complex issues, and making pragmatic architectural trade-offs. It’s the intuition that tells you a particular solution, while technically correct, will be a nightmare to maintain. And most importantly, it’s about knowing what to do if the customer wants to pick all three pillars of the CAP theorem, because they are not computer scientists.

A junior developer, fresh from their studies, is often strongest in textbook knowledge. Not only can they recite theoretical knowledge, but they are (or should be, at least) up-to-date on the latest frameworks and concepts that I simply don’t have the time to learn. Also, with the leetcode grind that’s going on nowadays, they are pretty solid with DSA, where I wouldn’t be able to code the same SuperDuperSort algorithm even if my life depended on it.

A senior developer, on the other hand, operates primarily from practical expertise. They’ve internalized the principles to the point where they apply them instinctively. They might not remember the exact textbook definition of every letter in SOLID, but they can design a system that embodies those principles because they have felt the pain of systems that didn’t. Their knowledge has been compressed and abstracted into a higher-level understanding.

The Interview Fallacy

This brings us back to the interview question. Is it a fair or effective use of time to ask a candidate for a Principal or Architect role to recite textbook knowledge?

Probably not. Their expertise is in applying the principle, not reciting it. But here’s the kicker: juniors can actually bring that kind of knowledge and fresh perspective to the table. So even if you’re meddling with AI, coding agents won’t call you out for your out-of-date knowledge like an overzealous junior might.

For a senior candidate, the questions should be different:

  • “Tell me about a time you had to make a significant trade-off in a system’s design.”
  • “Walk me through how you’d design a scalable and resilient version of this application.”
  • “Here’s a buggy piece of code. How would you approach debugging it?”

These questions probe their practical expertise, their problem-solving skills, and their architectural intuition—the true markers of seniority.

Valuing Both Skillsets

This isn’t to say textbook knowledge is unimportant. It’s the foundation upon which all expertise is built. A team needs both: the fresh, formal knowledge of the junior and the seasoned, practical wisdom of the senior. They are not competing; they are complementary.

The junior’s role is to learn, to question, and to bring new ideas to the table. The senior’s role is to guide, to mentor, and to ensure that the solutions being built are not just clever, but also wise.

So, the next time you’re interviewing, consider the candidate’s experience level. Are you testing for the right kind of knowledge? And are you hiring from a talent pool that’s knowledge-wise diverse enough to function well?