[stuartaxelowen]

One big one: talk with marketing and sales about marketing and sales things. It helps you look into engineering from the outside, and see the other side of the interface - it shows you the pain of missed deadlines, and the surprising benefit of having that one extra feature. It helps you put real value to the output, and gives you context for measuring the worth of things you're spending time on.

[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.

[bannerbschafer]

Thanks. That is helpful. I have a tendency shared by the engineering department here to think we are separate from the rest of the business. We are in a separate building so it is hard to interact with any one but an engineer here. One of parts of the article I liked best was the idea that we are developing solutions not code, and coding just happens to be a tool we deploy often not the job.