With great power comes great responsibility. Or so the saying goes. In the IT universe (as opposed to the Marvel universe) this means being the senior IT person in a business or organization. Finding a responsible person for such a position, however, can be challenging. If you are a CEO or a board member, what would your criteria be for selecting the right individual to fill your most senior IT role? That’s a good question and one that personally I don’t have a good answer for, so I reached out to a colleague who could give me some advice on this matter. Arnie Rowland is a Certified Technical Trainer, and has served as adjunct faculty at both universities and community colleges. He is a long-serving Microsoft SQL Server MVP, a Subject Matter Expert (SME) working on data platform training courses for over 20 years, and has served as a technical editor for several publishers. Clients include Fortune 500 and multinational companies, federal and state agencies, foreign governments, nationally recognized training facilities, and local enterprises — both public and private. During his career as an outspoken architect and application developer with very large databases, Arnie realized that most issues between developer and DBA come from incomplete communication and a misunderstanding of each other’s primary responsibilities. As a frequent trainer and mentor for developers and database administrators, he has nurtured a knack for helping to “bridge the gap.” Arnie is a rare mix of expert developer and gifted database administrator, bringing both sets of skills to better communicate with development teams to create a working solution. For more info about Arnie see his blog, his LinkedIn profile, or his Twitter account. We will learn a lot from Arnie about choosing the right person to fill a senior IT role. Let’s turn the floor over to Arnie.
Senior IT: They are so darn hard to find!
I mentor, teach, and consult with operations, infrastructure, security, and development teams. And one of the things that I am occasionally engaged to do for a client is to help interview candidates and find a candidate capable of stepping into senior FTE role. And finding such a candidate quite often proves to be a very difficult quest.
Let me be perfectly clear. Enterprise IT environments have become so complex that no one, and I’m very certain about that, is capable of being an “expert” in all of its capabilities. And the few that are true experts with various groupings of technologies and components are in high demand — secure and very well paid if an FTE, or perhaps even more so if they have chosen to be consultants.
Which brings me back to our subject. What do I look for in senior level candidates, and just as importantly, how can a candidate more readily assess if he or she really is senior level. From an interviewer’s perspective, I’ll give you a few tips on how to properly assess your own readiness to be called senior level when you are exploring the market for opportunities. And I’ll offer a few pointers about what you can do to make the leap to truly being a senior level resource.
Experience
What constitutes experience is always a big question. But what constitutes senior IT experience? That is a big “it depends” kind of question. But one thing is certain for the clients I’ve interviewed for in the past few years — experience means doing a lot of different things to solve complex problems and ensure that changing business requirements are being met. It does not mean doing a lot of the same tasks, week after week. If your biggest challenge every week is looking through your monitoring reports to verify that everything is working as expected, I don’t care how many years you’ve been doing that, and how many hundreds, or thousands, of servers you monitor, you’re really not the senior level resource my clients are seeking. They are looking for folks that have set up unusual, and even contra-indicated combinations of servers and services — and failed. But most importantly, they expect the senior IT person to be ready to try again. They expect a senior level resource to bring in experience from trial by fire learning. At enterprise scale, things rarely go as designed, or expected, or even hoped. But we pick up the pieces and take another stab at it, cherishing our failures as much as our successes. If you are interviewing for a senior position, and you can’t readily talk about some really major failures, and what you learned as a result, then you have not been in a very challenging environment, and you still have a way to go to really earn being called senior.
A hallmark of the “midlevel” FTE is doing the “same old, same old,” day after day, week after week, doing safe work, in a safe environment, rarely expected to work outside of a typical workday eight-hour shift. (I anticipate that there will be healthy disagreement with my characterization of the requirements of being senior. But with many of my clients, in rapidly changing competitive business environments, senior means being ready to “saddle up” and just get the job done.)
Maybe you knew that, and now you want to make the leap and try on the senior IT mantle. What can you do in order to be taken seriously and be given an opportunity to even try and prove yourself? Sure, your previous positions were not really challenging, but you think you are ready. So you’re considering submitting yourself as a candidate for a senior IT position. You are going to go for the interview. What should you expect? What can you do to prepare yourself? How can you stand out and be noticed — and considered, by the interviewers?
Product knowledge
Be prepared to respond to questions about the current versions of key software in your area. Sure, your current employer is still using last year’s version 3.x, maybe even 2.x, (or heaven forbid, 1.x), but if you can’t answer questions about current capabilities and features, you will be quickly relegated to the “also-ran” list. It is an acceptable response to indicate that you are not currently working with “4.x,” but that you know about it and think that it could solve certain problems. Visit the open source or vendor’s website, read the product literature, download the evaluation version, and set up a server on your home or lab computer. Start exploring and learning about the other stuff. Most likely there are a significant number of online labs and tutorials that are free for you to use and learn from. But gosh, don’t go into an interview without current product knowledge. I’ve recently interviewed candidates had no clue about mainline features that had been in the product for a decade. One “experienced” network admin had never set up an SSL certificate; another couldn’t even offer a basic explanation about how Kerberos works. A few alleged senior Dev-DBA candidates didn’t even know how data compression works — and the advantages and disadvantages. And the list is embarrassingly long.
Learning and training
Be prepared to disclose how you learn about software changes and new features. Do you have a test environment? Do you read significant blogs? If so, whose blog? Be prepared to talk about those you rely upon for product information. If you are not regularly reading blog postings by prominent and key practitioners, then you are truly losing out to a candidate that can tell me what they read recently that caused a pause, and a learning opportunity. I don’t really care which writers you may read, I just want to know that you are connected in with some of the best minds in the business. Do you attend your local user group, if available? Do you even know about it? If you don’t, I will be concerned that you are working in a vacuum, failing to take advantage of opportunities for knowledge transfer and networking. What was the last technology conference you attended? Was it a “free” event that you gave up some free time to attend? Was it an event that was important to you and you paid some of or most of your expenses? I want to know that — it communicates that you invest in your career. If your training, conferences, networking only happens on the organizations time/money, then I have real concerns that you are most likely not adequately keeping up with advances in technology.
Certifications
From my perspective as an interviewer, I value certifications as a testament to (1) setting a goal, (2) doing the prep work, (3) investing time and resources [$], and (4) obtaining the goal. Bottom line for me is that it becomes a gauge of a candidate’s ability to commit, study, retain, and use new information. Granted, it may be less than ideal information, sometimes even contrary to “real world” demands.
Candidates that only learn on the clock, and when being paid, are often quickly dismissed.
A certification does not give much assurance that information has actually been retained. But it does give me a way to evaluate a candidate’s drive. And the candidate’s willingness to invest personal time and money to further their career. Candidates that only learn on the clock, and when being paid, are often quickly dismissed. This technology moves too fast and changes too frequently to not have a commitment to invest personal time/effort/resources. You can’t tread water, you either fade away or work hard to move ahead. There is no easy path. It takes sincere commitment.
Résumé
Presenting a detailed list of every technology that you think I might be interested in is going to be a problem. First, if you allege that you have senior level expertise in eight or 10 server technologies, you are probably not being very honest. Yes, you may have passing awareness, or perhaps even dabbled in a lot of various server technologies, but what is your true expertise? Be prepared to defend your assertion that you have senior level knowledge and experience if you have it listed on your résumé. And if you list technologies unrelated to Server X, I wonder why you think I care, this interview is for a Server Y position. I have an expectation that you know a mix of ancillary servers and tools.
If you have a series of short, three to six month engagements, be prepared to talk about it. Perhaps even mention why on your résumé. This organization is not going to invest six months getting you up to speed in their organization just to have you walk out. If there appears to be a pattern of short work experiences, expect to be grilled about it and have convincing responses ready. Unless I see something special about you during the interview, an equally qualified candidate with longer tenures will be in front of you on the short list.
And finally, during the interview, if you are asked why you are leaving your current position, don’t tell me that you are bored, that you feel unappreciated, or that your boss is a jerk. That may be true for you, but guess what, I really don’t give a twit. I want to know why you think that this opportunity will be a good match for you — and for this organization.
Do your homework — be prepared to tell me a few things about this organization. What is its purpose, business, market — use the internet to research it out, for gosh sake. An interview is a two-sided conversation; you should be prepared to ask questions -about the company, the specific job/tasks/duties under consideration. A candidate who is seeking to escape a bad situation is far less attractive than a candidate that is seeking to join a new situation that may provide exciting and interesting challenges.
What it is really about
Being a senior IT professional means so much more than just having survived a number of years at a job — it is not about age, longevity, or being the first in the door. Or worse, because it just happens to be the job title. Being a senior IT professional is about drive, experience, knowledge, learning, and mastery. You don’t get to call yourself senior — you have to earn it.
Photo credit: Shutterstock
