[mcv]

Excellent answer. I think the real difference between a junior and a senior is not so much in coding skill; some juniors are really brilliant coders and can fix any problem you throw at them.

But a senior has more experience with the "why" behind the coding. What are the requirements in terms of schedule, user experience, stability, maintainability, performance, development process, QA, etc. A junior can be great at one of these, but a senior has to take responsibility for all of them. So you need to understand the needs of all the stakeholders outside the dev team. (At least the basics; functional details deserve an expert of their own.)

[collyw]

I think his point about over and under engineering stuff is spot on. I did both earlier in my career, and I would say that my skill after 12 years is in knowing the correct level of abstraction, and understanding the tradeoffs between various solutions.

(Yet all the interviews I turn up to these days want an hour and a half timed coding challenge to be completed).

[mcv]

I totally agree with you (and the article) on experience concerning the right level of abstraction. I don't think there's a quick shortcut to learning that, though.

I think an interview that focuses on coding challenges isn't really looking for a senior. Point them to a junior that's more appropriate to their needs.

In most interviews I do, we do talk about abstractions and maintainability and stuff like that. Although I have recently done one that involved a coding kata, which was kind of interesting because during the kata we also moved through a couple of (small scale) levels of abstraction while discussing them, and particularly the appropriate time to abstract some stuff.