The role of a piece of software is to simulate something. In the abstract, someone has an idea and sketches it out on a napkin or piece of paper. Then they attempt to commuicate that idea to someone who can simulate it in a piece of software. The problem is communicating the depth and breadth of the idea from the person who had it to someone who can reinterpret it in software. Short of a Vulcan Mind Meld, it's a very imperfect process.
If it's a large enough project then the initial contact person may serve as the lead architect. Then he has to elaborate on the idea and spread the word to everybody else so they get it.
Invariably there's always a barrier of sorts that shows up when it becomes necessary to translate abstract concepts of the idea into concrete declarations and imperatives in some programming language.
Based on my 40+ years of experience, I'd say most programmers have a very difficult time overcoming that hurdle. They need someone to write out algorithms for them to use, the preferred data structures and approaches needed so they don't conflict or compromise other parts of the system, and other things that just aren't quite visible to people who haven't got a lot of experience.
I don't know what constitutes a "senior developer", but I know most programmers have a really tough time dealing with abstractions. And those that ARE good with abstractions frequently get lost in low-level details. (That's me.) A frightening few can bridge the entire spectrum.
I think it's more valuable to know that programmers tend to start out focused on very concrete things. People who are self-taught tend to stay there, while people with CS degrees tend to be able to deal with abstractions more easily.
After a while and several battles later, some people begin to see the abstractions more clearly and they become informed by past designs.
People who employ copy-and-paste programming should be shot, IMHO, because they're stuck on the concrete side of the wall and they only allow abstractions to inform then what code from their past they can copy. Sorry, you want to be informed about the general approach, not the exact solution. A different solution may be called for that accomplishes the same end.
Anyway, regardless of where you're at in this spectrum, spend a little time observing people and notice whether they can discuss a problem in abstractions or if they need to write code or see an example before they can really deal with it.
This is why I think giving people coding problems during interviews is a Very Bad Practice -- you want people who can discuss things abstractly, not be rooted in concrete thinking. Concrete thinkers are great, but they need to be guided by those who can bridge that gap, and THOSE folks tend to not do well with rapid-fire coding tests. They get eliminated when they should instead be asked a totally different question -- one that most of the successful coding rats will fall flat on their face trying to answer.
