Skip to main content
Career

VCDX6-DCV Defence Experience

In 2013 I was a systems engineer, I worked mostly on automation scripting for consistently delivering virtualized infrastructure on VMware. A job I’d enjoyed but was ready to move my career forwards, my at the time colleague Richard Dowling and I started looked into pursuing advanced VMware certification. In early 2014 we attended a VCDX workshop hosted by John Arrasjid at VMware EMEA HQ in Frimley. Also in the workshop was Paul McSharry who John knew and who had recently had published VCAP5-DCD Official Cert Guide. I ordered the book that evening and this began my journey from engineer to architect.

During the four and a half years since I’ve continued with our goal of pursuing advanced VMware certification and passed VCAP5-DCA, VCAP5-DCD, VCAP5-DCV Design and VCIX6-NV. I’d also began contributing much more to architecture design documentation but still had engineering duties. In 2016 I moved jobs to take on a role where I was a dedicated architect and co-authored a complex NSX for vSphere design with Kyle McMaster. I had every intention of submitting this for VCDX6-NV but on delivery of the project, I moved to work on Amazon Web Services and could not dedicate the time the VCDX process needed.

I changed job again to take another architect role, which aligned to business transformation program. Moving away from specific technology and closer to using various technologies as business enablers. As part of this I created a vSphere design for un-differentiated configuration, like a VVD but without vRA, smaller starting footprint and tailed for our specific delivery org.

I speculative submitted this design exactly as was written for production with no tailoring for VCDX, and expected that it would be rejected but I would get good feedback on what needed to improve for a actual submission. From point of speculative submission I began writing a VCDX tailed document, after four weeks of working on new document set I got a surprise email reading, “We are happy to inform you that you achieved a high enough score to allow you to proceed to the defence stage of the process.”

  • Mistake One - Never assume failure, and begin work not required. As with Lean Architecture design only what is needed, enough but never more.

Many days later another surprise followed when I received an email inviting me to defend at VMware HQ Palo Alto. I’d previously had aspirations to defend at VMworld Las Vegas but never VMware HQ.

Time during these events was in short supply, I was offered defence slots very close to each other but my preferred earliest slot was given away. So I ended up with just over a month from notification to defence.

  • Mistake Two - Ensure you have good notice of defence slot, so give good availability to all dates. Having a month with normal job and other real-life commitments is not enough.

Preparation wise I worked as hard as I could reading through the design document, making revision flashcards and practice sessions with colleagues. I had found it difficult to practice with VCDX holders, as they have all become very quiet in this area. I did manage to practice with a few who gave good support on a few scenarios, but it didn’t match with my actual defence experience. I even slacked VCDX holders direct who I’d never met asking for help, all very embarrassing and sometimes rude, but when panicked pride means less. Preparation for the troubleshooting and design scenarios was really hard as I had no knowledge of what to expect and couldn’t find anyone to help guide me.

  • Mistake Three - Try and find VCDX holders to help you prepare and mock.

I flew from Manchester to San Jose, the flights were booked for a fairly short trip. I flew out on Sunday and landed late Sunday afternoon PST. I drove to Santa Clara and did some preparation before going to bed, albeit far too late in the evening as mind was racing through things.

Monday morning I woke around 3am with jet lag and continued preparing, but fear and doubt were quite high even then. Around 8am nerves got worse, so I headed to fitness center for a long run. After which there was no escape the defence was coming and I had to make peace with myself. My defence was at 1pm so I had lunch. I couldn’t even eat a sandwich and ended up just having a bowl of soup and drove over to VMware HQ Palo Alto.

I cannot express the level of anxiety I felt, I got to VMware reception and felt like I was going to be sick. I sat in the lobby with headphones listening to music trying to compose myself. When I went in I was almost an absolute wreck, which was wholly unhelpful during the design defence. With the nervousness came a lot of perspiration, which was wholly unhelpful during design scenarios when a whiteboard was involved.

  • Mistake Four - Arrive well rested with time to acclimatize and settle.

The defence panelists were great, very supportive and friendly. The design defence was first, my nervousness and lack of practice with a whiteboard was clear.

  • Mistake Five - When nervousness kicks in being well practiced with a whiteboard really helps.

We moved onto the design scenario, we had a good discussion and while nervousness subsided a little, the lack of practice with whiteboard was still evident.

  • Mistake Six - Make sure you really understand what the defence scenario will look like so you’re not surprised, and practice whiteboarding.

We then moved onto the troubleshooting scenario. I’m a sysadmin trained operations guy, but this wasn’t my strongest part of the defence. To a large extent, the troubleshooting section relies on information being presented to you, which requires asking questions to reveal. I made a decision tree and found one question which was not answered exactly how I was expecting, and I got confused and somewhat sidetracked. In hindsight, I should have noted it and continued to root cause other theories.

  • Mistake Seven - When asking questions, don’t dwell on a single point. If it doesn’t fit just note this and carry on, sometimes question answers can be off during troubleshooting.

After the defence concluded I felt okay about my performance, in reality I was beaten by nerves and under-prepared. One takeaway for all, is that you don’t know when you’re in the room. I got a lot of good supportive feedback from the panel afterward.

  • Mistake Eight - When you don’t understand something in the feedback session, ask for clarification.

I drove back from Palo Alto to San Jose and went to a mall to find somewhere to sit and eat, and gather my thoughts. With the stress of the day passed I began to have an appetite again and eventually ate a meal at a restaurant. After eating I walked around trying to find something to occupy my mind. Whilst doing this got a call from the VCDX program director with the news I had not passed. The call was great as it came with supportive feedback and gave some insight into what should be improved.

Looking back at the defence, it was a great experience, one which has helped improve my knowledge. My design document had several areas marked as out of scope. This is where my design document would get improvements if I was to re-submit. I’m already a much better architect for having gone through the VCDX process. I’ll now reset and get more experience before attempting to defend again. Many congratulations to all who got their numbers in the Palo Alto panel, and special thank you to panelists and Ram

tl;dr - Eight lessons learned:

  1. Never assume failure
  2. Get maximum notice for defence slot
  3. Find VCDX holders who can help you prepare
  4. Allow time to acclimatize
  5. Practice white boarding for nerves
  6. Know exactly what to expect from design scenario
  7. If troubleshooting questions don’t give expected answer, note and move on
  8. Ask for clarification during feedback