I’ve just finished the second part of the Salesforce Technical Architect Certification, the live Review Board, and I must say it’s a bit draining. Imagine something like the picture on the left with the questions coming fast and hard. SSO for desktop app!? Oauth! *Hewah!* Improve queries in large data volumes!? Indexing! *Kapow!* Cloud based platform for Ruby!? *Herokuuuu!!!!* Fortunately, my session was held at Salesforce HQ in San Francisco and not Han’s Island, so we were limited to verbal sparring only.
If you’t don’t already know the format, here’s the deal. You have to prepare a presentation – a Case Study, if you will – on a project that you’ve done in the past. This has to be sent to the Certification team at least one week prior to your scheduled appearance before the board. (You’ll get an email with all the details.) On the day of the review, upon arrival you’ll get handed a 4-page written hypothetical case that outlines a company and their requirements for a Salesforce solution. You have 75 minutes to read that and put together your solution. You then present that solution to a board of technical architects for up to 30 minutes followed by 30 minutes of questions. If you take less than 30 minutes to present, that time gets added to the questions portion of the hour. Following a 15 minute break, you’ll get another thirty minutes to present your Case Study followed by 45 minutes of Q&A. Same rule applies. If you use less time to present, you get more time on the hot seat. Finally, the whole thing doesn’t end until you pin the host. I’m not entirely sure about that last part, since by that point I was a bit punchy. You may want to add some extra pushups to your preparation regimin just in case.
In preparation for the board, I had two practice runs with hypothetical cases over the phone and one with my client case in front of a live audience. Based on my experience, my prep, and conversations with people who have completed the certification, here are a few bits of advice that you might find helpful.
Try scheduling your multiple choice exam board just a few weeks prior to the review board. I wish I had signed up for the review board that was held in March, only three weeks after I passed the multiple choice exam (see my previous post). Everything was still fresh in my mind, then. Instead, I opted for the May board thinking I didn’t have enough time to prep my project case. With all the time that passed I ended up having to study up on some key areas all over again. In retrospect, I should have done the case study in parallel with studying for the multiple choice exam and then three weeks would have been sufficient time to do some mock runs.
The mock cases I’ve seen have ranged from 3-5 pages in length and have a lot of detail about the company, requirements, desired process flows, security, and more. There is far more detail than I think is reasonable to read and respond to in the time you are given. This is where I had my epiphany – you are not meant to. In fact, expect that a lot of the Q&A portion will be focused on those areas you weren’t able to cover because that is by design. The board members need to have something to ask you about. It would be really awkward if your 30 minutes of presenting was met with 30 minutes of crickets chirping. So, instead of trying to provide a complete highly detailed solution for each requirement, concentrate your efforts on puling out the major requirements and putting a high level solution overview together. You can’t prepare a powerpoint in advance for this (which had been my original plan). They give you a blank powerpoint template that you can use with a few generic tables and diagrams in the appendix. They also handed me a Windows laptop to use, which given my four year mac conversion, presented other challenges. In my first mock run, which was via GoToMeeting, I spent far too much time trying to get my powerpoint slides together and couldn’t get everything down. Don’t make that mistake. It’s much quicker to use the provided paper to mock up your landscape diagram and ERD’s. For the review board case, I put together only ten slides some of which only had a title and most of which had only 3-4 bullets. My strategy was to use the powerpoint to set my agenda and keep me on track. On the blank slides, I knew to talk to my solution while transfering my drawings from paper to the whiteboard. I put a minimum of text on the other slides knowing that I could take as much or as little time as needed to expand on the bullets. There will be a timer counting down and visible to you and the board members. Keeping my total slide count to ten helped me know exactly where I should be by the 10 minute mark, 20 minute mark, etc.
I found the Q&A much easier, but I know that not everyone does. Just remember to take your time. When you get a question, process what you’re being asked and why, mull over a solution in your head, and speak once you’ve got a thought out answer. If you rush ahead to answer you’re just increasing the number of questions you’ll get. During some answers, I went back to the whiteboard and expanded on previous drawings or diagrammed something completely new. Take the time to answer the question as completely as necessary, but be sure not to ramble on. Once I saw heads nod, I wrapped it up.
The case presentation was much easier because it’s prepared and practiced in advance. My powerpoint was about 20 slides long and was structured as follows;
- Overview slides; a client description and a project description
- Systems Landscape diagrams; one before and one after
- Solution Highlights – pulled three discreet solutions from the overall project and gave two slides to each; one with bullets and one with an supporting diagram
- Project Reflections – this can include technical challenges or project management issues, lessons learned and maybe decisions that would be made differently in retrospect
The project I selected spanned the last year and a half of my life (and continues to do so). So, given that scope, it was important to pull out only a few ‘highlights’ rather than trying to cover everything the project entailed. I didn’t have anything related to testing and change management in my deck and got a lot of questions on that afterwards. So, it may be helpful to include that somewhere in the mix.
The second Q&A is longer by 15 minutes and it feels even longer since you’ve been talking for an hour and a half by this point. (Remember to bring a water bottle.) It was interesting that not all of the questions focused on the technical aspects of the project. A good number, as I said, were focused on testing and change management. Quite a few others were on coordinating the development team and overall project management.
In all, I think the review board part of the certification does a good job in eliciting those qualities required by a Technical Architect. Being able to present to an audience and field questions with confidence definitely separates a developer from an architect. Both can have the technical expertise, but the role of a TA in the project is more than that. Its one thing to be able to envision a solution. It’s quite another to be able to get people to buy into it. Make sure you’re comfortable on both ends of that spectrum as you prepare.
Hopefully, you find this useful. Good luck!
Update June 26, 2012 – Got the official notice that I passed the certification today. Thanks to everyone that helped make that possible.