An expert roundtable discussion hosted by SQL Server Expert Kevin Kline and featuring speakers from Microsoft, EMC, Avanade, HP and Quest Software.
With the release of SQL Server 2005 and its focus on Business Intelligence, SQL Server professionals are faced with unprecedented amounts of data to manage. How are you dealing with the flood of data?
At the PASS Community Summit 2006, experts from Quest Software joined forces with a variety of other SQL Server industry experts for a panel discussion around the implications of managing large volumes of business critical data on SQL Server and recommendations for ensuring availability and performance in your environment.
Some areas explored:
- Storage strategies
- Issues around moving to Storage Area Networks (SAN)
- Performance on SAN
- BI growth and multi-terabyte data stores
- Server scale out and consolidation
- Real world implementation and management challenges
Third-party applications are a very important part of the IT landscape. Many of us have faced the common dilemma of trying to decide whether to build or buy that next important application our organizations need. (By the way, I’m talking about smaller, specialized applications like an inventory management system for the company warehouse, or a practice management system for a doctor’s office. I’m not talking about the huge and incredibly sophisticated ERP systems like SAP and Oracle Financials.) [READ MORE]
There are three basic interview styles you can use when interview technologists: biographical, technical, or behavioral. Each has advantages and disadvantages. Because of this mix of pros and cons, some organizations will mix two or more of the styles, or allow different people in the organization to serially interview the candidate using different styles. We’ll cover each of these styles in a bit more detail and provide some examples of interview questions that you might use with them.
BIOGRAPHICAL
The biographical interview style offers the advantage of requiring the least amount of advanced preparation. In essence, the biographic interview is a recap of the candidates’ major life experiences as described on their resume. The biographic style requires that you sit with the interviewee with resume in hand. As you examine the resume, you ask about things discussed on the candidate’s resume that are relevant to the job you’re looking to fill.
Imagine that you’re looking to hire a junior DBA, you might ask questions like:
I see you worked as a junior DBA in your last job. What is your disaster recovery experience?
How much time did you spend at ACME Company doing security and user management?
When you were in the Air Force, did you ever have to spend time in the field offices helping clients?
The biographical style’s main advantage is it requires very little advanced preparation. On the other hand, it’s main weakness is that it can be difficult discerning quality of experience from quantity. In other words, you’ll have to probe carefully to determine whether the person has five years of experience rather than one year of experience five times.
When conducting a biographical interview, be on the look-out for certain red flags on the person’s resume:
Long gaps between jobs indicates the person may not be motivated to find jobs, may have health problems, may enjoy experimenting with jobs outside of your industry, etc.
Frequent job tenures of less than two years may indicate the person grows quickly bored and may not stick with your company for long.
A long career without evidence of growing responsibility or skills may indicate low motivation or interest in technology.
A candidate who is unable to secure strong references usually indicates an anti-social personality and inability to form strong personal relationships with their teammates.
TECHNICAL
The technical interview style offers the advantage of quantitatively proving whether the candidate has the mettle to meet your strongest technological challenges. It takes a bit of time to prepare because you’re basically going to ask them your toughest technical challenges. If you’re a bit of slouch, there’s great news for you. There’s a ton of technical interview questions already written and posted to the internet waiting for you to download. If you simply conduct a Google search, you’ll find multitudes of general information technology questions. It’s a bit harder to find them already specific to SQL Server, but they do exist.
And then he said "There are only 10 types of people in the world — those who understand binary, and those who don't." I ROFL'ed and LOL'ed.
As a reminder, your technical questions are designed to determine if a candidate can fulfill a specific technical role on the team. So your questions should be a) specific to your situation, and b) administered very much like a test, with pen and paper (or a computer) provided along with ample time to assess a solution. Some examples of technical interview questions might be:
For an ETL architect: “Build an SSIS package, using the GUI, that’ll perform a data load and cleansing process. Make sure that it logs it’s activity at every step.”
For a database developer: “Here’s the schema of a database. Devise stored procedure that will do X, Y, and Z.”
For a DBA: “Our OLTP application gets 6000 transactions/hr. Define a high-availability configuration and backup routine that will ensure we never lose more than 5 minutes of data and will get us back on-line within 3 minutes of a catastrophic failure.”
Some technical interviews also seek to understand how a candidate thinks, processes information, and approaches problems. In cases like these, the technical interviewer will generally ask the candidate to think aloud about a general challenge. For example, Microsoft once famously asked its candidates “Why are manhole covers round?” There is a right answer to this question (a round manhole cover won’t fall through the hole), but it’s also as much about how you go about solving the problem.
BEHAVIORAL
The behavioral interview style, my personal favorite, offers the advantage of giving you the best insight into how a candidate will do their work in the future. Behavior interview, another topic with abundant help available with a quick Google search, is centered around questions of past performance, since that gives us the best indication of how a person will act in the future. Some example questions:
For a product manager who has to deal with a lot of conflicting requests: “Tell us a time when you had to prioritize conflicting opinions.”
For a database developer with a heavy workload: “Tell us about a time when had to work long hours. How did you maintain work/life balance?”
For a development manager in a business that lots of merger and acquisition activity: “Tell us about a time when you had to make and win support of unpopular decisions. How did you keep your team on focus?”
To conduct an effective behavioral interview, you have to assess the specific challenges of the job (though not necessarily the technical challenges) and then ask questions that illustrate how the candidates face down those scenarios. Will they have to work with a team of cantankerous old-timers who are set in their ways (like me)? Then you might ask how they have dealt with keeping old technologies fresh. If your shop is always on the cutting edge, then you might ask how a candidate is able to keep their skills sharp while putting a full measure every day at work. (Of course, a smart candidate could possible perceive the problems that they might then face when coming to your company. But that’s usually ok.)
Another element of a successful behavioral interview is that you must be willing to let the candidate have a few moments to think about their answer. Most interviewers don’t like silence. It makes them uncomfortable and they quickly seek to fill it. To conduct a good behavioral interview, you have to be willing and able to let that silence stretch a bit longer than you’re comfortable with so that the candidate can comb through their memories for a good example. And that’s the payoff, because an example of how a candidate solved a challenge in the past is a pretty good indication of how a candidate will solve something similar in the future.
The idea of “SQL Server in the cloud” is all the rage as I write this article. Many SQL Server experts already predict the demise of the IT data center and a complete upending of the current state of our industry, in which large enterprises can spend millions of dollars on SQL Server licenses, hardware and staff. I have to admit, when I first heard about this idea, I was ecstatic. What could be better for an enterprise than to have all the goodness of a SQL Server database with none of the hardware or staffing issues? However, on deeper examination, there is much about which to be cautious. [READ MORE]
As I promised in the last post , I’ll be covering hiring in greater detail over the next three installments. Today, I’m going to talk about what goes into effective hiring before the interview ever takes place. Future installments will cover the various interview styles you can choose from in some detail, to be followed by another installment on what sort of team involvement and interview format you choose.
An Interesting Way to Filter Out Less Qualified Candidates
The Ideal Candidate
Hiring, training, and acclimating a new person to your organization is estimated to cost anywhere from 17-32% of the position’s yearly salary. It’s for that reason alone, if not for the turmoil and disruption of bringing a new person into the team, that many organizations spend a lot of time trying to make hiring as bulletproof as possible. The last thing you want is for the new hire to not work out – it’ll cost a lot of money to fix the error!
The first element of your pre-interview preparation is to actually have a good idea what qualities and characteristics the ideal candidate should possess. A quality is an aspect of candidate’s personality that impacts their work behavior, such as punctuality, friendliness, or attentiveness. Characteristics are learned skills that help on the job, such as prioritizing well, communicating effectively, and meeting deadlines. This may sound like an elementary component of the process, but you’d be surprised how many times this essential and fundamental step is given short shrift.
Does your resume look like this?
TIP: A decent shortcut for this step is to consider someone in this job who’s already doing an excellent job. List out their qualities and characteristics while making the list as impersonal as possible.
PROS: By identify the qualities and characteristics of the ideal candidate, you can better control the composition of your team as a functional organism. Teams work best when their members enjoy each other and sync easily. If you work for a faith-based organization or non-profit NGO, you’re not likely to want a person on the team with an unrefined interest in altruism. If you work for a highly structured and conservative consulting company, you’re unlikely to opt for the Birkenstock and tie-die loving hipster. On the other hand, when you work on a team that gives a lot of product support, you probably want someone who’s warm and friendly to strangers. Now, remember that this does not mean your final candidate must have all or even most of these qualities and characteristics. This step is only performed to determine what qualities and characteristics will make the eventual candidate most successful in their job.
CONS: Failing to do a good job at this step is exponentially more likely to happen when you have an inexperienced, immature, or plain ol’ incompetent manager in charge of the hiring. I’ve worked in several organizations where the main reason the manager was seeking to hire a new employee was to simply increase the size of their team and, by extension, expand their own prestige. This behavior is sometimes called “empire building”. The most common result of this fault is a manager who hires people who are much like them without regard to whether they are competent or not. “He got the job because we’re both UT graduates!” is a common refrain in situations like this. This can deplete the team of diversity and a wide variety of experiences and preferences.
RESUMES
By focusing on the qualities and characteristics of the candidate, you can assess resumes with a new set of eyes. And this composes the second essential set in the pre-interview days of the hiring process – read all of the resumes. HR or your recruiter should be able to provide you with a big stack of resumes. But which ones are ideal? As the key technologist in the hiring process, you are uniquely able to identify those candidates who are ready for the next round in the hiring process. Furthermore, you should be able to identify the “diamonds in the rough” among your potential candidates. If you’re looking for a top-drawer .NET developer, you’ll be able to tell the ones who have four years of increasingly sophisticated experience from the ones who’ve had the same one year of experience four years in a row.
You’ve probably heard anecdotes about the amount of resumes floating around out there. One friend of mine at a major technology company said that he routinely sees eight hundred resumes submitted when he posts for an opening on his team. Of course, most of these resumes are weeded out by HR at his company. Needless to say, with eight hundred resumes to pick through shows that there’s no shortage of people apply for jobs. The shortage is usually for talented people.
Application Rejected!
When I have a large number of resumes to examine, I hate to say it but I usually look for any excuse to exclude a resume from further consideration. Spelling or grammar errors – you’re outta there! Formatting issues or inconsistencies – next! Employment dates don’t add up – gone! You can be much more forgiving, of course, when there are fewer candidates to assess. However, most people realize that their resume is their first foot in the door. If their resume isn’t showing a high degree of polish, what’s that say about other aspects of their professional demeanor and performance?
Ideally, though, when you evaluate a resume, you’ll easily be able to see whether the candidate meets the technical requirements of the job. If you’re looking for a developer, do they have the right sort of computer language skills? If you’re looking for an administrator, are they skill with the right operating systems and hardaware? While it takes some time, this is usually one of the easier steps of the process.
TIP: You should read all of the resumes as they’re presented by HR or your recruiter. You should also review the individual resume of each candidate about an hour before you interview them and identify any areas on the resume that you’d like to discuss in further detail. This step also ensures that the details about the candidate are fresh in your mind and avoids wasting time reviewing their resume while you’re sitting at the interview table with your candidate.
BEFORE THE INTERVIEW
Once you’ve pared down number of candidates to a short list, you can begin to schedule them to come in for the interviews. There are couple quick and easy things to remember at this stage:
Make sure you have a quiet conference room available for the interview. If there’s not one in your office, consider going off-site to a quiet café or bistro.
Make sure any other participants in the interview have read the candidate’s resume and are clear on their role in the process.
Have printed copies of the resume available in case someone in a multi-person interview has forgotten their copy. Have an extra pen or two handy as well.
Ensure that beverages, at least water and coffee, are available for a morning interview as a simple courtesy. Water and sodas in the afternoon are appropriate. If you have sodas, make sure at least one sugar-free option is available for diabetics and dieters. Why go to the trouble? Don’t forget that the candidate is also interviewing you to see if there’s a good fit.
Unless the position you’re interviewing for is junior, interviews that happen around lunchtime should be followed up with an offer to pay for the candidate’s lunch.
Bring your laptop to take notes. Most computer techies type much faster than they handwrite. You can also keep a list of your interview questions on the screen in such a way that it’s usually obscured from the candidate.
After meeting the candidate but before the interview officially begins, conspicuously turn off your cell phone, put away your Bluetooth earpiece, etc. If the candidate doesn’t take the hint, ask them to do the same.
Following these steps sets the groundwork for a successful and effective interview. In the next installment of this series, we’ll discuss the various interview styles including sample questions, followed by another installment on what sort of team involvement and interview format you choose. Once you’ve gone through this process, you’ll find that hiring, like many things in the technology world, can follow a well-orchestrated template, making future efforts much easier.
Though things have died down a bit since the initial backlash, the recent development in the PASS board election process is still the talk of the town. I’ve had the opportunity to talk to a number of folks about this, and have read some excellent blogs and other opinion pieces from those on both sides of the debate. I traded some e-mails with Kevin Kline, a longtime member of the PASS board of directors, and he asked an interesting question:
“Many in the community seem to think that the PASS election process is badly broken. Do you think that PASS needs to implement fundamental and far-reaching changes to its election process, or does it only need some fine tuning? Please explain your thoughts?”
I’ve been careful not to write too often about this out of fear of belaboring the point, but I think Kevin’s question (and some of the other responses already offered up) illuminate a path to help the community heal its recent wounds and find a better way to do things in the future. To that end, I’m glad to share my opinion.
It’s STILL The Process
I can’t emphasize this enough – I believe this to have been a process failure, not a people failure. I blogged about this just after the story broke, and I pointed out that I believe this to be a deficiency in the institution rather than a bunch of folks making bad decisions, or worse, conspiring to keep a particular person out of the leadership of PASS. It was, and still is, my belief that some personal biases contributed to the end result, but I don’t expect that there was a conspiracy to exclude anyone. I greatly appreciate the work of the NomCom, especially the members who were selected from the community (those who are not board members). They put in a lot of hard work, stuck to their guns on the decision they made, and took it on the chin for the sake of the integrity of the process. While I still feel that their decision was not in the best interest of PASS, I thank them for their service and applaud their willingness to politely engage their critics.
Where Do We Go From Here?
With the blame placed firmly on the process, let’s get back to Kevin’s question. Where do we go from here? Do we rip out the plumbing and start over, or can we just repair the leaky pipes? Before we answer that question, let’s look at…
The Good
Yes, there are things that I like about the current process <gasp>. For example, let’s pretend for a moment that the election process has no vetting whatsoever, and anyone who throws their name in the proverbial hat will appear on the final ballot. Yes, you’ll find folks like Steve Jones, Jack Corbett, Geoff Hiten, Allen Kinsel, and others who are highly qualified, but you’ll also end up with folks who simply run because there’s nothing to lose. The existence of a proper vetting process will encourage applicants to self-screen to some extent, but the absence of such a formality could greatly increase the number of unqualified applicants. There are a couple of risks with having no qualification process: First, the truly qualified candidates will be lost in a sea of other names, and the voting process becomes as low-tech as “which one of these people have I heard of before?”. Second, the odds of an unqualified person actually making it onto the board are quite high, which is a risk for the future of the PASS organization. I am in favor of having candidates pass through a screening process, and I think the theory (not necessarily the current implementation) is sound.
Another positive is the amount of progress made towards transparency. What used to be a black box now permits a good deal of visibility by the community, and even though some parts of the process are cloaked from public view, I think PASS as a whole is committed to improving the transparency of their processes. There is still lots of room for improvement, but it’s safe to say that improvements have been made.
The Bad
We could go on and on here, but most of the dialog would be centered around once core question: Who is qualified to run for a BoD position? Hopefully we can all agree that last year’s selection process was a mess, when candidates including Tim Ford were excluded while another with no knowledge of the PASS mission or community was deemed to have been qualified. This year’s process resulted in the exclusion of a candidate who is the epitome of the SQL Server community. So maybe he had a bad interview (we are allowed to know that “something happened” during the interview, but nothing more) – it happens. Moving forward, the NomCom needs to have the flexibility – no, the responsibility – to look beyond just one interview to better judge the candidate’s abilities and contributions.
The NomCom doesn’t need to go away – it just needs new rules of engagement. The mission needs to be refined and simplified: Eliminate the unqualified candidates. Let’s set some reasonable minimum qualifications of education, leadership, volunteerism, and organization, and judge the candidates equally and fairly across those axes. Beyond that, let the community decide whom of those qualified should be on the board.
Bent or Broken?
Bent. I think there’s enough sound logic to salvage this process, but we must remember the lessons learned these last two years. The process isn’t fatally flawed, but it does need to be resuscitated.
In my last column (published in the February e-edition and the March print edition of DBTA), I reviewed the overall coding landscape for SQL Server with special focus on LINQ to SQL, a new technology introduced by Microsoft in late 2008. LINQ to SQL promised to make developers’ lives much easier by allowing them to focus on writing programs in their favorite Visual Studio language and letting LINQ to SQL write all the Transact-SQL code. The problem is that LINQ to SQL writes very bad Transact-SQL code. [READ MORE]
