Most items below are relevant for a senior developer too, but this discussion is about software architects. By “Skill” I mean something practical, relevant, value-adding… An architect should bring some of these skills to a team. Think of these as job duties, if you like.
skill – insight on the limitations of a large number of impractical/discredited designs. Everyone can come up with some solutions on-paper, but most of them won’t work.
skill – know a large number of common errors and solutions — usually available on google but way too many. You don’t need insight. Just awareness is valuable enough. This comes from “mileage”.
skill – insight on weakness and limitations of dominant, default solutions (like Oracle, linux, WCF, protobuf…)
skill – insight on project best practices and their limitations
skill – know a large number of FOSS and commercial solutions
skill – write library component for others. The more developers use the component, the more senior this author is
skill – practical testing strategy, automated or not. Junior guys may be too busy to worry about these. Testing can be tricky.
skill – tuning, optimization. Often overrated relative to GettingThingsDone.
** memory mgmt
** data structures nitty-gritty
Those are the skills interviewers like. Here are some evidence interviewers look for —
evidence – ability to clearly describe past systems, their design trad-offs, architecture, challenges, limitations,
evidence – ability to draw simple (but effective!) diagrams to illustrate any technical design
evidence – contribution to FOSS
evidence – know algorithms and their computational complexities. Google? Often overrated.
evidence – can identify and apply comp science constructs to programming problems, independently, without guidance — tough. Often overrated.
evidence(?) – know the “gory” details of popular languages
evidence – brain teaser mastery
evidence – design patterns. This is one of the laziest interview tests — ask the candidate to describe how he employed DP.