Next week, I'm interviewing another architect, so I've gone over my list of "things to ask an architect candidate" for another time to see if I'd change anything. Not much popped out, but I thought I'd share some exercises that I ask architecture candidates to run through.
Note: I care more about experience than book learning, but I care very much that you know the actual names for things. In other words, book learning does matter. If you never got around to reading any of those 'patterns' books, don't bother to show up. You wouldn't be considered a qualified medical intern if you referred to the Biceps Brachii as the 'upper arm muscle' and I won't consider you an architect if you can't tell that I'm using a Strategy pattern in my case study.
The things that a systems architect must do to survive an interview with me:
- Demonstrate the ability to work on a project team with developers productively
- Describe a time when you created a vision for a systems architecture, communicate it, and others made it come into existence
- Tell me how you know when it is time to review code for compliance and when you are better off getting out of a developer's hair
- Be able to guide and direct the team in the art and science of visual modeling (it's not enough to know... you must also teach).
- Detect the gaps in the early design artifacts of a project and determine what risks are going unmanaged.
- Be able to convince me that you understand, in your bones, the concepts of coupling, abstraction, and encapsulation.
- Be able to describe at least five GoF patterns in fine detail. Be able to describe at least five messaging patterns in fine detail.
- Pick a single system quality attribute that should be paramount in a particular situation, and then explain why.
A. James is an IT architect working with a team of 5 developers and 5 testers on a new system. He has a situation with his development team. He presented the high-level design for their new system at a dev meeting and the team listened politely. Then, after reviewing his diagrams, some of the members of the dev team concluded that he has created a great deal of complexity in one area that they think is overkill. James hears about it from the project manager three days later. He feels pretty strongly that the complexity is called for. Evaluate the situation. What dynamics are at play? James comes to you for advice: what do you tell him?
B. Let's say that you have 10 systems in an infrastructure. One of them provides the list of all customers, while another provides the list of all orders. You want to keep the systems as decoupled as possible but they need to share data in real time. What mechanisms do you put in place to keep the systems independent, yet fully integrated? Describe the steps you would follow to replace the system that holds orders.
C. Draw the architecture of one of your most complex systems on the white board. Now:
- What made you partition the system in this way?
- What data entities are mastered by your system? Which components are responsible for actually writing the key data about each entity?
- What changes do you predict the business will want in the next 2-5 years in this system? How will the architecture cope with those changes?
- What system quality attributes did you consider most paramount when designing this system? What attributes did you sacrifice?
- Logical Data Model showing every data entity in the system's database
- Deployment Diagram
- Class-level architectural diagram illustrating the use of design patterns
if (paramx != null)
do_something_specific(paramx);
What patterns do you discuss with your junior developer? What options do you consider? Do you advise the developer to change the code? Why?
F. Pick one of the following practice areas and describe the ideas and concerns that led to this area of software development practice, what the practice entails, the benefits that can be achieved, and the negative consequences that may be observed by teams engaged in the practice. Note: I may pick one for you... be prepared to be asked about any of them. (If you were to ask: "why this particular list?" I'd turn that around and ask you why I picked this list... )
- Service Oriented Architecture
- Test Driven Development
- Aspect Oriented Programming
- Dependency Injection / Inversion of Control
- Software Factories
Không có nhận xét nào:
Đăng nhận xét