I remember in early days when I had been doing lot of technical projects. I had been successfully leading and designing the complex problems which lead me to believe I was now ready for the architect position.
However, I was still at the designer and tech lead stage and did not know how to break into the architecture world. I did not know how to prepare for the architecture position. I did not have people around me to guide me. Architecture was still a new position and not much literature was available for it. Books gave a little theorectical knowledge of architecture.
With no other options, I started to apply for the architect position. I prepared some based on the job descritions. And then armed by all the knowledge I had of technical designing a project and OOP I went through many interviews which were largely unsuccessful because of my lack of deep knowledge in that area. In the interview I was asked 50% design questions (some of which I could answer) and 50% architect questions. Design questions were to judge how well do I know my subject and how well I have been at things I say have been doing.
During firsts few of my interviews:
I was asked about the architecture styles and pattern.
I could answer few like Client-Server, Layered and PAC (Pseudo Abstraction Control) but did know about the architecture patterns like blackboard, pipe and filter etc. So I could not answer these questions satisfactorily. Here I learnt my first lesson that you need to know you subject before going for an interview.
I could solve the complex problems by my persistence and problem-solving skill, but these skills are not demonstrable in an interview unless interviewer himslef takes a special interest in forming questions to judge it. It was expected from me that I should know architecture pattern and styles otherwise I would not know there are existing styles and pattern which can solve lot of common problems.
I could solve the complex problems by my persistence and problem-solving skill, but these skills are not demonstrable in an interview unless interviewer himslef takes a special interest in forming questions to judge it. It was expected from me that I should know architecture pattern and styles otherwise I would not know there are existing styles and pattern which can solve lot of common problems.
In current context, I would be advising people to learn about the SOA, integration patterns, Architecture patterns like blackboard, pipe-filter etc.
I was asked how do I decide on a design of a class.
I started with my usual gyan of the class should be maintainable, easy to use, flexible etc. etc. But, I could not answer logical questions like "what do I mean by design easy to use class?".
All this is part of the five basic patterns of OOP and Design which we usually tend to forget while designing the classes.
SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) http://en.wikipedia.org/wiki/Solid_(object-oriented_design) by Robert Martin.
SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) http://en.wikipedia.org/wiki/Solid_(object-oriented_design) by Robert Martin.
We may be using these principle knowingly and unknowingly during design but it should be a habit to apply these principles while deciding on the class design.
Lot of tools automate these by refactoing the classes. So we apply these using a tool without knowing the actual intent or what problem did the tool solve for me.
Lot of tools automate these by refactoing the classes. So we apply these using a tool without knowing the actual intent or what problem did the tool solve for me.
When I am learning something I make a practice of not using the design tools (like eclipse provides) but code moslty using the notepad so that I am aware of all the complexity by manually adding each imports and class method and doing the changes. However, duing the project I use the Visual Desing tool becuase there the motive is to attain the high productivity.
One of the examples to explain the use of principle would be asking a questions like:
Which type of Robot would a user prefer?
A) Robot which comes with a single command like cookPasta?
B) Robot which comes with many basic command like “put pan on fire”, “pour water in pan”, “put pasta in pan”, “add ingredient” etc. And these command can be used to create a bigger command cookPasta?
I think robot (B) is very flexible because I could make him cook pasta, cook rice, cook pulse.
However, Robot (A) is very easy to use because user can give a single command to cookPasta and does not have to know insider methods and other complexity. This also explains about why we should use access scope(public,private,...) of methods .
Hence, Robot (A) is preffered by the users because of ease of use.
Hence, Robot (A) is preffered by the users because of ease of use.
I was asked what I do for performance.
I had not done much work on performance. I have been only coding and designing keeping in mind the performance, best practices. So I answered with the caching, clustering stuff but could give the satisfactory answers to the actual measure of the performance like 999 (4 9s), 9999 (5 9s). Or how do I measure and make changes in my code for giving a required performance.
Clustering is not just a deployment/adminstration domain but require a careful desiging of the classes and strategy for achieving the horizontal scaling and coding changes for deployment for avoiding SPOF (single point of failure).
Clustering is not just a deployment/adminstration domain but require a careful desiging of the classes and strategy for achieving the horizontal scaling and coding changes for deployment for avoiding SPOF (single point of failure).
This gave me an awareness of the realm of performance, capacity planning stuff which I had been ignoring till now. I went on to understand about little’s law, capacity planning using for response time, concurrent users, transaction and about performance testing. A very complex and challenging area for to master….
So my entry into architectural world from designing world was very gradual. It actually pays to take on interviews so as to understand what is expected out a person in architecture and what is happening around in the world even if we are not looking for a job.
Interview actually leads to a meaningful learning and discussion (free of cost) with a master of those fields who actually guide us into our choice of path. He asks us relevant questions about that area which helps us to know what is expected out of an architect and what kind of questions to prepare for. Provided we come out of an interview with well aware of our weaknesses and with broad scope of what my target of next learning should be.
No comments:
Post a Comment