I was reading Josh Odger’s post on the VCDX Defense. Josh’s article can be summarised with the following part:
As a result, the candidate should be an expert in the design being presented and answering questions from the panel about the design should not be intimidating.
Having gone through the process myself, knowing many of the VCDX’s and having been on countless of panels I completely disagree with Josh. Sure, you do need to know your design inside/out… but, it is not about “who’s having an advantage”, the panel member is not there to fail or pass the candidate… they are there to assess your skills as an architect!
If you look at the defense day there are three parts:
- Defend your design
- Design scenario
- Troubleshooting scenario
For the design and troubleshooting scenario you get a random exercise, so you have no prior knowledge of what will be asked. When it comes to defending your design of course you will know your design (hopefully) better then anyone else. However, the questions you get will not necessarily be about the specifics or details of your design. The VCDX panel is there to assess your skills as an architect and not your “fact cramming skills”. A good panel will ask a lot of hypothetical questions like:
- Your design uses NFS based storage, how would FC connected storage have changed your design?
- Your design is based on capacity requirements for 80 virtual machine, what would you have done differently when the requirement would be 8000 virtual machines?
- Your design …
So when you do mock exams, prepare for these types of hypothetical questions. That is when you really start to understand the impact decisions can have, and when during your defense you get one of these questions and you do not know the answer make sure you guide the panel through your thought process. That is what differentiates someone who can learn facts (VCP exam) and someone who can digest them, understand them and apply them in different scenarios (VCDX exam).
As I stated, it may sound like that you knowing your design inside out means having a big advantage over the panel members but it probably isn’t… that is not what they are testing you on! Your ability to assess and adapt are put through the wringer, your skills as an architect are tested thoroughly and that is where you will need to do well.
Martin Banda says
Would “Knowing how you got to your design inside out” be the advantage to go for?
Understanding the decision process and choice elimination process would help the candidate understand the motivation behind the choice\decision they have taken thereby implying they understand why not the other solutions.
Would this be correct?
The bigger question for me then would be “how far down the rabbit hole do you go” in understanding the impact of what solution over another in your design?
Duncan Epping says
Sure… I don’t disagree with the fact that you need to know your design inside out. I also agree with you that you need to know (understand is a better word) how you got there is crucial. But I also realize that in many scenarios people follow “best practices” blindly, they have constraints which leads them to certain architectural decisions… You as a candidate, need to be able to articulate what would change if those constraints for instance were lifted. It is not enough to explain the constraint by itself, make sure you can take it to that next level.
As someone who is studying for varies tests (CCNA at the moment), and trying to get into the IT industry this was very eye opening, and want to thank you for your input. I am happy to see not all the tests are about fact checking, and memorizing text book answers.
Erwin van Londen says
I agree Duncan. I’ve seen a magnitude of people being experts in memorising fact sheets and textbooks and obtaining a fair share of certifications. Taking them into a datacentre and asking to start managing it is a whole new ballgame. Same thing obviously goes for the design and implementation phases. Being able to translate business requirements into a financially feasible architecture is a totally different method of IT comprehension.