Over the last couple of months I have frequently noticed myself referring to a personal experience. It was a rude awakening that ended up influencing my career considerably – upwards, thankfully!
After leading and completing several Documentum projects I was very confident about my ability to implement Documentum solutions. So when I interviewed for a position and failed the phone screen, it was a rude shock! Initially, I was in denial. I blamed the interviewer – he was a non-technical manager who was asking technical questions from a list and expected the exact answers that were given to him. Gradually, I accepted the fact that I didn’t know several fundamental concepts well, even though I could look them up any time I needed and would grasp them without a problem. I had learned well by doing but that had left much to be discovered. I could put in several more years to learn purely by experience or I could take a deep dive into the fundamentals and educate myself. I chose the latter and I am so glad I did.
Fast forward to today. One certification, an online community, and a book later I find myself on the other side of the phone. I often help my clients when they need to hire Documentum professionals. I notice the excitement when they see a resume reflecting 3-4 years of Documentum experience with aspects relevant to their needs. On the phone, it is a different story though. A self-described Documentum Architect cannot describe the solution architecture for projects on his resume – because there was another team that handled infrastructure. A self-described Documentum Administrator can explain little beyond creating users and adding them to groups – what else is there to Documentum administration? Oh yes, jobs. Which jobs do you know about? dmClean. What does it do? Cleans up docbase. Or deletes objects. Some get to “remove orphan objects”. What is an orphan object? Either a blank or cook something up. How can you find out where the content file for an object is stored? Content Server! It’s an attribute on the object. Some get so far as the content object but struggle to relate it to sysobject well. These are just some examples. Some candidates even get annoyed as to why they are being asked such fundamental questions (never mind that they don’t know the answers).
Most of these candidates probably do their tasks well and use the reference wisely as needed. But the interview experience does little to reassure the person who will be writing some not-so-lean checks for this position. The supply-demand inequation for Documentum professionals probably lets Documentum-experienced professionals persist in this mode because Documentum-skilled ones can’t be found within the timeframe, location, or other constraints.
I often share my experience with the candidates that I pre-screen hoping to help them take it in stride and maybe to inspire them to take a good next step. Some take it while others don’t get it. Oh, well.
Going beyond the interviews, a good grasp of fundamentals has helped me with better design decisions, including catching some would-have-been-mistakes before they happened. I strongly recommend taking the technical fundamentals exam (or just preparing for it if you don’t believe in certifications). Use the free resources such as dm_cram to help you in your pursuit.
Good luck with the step up your career curve!