Interview question

[Sagar Kale]

hi all,

In the interview first question is asked explain the architecture of your project.

What is expected?

Is it necessary to draw high level UML diagram? or just explanation is enough.

[Campbell Ritchie]

Do whatever you think will clearly show the structure of your project. They want to see you understood what you were doing.

[Jeanne Boyarsky]

Sagar Kale wrote:What is expected?

They probably want to hear about the layers of your application and what technologies are used in each.

[Sagar Kale]

Jeanne Boyarsky wrote:
They probably want to hear about the layers of your application and what technologies are used in each.

What I feel are two reasons for asking this question.
1) As Campbell and Jeanne said, they want to understand structure of application and layers and technologies.
2) They get scope to ask questions on your current project to verify did you really worked on the project. And what exactly you contributed, how you handled common problems for example something used in multi-threaded environment, how concurrent access is controlled. That I understand why they ask this question.
But what I want to know what is best way to explain it. For me, I am not so good with UML high level diagrams. So I explain just by drawing layers. I try explain each layer. But will it create bad impression in my first question of interviw, that I do not know UML high level designing ?

[Gabriel Claramunt]

Depends on the kind of role you're interviewing for: for a (junior) developer, I don't think that knowing how to draw a high level UML design is important, but if you're interviewing for an architect role, you're in trouble! I would say if a senior/lead developer can't draw a high level desing in UML, he/she must be really good in the other areas!

[Campbell Ritchie]

That is not quite what I said.

They don't want to know the structure of the application themselves, but want to know that you understand the structure of the application. They probably also want to see that you can explain what you did.
And yes, they will want confirmation of how much work you did.

[arulk pillai]

In my view and from my personal experience, these types of open ended questions are a very good opportunity to impress your prospective employer(s) and interviewer(s). Also be prapared for further drilling based on your answers.


For the above question you had mentioned, I would

-- very briefly describe the application and its objective. Make it a point to emphasize the calibre of the application you had worked on if applicable --> 24 X 7 application, 10,0000+ online registered users, highly transactional system, $50 million dollar project, 200+ concurrent users, etc.
-- briefly describe the tiers (3-tier or multi-tier), layers (presentation, business, data access, TCP server, data transformation, etc) and key technologies/frameworks/tools(Java, Web Services, JMS, Struts, eclipseetc) used.
-- briefly touch on the key considerations --> I call it the "key areas" like performance, design concepts, design patterns, scalability, reusability, transaction management, concurrency control, exception handling, memory usage, software development process (agile, SCRUM, XP, Test Driven), etc.


Where possible, try to marry your answers to the prospective employers' immediate requirements. Don't over do it. Don't come across as a braggart. Request for the interviewer's approval before elaborating on certain topics that may not be relevant to the question.

[Sagar Kale]

Thanks for answers.

Gabriel Claramunt wrote:Depends on the kind of role you're interviewing for: for a (junior) developer, I don't think that knowing how to draw a high level UML design is important, but if you're interviewing for an architect role, you're in trouble! I would say if a senior/lead developer can't draw a high level desing in UML, he/she must be really good in the other areas!

I am good in other areas. I tried to learn UML using free tools like ArgoUML. I learned class diagrams, sequence diagram. I also read few books on UML and I studied class diagrams, sequence diagrams,use case diagrams, activity diagrams, object diagrams. Unfortunately I never got a project in which I can get practical experience of drawing UML diagrams. Still I am comfortable with class and sequence diagrams. So I can say I am comfortable with low level designing. But I want to learn high level designing. I don't know from where to start, any good books which will highlight high level designing. I also got trial version of Rational Software Architect. I agree if I have to apply for architect position, I must know high level as well as low level designing.

[Joe San]

If I were to apply for an Architect position, then I would have atleast done my SCEA.

[Sagar Kale]

Jothi Shankar Kumar wrote:If I were to apply for an Architect position, then I would have atleast done my SCEA.

I do not completely agree that if I want to apply for architect, I should be SCEA. Well this topic may create lot of debate, so I do not have to go into that.

I am not applying for architect position. I am just trying to identify the gap between me and architect.

In the beginning when I started discussion on this interview question, I really wanted to know what is best way to answer this question. As topic is discussed further, I am trying to identify gap between me and architect.

[Jeanne Boyarsky]

Why do you think it has to be in UML? I don't use UML for the architecture level design diagrams at work anyway. I have seen it in Visio or PowerPoint. There are just boxes for the layers.

Of course, I do use plenty of UML. But that is for the design and not the architecture. And things like use cases. But again that is design and not architecture.

[Sagar Kale]

I am not saying it has to be in UML. This question is asked in every interview. I explain it using boxes. But at the last interview, the expressions which interviewer gave, I just thought may be something is wrong if I am drawing boxes. This is why I was trying to confirm is it ok if I explain with boxes.

[Joe San]

As an architect, you should know how to organize your layers and how to manage the dependencies in each layer. You should also be in a position to choose the right technology stack for the project. Doing SCEA will help you in the direction.