A few days ago I had the pleasure (?) to observe the board certification of several candidates pre-qualified for the title of “Microsoft Certified Architect“. Based on the feedback of a highly-respected colleague – who had failed his first exam – I had assumed I’d be somewhat prepared on what to expect. That was a pretty stupid assumption for the certification of technology architecture skills with a specific focus on database architecture.

The first candidate I was to observe didn’t show up, and Cindy couldn’t contact him. Interesting: Candidates pay a fortune for the certification, this one flew all the way from Australia to Redmond – and then doesn’t appear? Schedule screwed up for the rest of the day, and additional stress for the next apprentice because he was rescheduled.

According to the description it seems to be easy to become MCA: You pass the written test, you deliver the desired results in the qualification lab, and then you pass the one-hour-screening of the review board. The description of the review board is absolutely accurate. The only problem: You have to take it literally, word by word.

Due to the rescheduled agenda I was a little late for the next group of candidates and met one of them in the lobby. He asked me a simple, straight-forward question: What are the most common mistakes made by candidates? Since this was my first review, I wasn’t able to answer his question then.

But I think I could now, and I’m prepared to share some of my observations concerning some major mistakes:

• If you’ve not implemented the stuff, don’t even think about applying. There is no way you could pass the board without in-depth, practical, hands-on experience. Knowledge just by the book doesn’t even bring you close to what the board wants to see.
• If you’re claiming deep knowledge in a specific subject area, being a SME, make sure that you really have the depth. Validate it with other SMEs. To believe having depth, or being praised by colleagues for knowing a little bit more, is just not enough. These reviewers are going to challenge you on your acclaimed level 400+ knowledge, and the way to do that is to have a level 600 person (the dev lead) reviewing you. The reviewers are not going to challenge you on any topic, only on the topics you claim as your strengths, such as security, or PTO. Two examples that astonished even me, completely out of context:
• Q: “Is there a difference between the tokens returned when using authentification versus impersonation?” A: “Oh, well, off course there is a difference in the two methods, because, ah, …..” And so on, for another two minutes. A waste of time. If you don’t know the answer, just say it. Don’t waste your time with stupid explanations.
• Q: “In case one of your queries sometimes runs perfectly well, and sometimes nearly blocks the system, would AWE be helpful?” A: “On a 32-bit or on a 64-Bit system?” Again: If you don’t know the answer, skip it. If necessary three times. Accept that this might not be your core strength: That would give the board an opportunity to zoom-in their laser on on of your other areas of expertise. That can’t happen if you waste your precious time with stupidities.

During the role play, I noticed that the common weaknesses, shared by all candidates who failed, were Strategy and Tactical/Process. Some assistance:

• Provide alternatives, choice to your clients. Weigh the alternatives, demonstrate the business benefits of the different solutions to the clients.
• Validate.
• Don’t explain methodology, apply it instead.
• Listen: If the customer tells you three times, that his tapes are corrupt and can’t be read, don’t try to find alternatives for reading the tapes.
• Deliver the complete solution, demonstrate application of the methodology (whatever it may be), outline the roadmap / project plan (break-fix vs. long-term resolution), address technology and operations. Again, out of context, an example, related to a DR scenario:
• Three out of four candidates (especially when they are working for Microsoft Consulting Services) jump right into a specific technical solution for the DR problem, based-upon database mirroring. Most of them ignored the alternatives (log shipping), and all of them completely ignored the operational issues originally causing the problem. And most of them not only forget to validate their proposal, but also to explain the advantages for the customer. (Disadvantages cannot be compared if you don’t mention alternatives.)
• The fourth candidate correctly addresses the operational issues, but then forget to outline the long-term HA solution, to be based-upon DB mirroring, and wastes five minutes to explain how log shipping works technically.

That shouldn’t be too difficult, it’s basics. Unfortunately you have to add the time constraints, your own angst to fail, a certain aggressiveness of some reviewers – failed. Only 20% pass, which is good: The MCA is a quality certification, and only the best will get through.

I’m not sure if the certification of architectural skills for a specific technology makes sense, but that should be a different discussion.

As a SQL Ranger, the Microsoft-internal brand for the guys who pass, you’re supposed to solve problems that cannot be solved by anybody else. There’s no help, no back-up, nobody to ask. If you can’t solve it, only the developers can create a work-around, or fix.

For me that was a terrific learning experience, and an opportunity to get to know some really cool guys. Pleasure? Yes – but also exhausted, definitely more than the candidates.