Technical Interviews

[Ray Marsh]

My boss has requested me to interview a Technical Architect for our department.
I've never given a technical interview before, any suggestions?

[paul wheaton]

Ask him to name some design patterns (and don't settle for plaid, polka dot and stripes). Ask him to draw some UML diagrams. I usually ask for an example of a class implementing an interface. Have him describe a singleton, a factory and a strategy pattern.
Here is one of my favorite questions: In OO, a switch statement can often be replaced with what? The answer is "polymorphism".

[Edward Man]

If the job is for an Architect for a web application, ask questions like:
1. How many Web Application Architecure Patterns are there? How does he/she decide which pattern is suitable for the kind of web applications?
2. Can he/she draw UML diagram for those Web Applications that have HTML/JSP/ASP pages/Java Beans?
3. Does he need special symbols for the UML diagrams for web applications? What are they?
4. How does he make decision to split objects/functionality into client and server?
5. Can he translate a use case diagram into analysis using UML and collaboration diagrams? Ask him to draw the diagrams using an existing use case diagram from your application.
If you can get someone who answers the above questions fully, offer him/her a job on spot.

[paul wheaton]

Edward has tough requirements for an architect!
But I have to admit that my questions are pretty lightweight. If your candidate cannot answer all of my questions, you shouldn't hire him.

[Ray Marsh]

That's provided I have the slightest clue he answered correctly!
It's for a legacy system, under-going major re-working, not a web app and not OO, strictly proceedural. The request to interview this guy, came as a surprise. I need to find out what my boss wants me to accomplish.
Thanks for your responses. I can use the information. BTW, Does UML apply to proceedural languages?

[Edward Man]

If it is for a legacy procedural system (COBOL with VSAM/DB2?), I suggest the following questions:
1. What SDLC methodology does he/she use (most of them use Strutured Analysis in procedural system)?
2. Does he/she know how to model a RDBMS using Entity Relationship diagrams and other methodologies?
3. Give a part of the new user requirements and ask the person to draw the Context Diagram and part of the Dataflow Diagrams.
4. Also try to model the ER diagram that involves the DFD diagram he/she draws.
5. Ask the person to explain how the ER diagram can support the DFD diagram and vice versa. You should spot any discrepancies in the explanation.
6. Ask the person to outline the functional requirements based on the user requirements.
7. What other non-functional requirements are necessary for the new system - user-friendliness, performance, batch job requirements, OLTP requirements, interface to other systems. Ask the person to elaborate based on the new system.
If the person is a hands-on architect, he/she should be able to answer all the above questions.
The following questions may also be useful, depending on your company's requirements.
8. Does he/she know how to manage change and configuration management? What tools were used before?
9. What databases were used (if the legacy system uses a RDBMS)? It yours is IMS (or other hierarchical database), ask whether he/she knows how to model a hierachical database.
[This message has been edited by Edward Man (edited June 05, 2000).]
[This message has been edited by Edward Man (edited June 05, 2000).]

[Ray Marsh]

Thanks for your lengthy response, Edward.
Although I need a glossary to understand most of it!
I only have a 1/2 hour with the guy, so I'll have to make it fairly concise. I suspect this is a training exercise for me, as well as an interview.

[Edward Man]

Ray,
I try to explain a bit of what I posted. I am sure you know at least some of them. Anyway, it may be useful for others as well.
In the 70s/80s, methodologists proposed Structured Analysis to tackle the analysis and design requirements for procedural systems developed at that time. Structured Analysis mainly use Data Flow Diagams (DFD) to document the process flow. Systems were considered as data flowing from one process to another. That's why they use DFD for analysis and design.
At the same time people use Entity Relationship Diagrams (ER Diagrams) to model tables and their relationships (primary key, foreign keys, etc). They then use normalisation to split/combine tables into Third Normal Forms (an optimal form for relational tables). A lot of designers are still using it. (Erwin is the best known tool that supports drawing/re-engineering ER Diagrams). Even you use flat files or index sequential files, ER Diagrams are still useful to capture the semantics of the system.
As both DFD and ER Diagrams have data in it, you should be able to find the same piece of data in both kind of diagrams. If you find Shipping Charge in the ER Diagram but not in any of the DFD diagrams, then something is missing in the DFD, or one of the process in DFD that calculates the Shipping Charge is omitted. You can tell whether the architect is up to the task or not.
An architect should always consider non-functional requirements as well. If it is so hard to use and so slooooow in running, who's going to use it?
SDLC is System Development Life Cycle that includes everything from gathering user requirements, analysis, design, testing, implementation, maintenance, training.
I hope you can pick some questions to ask in the short interview.
Edward