Skip to main content

Java Architectural Knowledge for Job Interviews. Are we prepared?

Posted by giovanisalvador on May 22, 2008 at 8:24 AM PDT

I already interviewed lots of Java developers during hiring activities. As part of the interview, besides other things, I like to understand if the person being interviewed has understanding of the applications he/she develops as a whole, I mean, not only understands business requirements but also understands the entire architecture of the application and, most important, why that specific architecture is in place for that application and its specific needs.

So below a typical dialog between a candidate (C) and I regarding architecture of a Java EE application.

- So, could you please describe, from your perspective, what should be a typical Java EE architecture for, let's say, a medium-size web-based application?
C - Of course. Well, typically I will have in place a lightweight container like Spring and persistence mechanism like Hibernate. Spring will do everything for me.
- Alright, let me be more specific, I believe my question was not well-built. Imagine if the end user is about to submit a form data. What will be the flow that data would take to be persisted in database? Describe to me the building blocks, all the path of the data, which objects will apply business rules, which objects will handle web requests, etc. Feel free to draw this architecture if you think it is better for you.
C - Not necessary. Well, I would put Spring MVC in place to handle all the requests. For persistence, Spring DAO with Hibernate support.
- hum, I think you haven't got the point. Forget about Spring. forget about EJBs. Forget about lightweight or heavyweight containers. Forget about Hibernate. Imagine you don't have these technologies to assist you. You have to propose the architecture without using any specific product. What would you do? Remember, no products. Just give me building blocks.
C - .....
C - .....
C - In the presentation layer an object will take all data submitted and...
- Which object?
C - hum...... maybe a Servlet object or .....
- Or a managed bean, something like this? Ok, go on. Once data is retrieved from the UI, what will happen?
C - ... ok, data will be sent to an object and this object will perform business rules and after that data will be persisted.
- Could you please be more specific? Do you have in mind any design pattern that could assist you for this architecture? What would be the structure for the domain layer? And Persistence layer?
C - ...
C - Man, I would work with Spring, it does all those things for me.
- Alright, that's good for me. Thank you.

Let me say somethings about this dialog.
First: I don't have any problems with Spring. In one of my posts I said that I never used it because I never had to. We need to find solutions for our problems and not create problems for given solutions. By the way, comments in that post were great.

Second: The candidate never asked how many transactions per minute, hour, etc, how many concurrent users, if it is a critical application. That dictates the architecture. We can't have silver bullet and it seems today most of the "architects" have silver bullets. And, even worst, relying on specific products. Also, based on the non-functional requirements of the application we could see if clustering would be needed. But no, no question about those kinds of things at all.

Third: The lack of knowledge on some typical design patterns is also something to take into account. Façade? DAO? Value Objects? Application Controller? Even if we don't need all of them, candidates should be prepared to use them when necessary.

I know it is hard in an job interview to remember all those things. And I really don't have answers for all problems, most of the times we just can't propose an architecture whitout digging deeper in the details, in the business requirements and having lots of discussions with peers and even business team.
But as developers and architects we can't be relying on specific products, we need to be able to understand architecture as a whole and what are the options we have to better propose a scalable architecture and build a solid system.

Here a few basic references about all this stuff.

Java BluePrints - Here some good stuff for JAva Enterprise Applications.
Java EE Design Patterns: Core J2EE patterns are here also
Patterns of Enterprise Application Architecture, from Martin Fowler.
Head First Design Patterns.

There are lots of other good books and articles. Please, feel free to comment here adding more references.
Also, what do you think would be the basic understanding developers should have nowadays? Any other specific skill?

Related Topics >>

Comments

Continuing on this slight tangent, I think it's unfortunate that people try to create a distinction between people who are "developers" and people who are "architects", and never the twain shall meet. Effective software engineers tend to work in the entire continuum. Developers who try to avoid thinking about architectural decisions because they think they're not an architect, and architects who never write a line of code, are people who artificially limit themselves. Agile development blurs these lines even more.

I agree with you when you say, "I like to understand if the person being interviewed has understanding of the applications he/she develops as a whole, I mean, not only understands business requirements but also understands the entire architecture of the application and, most important, why that specific architecture is in place for that application and its specific needs." However, I think you might need to reconsider how you get that information. Your questioning is rather vague, and as we all know the term "architecture" is heavily overloaded.

I think the questions you are asking pertain more to design than architecture. That's why Facade, DAO, VO, etc. are called design patterns. There are also higher level architectural patterns, and system architectures have their own patterns.

I don't think it's the job of a developer to make architectural decisions, or to know how many transactions per hour the application needs to support. That is the job of an architect. The developer should have an understanding of how to develop against core technologies, understand how those technologies fit into the architecture, and have have reasonable understanding of design patterns. All of that can usually be learned by asking them about projects that they have worked on in the past, what their involvement was on the project, and how their code fit in with the rest of the application.

First I like the overall gist of your questions. The job of developers is to create a product that aligns with it's intended business use. Questions of scale, resources, required technologies, etc. help show an interviewer how the developer thinks about his toolkit and how to apply it.<\p>

Secondly, I liked your insistence on the developer thinking about things on their own terms rather than in terms of the easy answer of "tool XYZ takes care of that so I don't worry about it". In my experience, the best developers understand what's going on all the way from the architecture level all the way down to the bytecode that runs on the JVM. They understand the universe of their choices and the consequences of one versus another.

I'm not in favor of your talking about design patterns until the task is defined, however. Doing so takes things out of the visual realm into the verbal realm. IOW, I'd be as skeptical about them saying "I'd build a solution using appropriate data patterns such as DAO and Facade" as I would by them saying "I'd build a solution using Hibernate and Spring". That just shows that they've read the right books, not that they understand how to apply what they read.

Otto (Kevin Kline): "Apes don't read Nietzsche!"
Wanda (Jamie Lee Curtis): "Yes they do, they just don't understand it."

:-)

When interviewing developers, I like to see how they think. One of the questions we ask is to help us build the software to run some everyday appliance, such as the gasoline pump at a filling station. Although most developers have used gasoline pumps all their adult lives and implicitly understand the requirements, few have thought about how they'd write such a system. It reveals a LOT about how they think about problems. On the one extreme, we find developers who are so caught up in the details that they can never gain enough context to make good decisions. And on the other extreme, we find developers who are so vague in their understanding of the system that they could never get started. Both are unsuitable for us. The ideal candidate is able to change their scope from wide beam to narrow beam and back many times as they rapidly iterate their design to create a viable solution. Then when they see enough to build it, they can get started.

I don't find good developers and architects to be so different. Sure, their tools and dominant scopes are different. But both need to approach software as inventors. Both need to be adept at the creative process.

With the truly wealthy, after the generation that actually made the wealth, the subsequent generations can be fairly useless people. Sadly, with languages like Java, and frameworks like Spring and Hibernate, the benefiting developers are no where near the caliber of the authoring developers.

What ever happened to standing on the shoulders of giants?

Unless you are saying about Value Objects from P of EAA or Eric Evans DDD , I don't want to interview at your company.

Mine is things simple
its Hibernate and Spring in the back and dwr in the front with extJS from widget
The best things about spring is support for all other apis that i use for project

The way I see, Java developers should be aware of Design Patterns, they should understand at least GoF ones. No matter how senior they are. If they are learning Object Orientation, they could care some time to learn the basics of design patterns.

I teach that in college, to make my students understand the importance to have and use reusable solutions.

Design patterns work like a language for developers. We can say DAO or DTO or "Viewer Helper" and we understand what we are saying. Developers may not be architects, but that's not an excuse for them to forget about learning design patterns.

but I am forced to agree that most part of time you ask something about design and architecture, developers give you back the name ot their preferred frameworks :( it sucks, but it takes time to educated a senior professional, and once they are senior they will be never available in the market.. :) Be prepared to hire junior ones and train them for months, perhaps years, before you have the correct answers ;)

offer a good salary (15% more than average), be aggressive in the job position announcement, call only the very experienced guy that send you the cv.. and most part of time you will be free ot this...

Well, wouldnt it depend on the position you are hiring for? If the position above you interview is not for an architect, then the developer has answered well. At that point, It only comes to the understanding that if that person can actually deliver what he/she speaks. That is the bottom line. On the other hand, If the position is for an architect, I think that is not the way to understand if he/she is actually capable of calculating the statics of the would be software architecture. An architect/designer does not determine the tools or material while designing. The right tools for the job can be determined after the architectural plan or design is complete not at the beginning.

@johnwallace - I want to interview at your company. It sounds like you have the right idea.

In my opinion a good Architect is the person who is a good developer as well or put it in other way round, only good developers need to be architect. I did worked with several architects who do not know more than the buzz words and put some boxes having these words in the so called design. When they are confronted about the ill designs they have during coding phase of the project, they enforce their influence on the developers to code as per the design only because they have designed so. In the end project fails to deliver the performance objectives. In my opinion, if one wants to hire good developers then he should be posed design and architectural questions.

And thinking about patterns, here is another great post about the subject, and there's a little dialog in there too.
Sometimes when we talk about patterns, that's what we get sometimes. You see people saying that "Singleton is the pattern I like most"!! :-)

URL: http://steve.yegge.googlepages.com/singleton-considered-stupid

Base Reference: http://blog.fragmental.com.br/2008/05/28/singletons/