Architect (Java) Interview Questions
Send your Question/Answer
General and general terms questionsArchitect interview is slightly different from all other interview types. Interviewer is looking for ability of the candidate to think independently on top of pure technical knowledge. Most of the questions are open-ended, prompting the interviewee to discussion about different aspects of Java development. Other side of the interview is general questions about position of the architect within the organization. Some questions do not have clear, direct or single answer and require discussion with the interviewer. On top of questions mentioned here you may be asked generic OO questions (what is class, what is polymorphism etc.)
This is an open-ended question. There are few aspects of "good" architecture:
Interviewer is looking for your experience with designing J2EE applications and your experience with J2EE technologies and general terms. This is often start of the discussion and bridge to the technical section of the questions.
You may mention design pattern books, such as "Core EJB Patterns" and web sites, such as http://www.theserverside.com
Specific technical questions
This is very popular questions that leads to some confusion. According to the second edition of "Core J2EE Patterns" and contrary to popular belief, stateful session beans are not less scalable than stateless session bean. The reason for that is life cycle of either type is controlled by Application Server and control of life cycle is what defines the scalability of the application
There are many differences. Some key points you want to mention are:
none, repeatable read, read committed, read uncommitted, serializable
requires new, required, supports, not supported, mandatory, never
Optimistic lock is an implicit lock that tries to make best assumption about locking strategy and minimize time spent in lock of resource. Optimistic lock is usually implemented with some kind of timestamp strategy. Pessimistic lock is an explicit lock that set by client.
Typical reaction to this question is very expressive answer that entity beans should not be used. There are many performancy implications with entity beans if used incorrectly. One of the famous problems are "n+1 call problem" Inter-entity bean call is very expensive operation and should be avoided.
Architect must know at least some basic design patters used in J2EE development, e.g. Business Delegate, Session Facade, VO, List Handler, DTO, Composite Entity, etc.
Typical answer is "in business tier" This usually opens series of questions like: What is business logic, how to determine business logic, how business logic is different from persistent logic etc.
JDO is Java Data Object - persistent framework that is alternative to idea of entity beans
JSP is compiled into servlet. JSP are better suit to view of information, while servlets are better for controlling stuff.
System one does not support hot deployment.
Design Pattern questions
Yes, but should not (explain why)