IMHO I think this is a good list. One thing that I hate is interview questions where there really is only a single answer. The person your interviewing is probably stressed out to begin with and open ended questions help break the tension and open a person up to learn what they are really about. If you want a potential employee to be book smart and have memorized a series of definitions then fine. However, I look for people that are dynamic thinkers and are able to deliver solutions to complex problems. This list might not prove that ability but it is a good start that would probably lead to more discussion.

Behind the lower level questions there is another question I guess.

The thinking behind the final, finally and finalize one is simple - "Have you ever actually written any real code or is it purely academic?"

The toUpper question is about teasing out user requirements and about i18n a bit as well. It's a question you really need to talk through with the applicant.

Often I find that the hardest part of being and effective architect is not being "correct" with the technical issues, but rather coaxing developers to actually follow guidelines and best practices.

So I might ask about a hypothetical follow on to the "what's the hot trend in Enterprise apps these days" -- How would you convince a development team to use that approach in their next project?

We're hoping to judge people skills face to face rather than on paper, so the questions didn't focus on that too much. That said people are always on their best behaviour in an interview so it's always hard to tell.

I think you're right about the what-if scenarios. The toUpper question has been quite revealing so I intend to add another one in a more general vein.

Maybe I could convince you to put your CV forward ;-)

I just read through the questions and had no difficulty answering any of them. final, finally and finalize <<< very good question!

I hear programmers speak here about a number of relevant programing skills. From a business-centric perspective, architects should be corporate assets, not code designers. There are five dimensions to a software architect role: 1. technology 2. consulting 3. strategy 4. organizational politics 5. leadership Technology should consume perhaps less than 20% of an architect's day. Projects don't fail because of bad design or ugly code or improper/inefficient testing or even a wrong choice of technologies. There is no such thing as a perfect technology for a task at hand, only bad leaders and poor visionaries. The above mentioned are but consequences of poor organizational choices and a lack of focus. And patterns? They are but a convenient communication framework of the day. Should we know it as architects? Yes. At least we should know where the repositories are, and how to look through the repositories for a match with a task at hand. Frameworks change. For example, is MVC in Struts really M-V-C? Some people would say no. Unfortunatelly, those are few in between, for Struts rules. Oh no, or is it AJAX that rules? Or maybe SOA and REST and web services? No, no, it's OOP and generics, and AOP. One interesting thing happened with software engineering after WWW hit the mainstream. Some became gods in their own minds, and everyone became an architect. Vanity rules, and it will come to bite the software industry worse than the dot.com crash did. For Bankers are not a very patient bunch. Remember Occam's razor. "one should not increase, beyond what is necessary, the number of entities required to explain anything." That's wisdom. Now, you Mr./Mrs. Architect, who got bitten more than once by your own vanity and have learned some valuable life lessons, you go and explain this to a young hotshot who thinks he's got it all down after two books read and three projects completed and left for someone else to maintain. Someone should teach a class titled: "History of software art" and make it a mandatory read. Got to run...

Good Interview Questions !

Hello I'm Jem Smith webmaster and web developer in www.infoseeksoftwareystes.com. This architect view is a help full for everyone who associated with IT sector.

Good Thread

Thank. Me too wants to move furhter as a Technical Architect. This discussion helps me. I wants few more interview question for .Net Architect position (specialy scenario based). Could anyone help me?

It's a nice place to share my thoughts. It takes many of the methodological issues raised in traditional face to face or F2F interviews and transfers these online with some key differences. It principally focuses on the conduct of one-to-one exchanges as one-to-many exchanges are usually called online focus groups.I'm willing to stick around here and watch it grow. As i also want to learn how to grow mine. Tom Cv interview questions

In Architect Level Interview Questions, Joe Walker shares some of the interview questions that he uses to quiz architects. For me, the comment that sums up the essence of Joe's questions is as follows.