Part II of My Analysis Services Interview Questions: Cool Business Problems
I’ve seen a variety of techniques used by staffing companies to combat the beating I’ve given their previous candidates. Though I’ve never been hit by the bait-and-switch, candidates have tried to look up answers during the interview; they’ve had somebody in the room with them; and the last technique seemed to be the group interview. In addition to the candidate, the phone interview would include the sales rep for the staffing company, and often another technologist. Why? To write down the questions, of course! I can only guess that the last candidate I rejected complained about how unfair the interview was, and the recruiter wants to be sure they get every advantage possible and they think they’ll get a leg up by writing what I ask. Fair enough, but it won't help you because I’ve learned some great interviewing techniques, like asking follow-on questions based on your first answer. I understand that the goal for a staffing company is to put cheeks into paying seats, but that's not my goal when I'm interviewing, or when I'm a candidate.
I use an axiom in the classroom and with client personnel who are learning business intelligence: if you can’t articulate the answer, you don’t know it. Some will say, “I know the answer. It’s in my head but I can’t tell you what it is.” I repeat: if you can’t articulate something, you don’t know it. The only evidence of knowledge is its articulation, so let’s lay out a couple of rules.
-
Rule 1: If you can’t articulate something, you don’t know it.
-
Rule 2: If you think you know it but just can’t communicate it, refer to Rule 1.
I always start with high-level business questions. I believe that technical knowledge is the easiest of all skills to acquire. Writing, speaking, architecting, and mentoring are far more difficult. Complex business problems require passionate people with creative solutions. The high-level questions explore all of these at one time. I want to know if you’re a thinker and a learner, squeezing as much as possible from your experiences.
I usually lead with the following:
“Tell me about some great business problems you’ve solved with Analysis Services.”
I expect to hear an answer like this: “I used Analysis Services to provide certification supplier metrics for a retail supply chain. The database and cube(s) that provided these answers had 45 dimensions, about 10 measures, and 25 calculated members. My favorite metric was a ratio of dollars ordered to dollars received because the business could ensure they were getting what they paid for. Additionally, they were able to reduce back office labor for receiving because they could avoid detail receiving for suppliers they knew were doing well.”
Some of the answers I’ve actually received are downright comical.
“I used surrogate keys.” That’s very nice, but it’s hardly a business problem.
“I built a star schema.” Stating an obvious architecture is not evidence that you really know what you’re doing.
“I used MDX.” That’s good! Perhaps you used dimensions and cubes as well, but quoting product features provides no evidence of problem solutions.
But my favorite is a maddening three-part answer vaguely reminiscent of the Underpants Gnomes in a certain South Park episode. The Underpants Gnomes were “experts” in big business because “underpants are big business!” The Underpants Gnomes had three steps:
Here’s what I get as the most common answer to the question about business solutions. “First, I talk to the business and gather requirements. Then I make a design. Then I build software.” See? It IS the Underpants Gnomes, who would say it like this:
Of course, this isn’t a business solution. It’s an approach to solving problems and it’s so obvious that nobody should have to say it. It would be like going to a staff meeting and hearing a low-level manager lecture you for 15 minutes on the importance of profit. (Duh. And yes, I’ve experienced this with a prior employer. Note I said "prior.")
It may be obvious, but I hear it repeated so many times. Over and over and OVER again.
In an earlier installment of this blog I noted the existence of talking points. I invariably get these from candidates stemming from one Asian country. It’s like there’s a four hour seminar that instructs candidates, “Americans LOVE process. If you tell them this, they’ll see that you’re truly an expert and will have no choice but to take you!” I’ve had candidates stick to this party line even when I tell them, “That isn’t a business problem. What interesting business problems have you solved?” I’ve actually told more than one candidate to stop repeating the line because I don’t want to hear it again. (I must be the Dr. Laura of BI interviews.) I usually provide examples in hopes of spurring the candidate to action because sometimes there are linguistic difficulties. Some candidates respond well after that; some don’t. In a couple of cases the interview has ended because the candidate can’t deviate from the party line.
Why can’t they answer the question? There are many reasons. After teaching SQL Server to adults for more than five years, I’ve taken a very dim view of the average adult’s learning ambitions and thought intensity. Most people just don’t pay attention and learn lessons. Others are terrified of talking, but it’s an interview and you must talk. I think the majority of them simply don’t know the answer to the question but they believe such an admission is failure. Well, you surely won’t be recommended for an architect position if you can’t tell me what cool business problems you’ve solved, but you may have a personal epiphany that leads to personal growth.
Mostly, candidates responding in this fashion haven’t really used Analysis Services to any great degree even though their resume says they have. They’ve had success bluffing their way with interviewers who can’t tell the difference. Personally, I only put on my resume those things in which I am competent or expert but I seem to be a rarity. In fact, here's some advice: I don't like 10 page resumes. I don't mind four or five pages because it's my duty to read your resume and see what you've written. If you've worked for 10 or 15 years, I expect more than two pages. But if you get much past five pages, you're either playing cut-as-paste patsy, or you're telling me stuff I don't care about, like what you wrote in FORTRAN or how many NIC's you replaced. BTW, if you feel the need to tell me that, this doesn't help you and may hurt you. If this is a BI interview then I want to know what you've done that is pertinent to BI. (And don’t get me started on recruiters who don’t actually READ your resume. I get called frequently for Oracle/Informatica work even though those words don’t appear on my resume. Yes, many of the same letters in those two words appear on my resume, but not the actual words themselves. Would you believe that today I got a hit for a UNIX/Sun/Solaris admin? Huh? You can't find any of those words on my resume with just a keyword search! But I digress...)
The lesson here is to pay attention to your experiences. Wring every last drop of wisdom from your work. Be prepared to talk about those experiences and what you’ve learned. You never know when an interviewer will ask you about them!
NEXT. Part III of My Analysis Services Interview Questions: Architectural Philosophy