Doing Business

Thoughts From a Hiring Manager on the MCDBA

AjarnMark — Fri, 01 Feb 2008 07:38:53 GMT

Now that I have had the "pleasure" of filtering through numerous resumes looking to hire someone, my thoughts on certifications has evolved a little... Or it's probably more accurate to say that they have been solidified.

Acrimony

Anyone who is active in the community is well aware that the topic of whether to pursue your MCDBA or other certification is hotly debated. Are things a little too quiet in the office or on the discussion boards? Just throw out the "innocent" question of whether it is worth pursuing certification and things are certain to get lively for a while. It ranks right up there with abortion, evolution, and Sean Connery vs. Roger Moore as topics guaranteed to get the sparks flying.

As for the MCDBA, the argument often breaks down into the following points:

"I know plenty of people who have their certification but I wouldn't trust them to organize my pencil collection."
"I know plenty of people who do not have certifications but are sheer geniuses in SQL Server."
"All the MCDBA proves is that you know how to give the official Microsoft-approved answer."

My tendency in the past has been to come down on the side of "certification doesn't guarantee you know squat about databases in real life, but it probably doesn't hurt to have it on your resume when you're looking for a job." And guess what? I was right.

Hiring in the Real World

Here's how the screening process goes at my company. I tell the HR person (recruiter) that I am looking to hire someone and I send her the advertisement that I wrote which contains all the acronyms and buzzwords we are looking for. (Note that MCDBA is never on this list.) The recruiter then makes sure I didn't break any laws, puts our corporate intro or conclusion on it and gets the word out. This may mean working with a Staff Augmentation firm or posting it wherever her experience indicates we tend to get the best responses. She collects the responses and filters out candidates based on non-technical issues. For example, if we get a resume from someone who is international and we are not planning on sponsoring, then she weeds those out. Or when we get resumes from people that do not include any of the acronyms I specified, out they go too. There are a handful of reasons that a candidate is immediately eliminated, and she does a great job of that. She also does a good job of running interference with the StaffAug companies that want to send us every person they have riding the bench, and asks me for clarification of requirements when necessary.

But what our corporate recruiter absolutely does NOT do is make judgments as to someone's technical acumen. That is left to me. And here is where we get back to the point of this post. I know plenty of people who have their certification but I wouldn't trust them to organize my pencil collection. And I know plenty of people who do not have certifications but are sheer geniuses in SQL Server. BUT, when I do not personally know the person whose resume I am reading, and I am narrowing my list down for the first round of calls, and I have two candidates who appear to be similarly qualified on paper, if one of them has the MCDBA and the other doesn't, then the certificate gets called before the non-cert.

Why?

But Mark! You just said that certifications don't guarantee that the person knows anything! Yes, I did say that, and I meant it. But once I have sifted out the unqualified and am down to the situation where, I am looking at resumes for similarly qualified people, I do give one bonus point to the person with the certificate. Now hear me, I did not say that I would call every person who has their MCDBA, regardless of their experience. I'm talking about candidates that are nearly equal in experience. The certificate earns a bonus point because I know this much... you are serious enough to spend the time and money to go through the testing process, and you not only persevered, but you prevailed. (How's that for a little alliteration?) And for all that hard work, your reward is that you get called before someone else who otherwise would be tied.

So, should you pursue the MCDBA or not? Well, that's up to you to decide but here are a few key considerations:

If you are job-hunting, it may help you get the interview, but probably won't get you the job (except for #2 or #4 below).
Some companies are required to have a certain number of certified people on staff, and this could help you.
Some companies pay more to people with certifications (we don't, but some do).
While studying for the exams, you just might learn something new that lets you solve somebody's problem.

Those who really know me can tell you that it is the last one that would be the biggest consideration for me. Anything you do to learn more will help you grow and meet the needs of your current or a future employer. And that's what it's really all about, isn't it? Whether you can meet the need.

UPDATE: I stumbled across my own posting from four years ago on this topic. HA! I forgot I even wrote about it back then. But back then, I was an independent consultant. Now I'm a manager.

Technical Debt, Live Writer, and oh yeah, Happy New Year!

AjarnMark — Wed, 23 Jan 2008 06:53:49 GMT

I know, we're already a few weeks into the new year, but I have been so busy with work and life stuff that I haven't been out here in a while, and it sounded like a good start.

I had dinner with Graz last night, and he off-handedly mentioned that I got passed by Mladen in blog post count, as if I might not already be aware of it. ;-) (Congrats Mladen! You are doing a great job and a great service to the community!) OK, seriously, Bill did encourage me to write some more, and suggested that I check out Windows Live Writer. I'm using it now to write this post, and I have to admit that I'm liking it quite a bit in just the little time I have used it. It is a good, simple WYSIWYG editor with options to write your post in either "Normal" text editor look or "Web Layout" which makes it look like you are writing directly in the way it will display on your blog, but without the top and side bars. There is also Web Preview so you can see exactly what it will look like when posted on your blog. And perhaps my favorite feature is to Save Local Draft so I can work on it, craft my words, save it, and come back to it later and edit one more time before actually posting it to the site. And, related to that, I can save drafts of multiple posts, so I can start topics that have been on my mind, and then come back to finish and post them later when I am ready. In fact I just did that to prove it works. I started a second post that I have been meaning to write for several months, and now I have the opening paragraph done. So, if you were like me, and just used the built-in post editor on your blog, go check out Live Writer for yourself. I think you'll like it!

And while I'm here, one more thing. If you are in a position where you communicate to non-technical management regularly, you should go read this article on the concept of Technical Debt. Apparently this phrase has been around for a while, but I just stumbled upon it today and I think it is going to be a very handy analogy to use.

So here's to the start of a great new year! I look forward to more writing this year than last (and hopefully you look forward to reading it).

Cheers!

DBA Interviews from Both Sides of the Table

AjarnMark — Wed, 19 Sep 2007 07:14:06 GMT

A few months ago I was conducting interviews for a Production DBA position that we were creating, and an interesting thing happened...I ran into a candidate who was much like me a few years earlier. Unfortunately neither of us qualified. Here are some lessons from that experience...

Perhaps I should provide a little background for new readers. I have been a database application developer since about 1988 ranging from Info on minicomputers to Advanced Revelation and on to Oracle. I started using SQL Server in 1999 on version 7.0. I have a lot of experience in both the UI and database areas of development. I can hold my own when it comes to the responsibilities of being a Development DBA. A few years ago when I was doing a lot of contract work, I started looking for jobs with the title DBA in them. One of my great frustrations was running into interviewers who, I thought at the time, were inflexible and unwilling to give me a chance to prove myself. At the time, I figured that I was a fast learner and had done a lot of different things with SQL Server, so there shouldn't be much I couldn't handle or figure out (and hey, I always had my friends at SQLTeam to back me up, right?)

So as I was saying, a few months ago while I was conducting interviews, I ran into a guy who was just like I had been. He had good credentials for database development, was a great guy to talk to, and I had no doubt that he could learn things quickly. He was looking for someone to give him a chance. And right then I realized that I was thankful for the past interviewers who would not give me a shot.

Sound crazy? Well, if you have been reading carefully and you understand the terms, you know the problem. This guy (as I had been) was a good candidate for a Development DBA position, but I was seeking a candidate for a Production DBA position. While both are called DBA they have very different responsibilities. Basically the Development DBA supports the application development lifecycle and is generally focused on things such as normalization, naming conventions, constraints and keys, stored procedures and effectiveness overall. A Production DBA on the other hand supports the application after it has been deployed into the live (or production) systems. He or she is often focused on performance, efficiency, and reliability; including backups, replication strategies, serialization, locking and blocking. A Development DBA deals with the pressures of development deadlines, while a Production DBA deals with the pressures of C-Level executives screaming that every second it takes to fix a problem is costing the company umpteen millions of dollars.

So sometimes when you are out there interviewing, as frustrating as it can be at times, you need remember that the interviewer just might really know what he's looking for and you may not be the right fit. In our case, we needed an experienced Production DBA and were not willing to let a guy learn how to do his job on our time. We had an occasionally recurring nightmare that completely locked-up one of our mission critical databases causing about 50% of the company to come to a grinding halt. We already had two highly skilled, but development-focused SQL guys on the team who could read Books Online. We needed something different.

The good news for that candidate was that I recognized this while we were conducting the phone interview and I was able to help him see that I wasn't just being a jerk, but rather that I needed specific skills he did not have. So take a look at what your skills are, and either search for the jobs that fit you, or if you don't have the skills for the job that you want, go learn them as best you can. Maybe somebody is looking for a junior DBA that can join their team and grow into the position they want.

Defining Experience

AjarnMark — Wed, 21 Feb 2007 01:45:50 GMT

I'm sure I've written this before, but while I'm on the topic of interviewing, it bears repeating...

Do NOT confuse 1 year of experience repeated 5 times with 5 years of experience.

In the one, you have just been doing the same thing over and over, hopefully getting better at it, but not really growing. In the other, you are learning new things and growing, hopefully refining what you knew before based on what you are learning now, but at the very least, expanding the total area of what you know.

When a job ad says something like "5+ years experience" it is the latter, not the former, that they are seeking.

Honesty in the Interview

AjarnMark — Wed, 21 Feb 2007 01:36:17 GMT

In my previous post about interview flubs, Jon dinged me in the comments for posting something that is too obvious. As he put it, "who DOESN'T know these?". Well, Jon, apparently a lot of people don't. I have been amazed at the things I have seen in my short stint as the lead interviewer for developers. (I alluded to this earlier, and last month it was finally made official that I am now the Software Engineering Manager.) One of the things that I have seen which I find really shocking is how much people misrepresent their skills. Oh sure, not everyone is intentionally lying. Maybe the problem is that they do a poor job of self-assessment. But if you're going to go apply for a job, you better get a grip on where you stand in your area of expertise.

Specifically, what I'm talking about here is the fact that in my phone screening I would ask people to rate themselves on a scale of 1-10 in several areas. When somebody rates himself a 7 or 8 in SQL Server, then I expect them to be able to fly through the specific technical questions we ask with no difficulty. We are not Microsoft, we are not conducting marathon interviews asking you to design on-the-fly solutions to real-life core business challenges, these are not difficult questions...certainly not if you rate yourself a 7 or 8 on a scale of 10. Yet time and again, I find people cannot explain to me what, if any, benefits they see to using Stored Procedures over in-line code. They struggle to explain the priciples of 3rd Normal Form, and we are not asking for the textbook definition, just give me the impression that you have a basic understanding of the concepts. We give them a basic problem with a subquery and ask them to rewrite it without the subquery. This is the classic example of using a JOIN and they miss it. We describe another classic example of when you would use a CASE statement, hoping that they can come up with that, yet they don't. I ask them their general impression of cursors and they have never heard of them! And they have the gall to tell me they are a 7 or 8?! Come on, get real! I'm not asking for you to explain the inner workings of transactional replication or to setup a Read80 Trace.

On the bright side, our simple questions are doing the job they were designed to do, which is to weed out the posers. I'm just astonished at how many of them there are. So here's my tip...Be honest with yourself and with the interviewer. I had a guy who was very honest with me that his SQL skills were not very strong but he was strong in .NET which was an additional skill set we were seeking. I really appreciated his honesty. I tailored the questions I asked based on that information and we had a great interview. I knew what to expect from him and he was right on. We were about to offer him a position because we knew what he could do and he had been completely honest with us, but unfortunately somebody beat us to it. But I'll tell you this, if I ever see his name come up again, I would not hesitate to give him another shot. That is quite unlike many of the others I have interviewed, who have no chance of working for us. And anyone else I know who is doing interviews, I would recommend they be sure to ask the detailed questions of those candidates so they know what they are getting.

Escape From Cubicle Nation

AjarnMark — Wed, 21 Feb 2007 00:21:14 GMT

For those of you who are already independent contractors, or thinking about taking the plunge and being your own boss, some good ideas and good humor awaits you at the Escape From Cubicle Nation blog.

The Interview - Don't Blow It

AjarnMark — Mon, 22 Jan 2007 04:17:31 GMT

While I am putting together a few of my own tips based on my recent experience of interviewing candidates for developer positions, here are some tips from eWeek on 10 Avoidable Interview Flubs.

Geek Marketing 101

AjarnMark — Thu, 02 Nov 2006 06:08:55 GMT

Found this post titled Geek Marketing 101 at Make Marketing History by way of Guy Kawasaki's Blog. Of the little I have read so far, the Make Marketing History blog looks promising for no-nonsense business/marketing tips.

As for Guy Kawasaki, I have been enjoying his blog for the last couple of months. I don't remember how I stumbled across it, but it's an interesting perspective on business. If you don't know who Guy is, go ask "the old guy" in the IT department at work and learn a little history of your world. Or for the advanced history course plus some current trends, check out the new DVD In Search of the Valley and enjoy some stories from Guy, Woz, John Warnock, Craig Newmark, and others.

Interviewing Tips & Tricks

AjarnMark — Wed, 16 Aug 2006 06:18:00 GMT

As an independent contractor, I spent plenty of time as the candidate looking for work. Each time, I learned a little bit more about how to do it better, but I sure could have used some tips, especially in the early years. Over the last year, I have been involved in numerous interviews on the hiring company's side of the table, and again I find that the first ones were rough and we probably missed some good candidates because we didn't know how to screen them well, but we have gotten better over time.

Whichever side of the interview table you find yourself on, the following articles may help you excel in the process:

In Fixing the Software Development Industry, Eric Wise discusses both sides, from discussing ways to identify the “dead wood” in the company (and how to not be one) to things the potential employer should ask and be on the watch for. And in his follow-up article, Interviewing Your Employer, Eric provides several good tips for the interviewee. And finally, Fast Company has an article on Cracking Your Next Company's Culture which is all about creative ways to decide if the company or position is right for you. While not specifically about the software industry, many of the tips can be easily adapted to researching software positions.

BATNA

AjarnMark — Fri, 07 Jul 2006 03:40:00 GMT

Eric Sink, known for writing about the Business of Software and principal of SourceGear has a great post about The ONE Key Thing to Know About Negotation, and he hit the nail right on the head. Being a business major, I actually had a class on negotiation, and one of the few things I remember from it is the acronym BATNA. I realize that is a five-letter acronym, but I have confidence that even you CSci guys can remember it. :)

BATNA = Best Alternative To a Negotiated Agreement

Or, as Eric put it, the ability to walk away. Instead of dreaming about how good things will be when the deal comes together, think about how good can you make it if the deal falls apart. If negotiations break down, what is your next best alternative? How good or bad is that alternative? When you solidly know this, then you know at what point you can still walk away from the deal if you don't like how it's going.

Many people think that they are stuck and helpless in a negotiation when they really are not. Usually it is a lack of preparation in determining their true BATNA. I was guilty of this when I bought my Land Cruiser a few years ago. I had done my homework about what SUV to get and I was pretty emotionally caught up in getting the Land Cruiser. I wasn't ready to drop the dough for a new one and I was totally unprepared for the apparent shortage of them used. I had not done my research. I had not checked other dealers or searched online. I actually was only going to "stop by and look", but I got caught by a good salesman and test drove the only one they had on their lot. I was hooked and he was very good at his job, and I ended up buying it that night for more money than I should have paid. In fact, it was right at the time that the used car market was starting to tank because of all of the 0% financing deals on new cars and I ended up upside-down in that loan for several years. I made a HUGE mistake because I was not prepared to walk away. I had not figured out my BATNA.

The lesson applies equally to negotiating business contracts. An important key here is to do some very serious analysis of what your alternatives really, really are. Too often, we play the role of helpless victim and give up all negotiating power by mistake. Maybe you're hungry, but are you really on the verge of starvation? At the same time, we have a natural tendency to think that the other side has it made in the shade. Remember that the other side is figuring out what their BATNA is, too. Maybe the company has been trying to fill this employment position, or complete this contract work, for a long time and you are the best candidate they have seen in months. Maybe the work does not sound that critical, but if they don't get it done, they will forfeit a large contract of their own. Maybe the car salesman is having a rough month and his manager threatened to fire him at the end of the week if he doesn't make more deals. You don't know what their BATNA is, but you had better know yours.

The more willing you are to walk away, the more power you have in the negotiation.