|
The application which I am working on currently is a bit huge. It cannot be explained in 15 minutes or so. Last time I ended up drawing some class diagrams and how they are linked, but I could see that the interviewer was not happy with the answer. What are the main things that should be highlighted when answering this question? For example, how session is managed, how persistence is achieved are few things. What are other things, which should not be missed? |
|||||
|
|
Personally I think you're going to deep (for an interview) if you start drawing class diagrams, unless they ask for it. Last time I had this question I ended up drawing the different layers (3 tier app), explained how the assemblies were mapped (cause this was something 'odd' for the project in my opinion), in which direction the layers had dependencies and the direction of dataflow. You can go deeper in specific components if you feel you have to. But I never went much deeper than "we used Workflow Foundation for this part of the business logic, because of that reason". This gave me the chance to point out we used a certain technology used, without wasting time on trivial things like simple POCO objects. More important is showing that you understand the architecture and why it's done like that. Even better is to point out points of improvement (if possible) and explain why so. If on the other hand you think the design is 'perfect', you can point out a particular part of the design that doesn't seem logic for an outstander and explain why it fits for this project. |
|||
|
|
If you are unable to provide a high level overview of the architecture of your project, or explain the project in 5 minutes (let alone 15) to somebody else, then most likely the reason is that you are too close to the coalface. You need to get some distance, so you can see your own work as others would see it. Just like a painter, step away and look at the whole thing. Then you will see what the important things are in a 5 minute overview. |
|||
|
|
|
Think of answering this question like how you would explain it to a client. Your client doesn't care about the nuts and bolts they just want to know the overall structure. In the same sense, the interviewer just wants the overview to see what time of environment you are coming from and how it correlates to their own. They don't want you to drone on about your project and you shouldn't be showing class diagrams in the interview. So give them the 10,000 mile overview of the architecture. If they want more detail on something, they will ask. Then start going deeper. |
|||
|
|
|
All of these answers are superb, but I have noticed that a very high level component diagram, a listing of the technology stack, (Eg. Java, JSF, Primefaces, etc...) and a confident smile and open attitude are the best answer to this question. If you aren't smiling or even a bit excited when explaining the architecture of your current project then the interviewer might see you as detached and uninterested in your hard work. I act excited and talk about it like I think its the "coolest" thing in the world and that gets the interviewer smiling and comfortable, and he starts to ask more detailed questions. |
|||
|
|
|
Start from the highest level you can and work down. I would start with a basic functional block diagram on the whiteboard. Remember that the interviewer will (hopefully) be technically skilled, but knows nothing about your project. Whatever the project you should be able to draw an outline of the basic operation in a few (<10) blocks. You can then expand out on the blocks you know well and add more detail. For instance you mention persistence - this could be a single block in the first diagram, but may cover an entire whiteboard if you need to drill right down into the details. If they are asking about the architecture they will be expecting an overview to see if you actually know how it fits together, or whether you just worked on one small chunk of the project. Make sure you provide this before you start drilling down on one small area. |
|||
|
|
