Algorithms and data structures are correlated but not causal.
Do they build things that work well and are easy to maintain and scale?
Rookies tend to make, well... rookie mistakes. N + 1 problems, O(n^2) algorithms, etc tend to creep in. This could be as simple as a missing index in the database.
Intermediate avoid the rookie mistakes, but design for the problem at hand. Their foresight is either lacking or they overbuild. Either way, new requirements often lead to being painted into a corner.
Senior developers try to minimize regret. They don't build unnecessary features, but they keep future requirements in mind.
This isn't an exhaustive description, but I feel it underscores why data structure and algorithms matter. Persistent data is probably the hardest to adapt to new requirements. Knowing how to structure data so that it can be accessed properly is a huge part of the difference.
Suppose I need to track whether items are in a processed or unprocessed state.
The intermediate developer would create a boolean field on the item, allow constant time lookup on that flag so we can easily fetch all unprocessed items.
A Senior developer would recognize a few core assumptions that would make the boolean field a problem. (1) It assumes there are only 2 possible states (2) It assumes that an item will only have one state at a given time. They would seek out ways to relax those assumptions without increasing complexity. They would likely use an Enum with two states rather than a Processed boolean. That would remove the first assumption with an almost negligible cost. As far as the second assumption, they might decide the cost of removing that assumption is too high compared to the likelihood of it mattering.
A month later, we have to track which items are assigned for processing. The intermediate engineer has to invalidate a previous assumption and convert the field from boolean to enum. The senior engineer just adds an enum.
A month after that, we find out we need to track multiple assignments. Both engineers have a lot of work to do (you can't win them all).
That's the difference I frequently see. Senior engineers can see problems down the road and recognize their implicit constraints. They aren't always right, but more often than you'd expect some decision they made pays off.
A senior developer would also know to not use an enum instead of boolean when not useful and just wasting performance. (because Java and C# make you pay a lot for abstractions you don't use)
What you described is an intermediate programmer trap. A senior programmer would make a design easy to refactor if such a change is needed, but not pay the unnecessary cost up front.
First, it's hard to come up with useful examples on command. :)
Second, I was thinking more at the data persistence level. Which is harder to change than a simple refactor, and depending on the data store has zero cost (for example in MySQL booleans are just ints). They might then treat it as a boolean on the application side if there are indeed costs there.
Either way, a Senior programmer has that conversation and recognizes the potential costs down the line. Then makes decisions about the tradeoffs.
