What is Digg?Sponsored by Norton 2010
80's metal band Dokken vs. a chicken. Who would win? view!
everyclickmatters.com - It's raw head-banging talent against raw meat. See the showdown. Seriously.
48 Comments
- Tredici, on 10/12/2007, -0/+13I've found you can always find the better applicants by simply having a relaxed and informal chat which relates to the duties the potential employee with fulfill, in this case, SQL server database development. You'll find that the applicant, if at least half competent, will attempt to work in to the conversation everything he or she knows, whilst also remaining relaxed and hence, you'll get a much more accurate snapshot of how the person will act in day to day situations.
By asking these sorts of straight-up pressuring questions you can often scare applicants which know the answer but haven't ever had to define it on cue as such. It's like the argument between hiring an employee with a degree or one with three years of industry experience. Being a good DB developer is most definitely not about knowing the word for word definitions of indexes, primary keys and the NULL value, although I'm not arguing this doesn't help. - airjrdn, on 10/12/2007, -6/+14I'm guessing:
a - you know extremely little about it
b - you're one of those people that thumbs up macs and linux and thumb down anything MS related
c - you've never had a "real" job
d - you're just plain stupid.
Note that these aren't mutually exclusive...multiple answers could apply to you. - pdavis, on 10/12/2007, -1/+8I must disagree, I am an MCDBA and work with MSSQL server almost every day. But, I develop on a small team, usually just myself, and on small projects, usually just a week or two. I don't need to know the answers to most of those questions because I don't do that sort of thing on a day to day basis. But, when I need to, I just pick up a reference or search the web for the answer. Most of this sort of thing isn't that hard but if you don't use it on a regular basis, it isn't going to stick around in your head just waiting for an interviewer to ask you. When I interview candidates, I am more interested in what projects they worked on and what they actually did on those projects.
- darkstar949, on 10/12/2007, -1/+6There are some good questions in there - but the first few questions are a bit too basic, if you have an applicant that couldn't even get through the first page of questions then you might need to talk to who is screening the applicants to ensure they know what to look for.
- darkstar949, on 10/12/2007, -1/+5More often than not the people in charge of hiring are not in the same field as the applicant - DBAs do not typically hire other DBAs. In some companies all interviews are handled by an HR department who is told what qualifications to look for, and the receiving department may not even meet the applicant until after they are hired.
- ABadInAlbany, on 10/12/2007, -1/+5uhhh, hash join and loop join? maybe for a DBA job, but not necessarily a DB dev job. but if a dev knew the answer, sure, I'd hire him or her.
- MattL920, on 10/12/2007, -0/+3All you need to know about cursors is that if you're using in production code you should be fired. They're sloooooow.
They have their place though, if you're scheduling off-hours maintenance scripts that need to iterate through some tables without regard to speed. - rodrigo74, on 10/12/2007, -0/+3Agreed with Tredici..with this kind of questions you might end up hiring a MCSE-champ, but not necessarily the best guy.
If the interviewer is also proficient in SQL Server, a good chat should be enough to get an idea of the guy's skills. Of course you can fit some specific questions here and there but not as a school drill.
It is also important to get people who can find their own answers when needed, and, especially in the case of a DB admin, it _must_ be someone who can keep his cool during crisis. The certification-champ above might as well be one of those guys who knows all the answers but panics to death when a production database goes down at 2 AM. - gtiness, on 10/12/2007, -0/+3These are good questions. It's a good start. I think db developers should be asked about how they mitigate SQL Injection attacks in their code. And, every developer, regardless of programming language, should always be asked about error handling (try/catch) in most modern languages.
and, ask them about opening/closing connections + connection pooling. do they really understand what's going on? especially if they are a .Net developer as .Net tends to hide a lot of complexity. - nilekinnick, on 10/12/2007, -0/+3Amen pdavis. Having been in a sql developer position for 5 years (3 years ago) as well as successfully completing a part time gig as a sql developer (yeah, IT contractor) last month....these questions would only seem to indicate a candidate knows definitions.
You hit the nail on the head for a candidate to be engaging when describing past projects, their role on the project...and what I look for...what was the project trying to accomplish and how did you know if you were doing a good job or not.
The bulk of these competencies can be gleaned through having the candidate explain 'How did you do that?"
Lastly...my kicker question when I used to interview programmer's was 'Describe one of your favorite projects that you've worked on and why is it one of your favorites?"
This is a great way to see if the candidate has passion about their job....which is a rare trait...but heck, when I would bring in people in my groups...my #1 requirement was ..."Are they going to care enough to stay up till midnight or beyond if their not done with a commitment yet?" I can live with having to teach someone some sql skills....
- jrchin, on 10/12/2007, -1/+4I'd add "What's the difference between a table variable and a temp table?" and "What's the difference between a hash join and a loop join?" The table variable vs temp table question is pretty basic. I bet you could really weed out a lot of people with the hash vs loop join question.
- rip747, on 10/12/2007, -0/+3Personally these question were so basic that they can be applied to ANY database platform.
- Max3000, on 10/12/2007, -0/+2... in short, someone who learns and adapts quickly is a **lot** better than someone with some fixed predetermined knowledge.
- ABadInAlbany, on 10/12/2007, -0/+2but try/catch didn't exist for 2000 ... new to 2005. and most small companies who'd apparently need a guide like this to begin with probably aren't in 2005 yet. I work for a huge corporation, and we're still in 2000 ... mostly to support integration with a smallish (~100 employees) vendor still in 2000.
- probeta, on 10/12/2007, -0/+2uhhhh if you are a small company outsourcing a db project and have no idea how to write 2 lines of code, this could help weed out those who would say they knew what they were doing.
- MattL920, on 10/12/2007, -1/+3It's important for a dev to know these things too. It's just like writing any other code, if you don't know what's happening behind the scenes (in this case what the likely execution path taken by the optimizer is) then you're liable to write slow, inefficient code. If you can interpret what those different joins mean, you'll know why your query is taking longer than you thought it would, and you can fix it.
I learned this the hard way... - MattL920, on 10/12/2007, -5/+7Because flat files are so 90s
- ZergyPoo, on 10/12/2007, -0/+2I agree with you completely 100%.
The company I work for has been turning away smart people because they don't know a specific language. And these are for entry-level positions. This is Silly, it's much more important to hire someone who can do research and learn a language quickly over someone who isn't as smart but already knows said language. - jeffreymcmanus, on 10/12/2007, -1/+2I am not sure that somebody absolutely needs to know how to program triggers to get a SQL Server job. I never use them; to me they're the GOTOs (considered harmful) of database programming.
- gharding, on 10/12/2007, -0/+1I dunno. I can make up a pretty much rockstar resume for a ton of tech jobs out there that I wouldn't be qualified for. It's not usually hard to fake it past resume screening, but hopefully some of these simple questions would be brought up in a phone interview.
- Lazybones, on 10/12/2007, -0/+1Exactly what I was thinking.
- petepete, on 10/12/2007, -1/+2I'm an SQL Server developer (although for non-work stuff I use PostgreSQL) and got all of these except "What is a correlated sub-query?". I've written them but didn't know they had a special name.
I think I'd also include some questions about union/intersect/except and costing/strategies for optimising queries. - MattL920, on 10/12/2007, -1/+2I agree... that last one on subqueries doesn't really take a seasoned developer like he suggests. Even an intermediate sql server dev should know how to use temp tables and subqueries and the like to pull different datasets together for use in a query, when to use one over the other, and the performance implications of each.
- kd1s, on 10/12/2007, -1/+2I looked at the questions and could answer them all, but my experience with MS-SQL is pretty light, I have more experience with MySQL, which I much prefer.
Anyhow - anyone with an information science degree can pretty much score 90% or higher on that little test. And wouldn't you know, I have an I.S. degree. - Max3000, on 10/12/2007, -0/+1It pains me every time to see developers themselves agreeing with these sort of questions. They don't tell you anything valuable about a candidate. Our field is one driven by keywords in a CV and that's very unfortunate.
What's a lot more important and relevant is to ask the candidate about past work and their responsibility and relationship to it. To go one step further, give them a written test (with, say, 10 questions, 1 or 2 tricky) to assess their programming skills. What do you want? A person who has recently worked with SQL server and that has met all the problems related to your questions, or a good software developer? These questions will give you the former and tell you nothing about the later.
I have never touched a SQL server in my life. However, I'm pretty sure I could answer all these questions (and a lot more) after having spent a day or two (8-16 hours) reading a book (or two) about it. Not to mention that most of these questions can be answered in 30 seconds flat using google. I would personally not want to work for someone who thinks answering these question correctly makes you a good candidate. - jayhawk88, on 10/12/2007, -0/+1"There are some good questions in there - but the first few questions are a bit too basic, if you have an applicant that couldn't even get through the first page of questions then you might need to talk to who is screening the applicants to ensure they know what to look for."
You'd be surprised what you have to do for interviews. Typically in mid-to-large companies candidates are screened by HR people, who usually are just trained to look for a specific set of buzzwords in a resume/app. Even after your interview teams further whittles down the list, some people just have a knack for writing world class resume BS. We've had people come in for Network Specialist interviews who couldn't tell us why you would want to use NTFS on a server. - helpimstuck, on 10/12/2007, -0/+1The article didn't mention that someone needed to know how to program triggers, they just needed to know the options available. I'm an MSSQL DBA & Developer and I have not used triggers in production, either. A few years ago that concerned me so I created a project that used triggers to stop blog spam. I learned them inside and out but still have not used them in production.
- helpimstuck, on 10/12/2007, -0/+1PDavis, I also work on small (for myself) and medium-large (for my employer) DB projects and I'm an MCDBA. I knew the answers to all those questions (sans the 'correlated' subqueries). Seems like second-nature stuff no matter how small the database. I'm a bit surprised you weren't familiar with them, especially because I probably learned about most of the answers while studying for the certification.
- grumpyrain, on 10/12/2007, -0/+1What about asking them about isolation levels and when to use what?
MVCC vs Optimistic locking?
What problems are likely if a database is not normalised?
What benefits does normalisation bring?
I can't believe they suggest that triggers can completely replace declared foreign key constraints.
I would never ask a candidate to list database objects. I would rather ask them for an example of a problem they could use a view, stored procedure, trigger, user defined function, etc to solve.
Difference between inner join and outer joins (full, left and right) by example - giving two tables with sample data and a simple query, asking what is returned for each.
What is a re-entrant join and give an example of its use.
You need to test concepts, not simply if someone can recite SQL 101. Concepts are portable between different DBMS within days. Trying to teach good concepts can take years. - MrKite, on 10/12/2007, -1/+1Wow, there seems to be a lot of business geniuses posting here. Too bad you're posting here and you're not out on your yacht. lol
- MattL920, on 10/12/2007, -1/+1@jeevesbond: You're right, I misread that in the article :)
My point still stands though, it shouldn't take an expert developer to understand how to use correlated subqueries. - ZergyPoo, on 10/12/2007, -0/+0@Scott...
There are a lot of people who might not able to answer these questions who would be much better candidates than others who could.
It's much better to hire someone who's eager and able to learn all these things than someone who has a bunch of things memorized. - ScottWhigham, on 10/12/2007, -1/+1I totally disagree. As others have commented, the questions are so basic ("What is an index? a Primary Key? NULL?") that, if you don't know answers to these generic questions, you're just writing/designing poorly designed systems. Just because you *think* you don't need to know these questions in your job doesn't make your opinion a correct one.
I also agree with whoever said that these questions were so generic that they could be used/adapted for any system. That's how fundamental the knowledge is... - evilneal, on 10/12/2007, -1/+0I got my first ms-sql developers job a month ago, and to be fair 90% of those questions were asked of me, missing from that is a discussion about cursors and t-sql code fragments to analyze/explain. But decent enough article.
- fatbeaver, on 10/12/2007, -3/+2I think I can be a database admin/developer
- qtuner, on 10/12/2007, -1/+0I would ask the following question.
What is a relation? - AntiMe, on 10/12/2007, -1/+0Triggers are useful in a few cases, particularly when you want to do something like email somebody if some value happens (or some value changes). Can't do that with foreign keys. I've also used them to update complex views implemented as tables (view was too slow, so we implemented static tables that would be recalculated when the base data changed).
- inactive, on 10/12/2007, -1/+0If you have to read some article about what questions to ask a potential hire as a database developer, you have bigger problems on your hands than you probably realize.
- TheSak, on 10/12/2007, -2/+0I suppose for small databases supporting simple applications you can get away with not knowing many of those, but for any kind of enterprise application, you're going to need to know this stuff. Anyone who is planning on moving up the career ladder should know this stuff.
- inactive, on 10/12/2007, -7/+4Nice study guide. Alot of these questions apply to SQL (not only SQL ServeR) in general
- MattL920, on 10/12/2007, -5/+1That was supposed to be a reply to another post
- buddyfarr, on 10/12/2007, -5/+0@airjrdn -
I'm sorry, but that was just plain funny....I don't care who you are.... - ABadInAlbany, on 10/12/2007, -8/+3uhhhh if you don't know to ask these basic questions to begin with, maybe you shouldn't be the person responsible for interviewing someone for a DB job?
- SweetsGreen, on 10/12/2007, -7/+2A better question would be "Have you ever specified JOIN hints in a production database?"
If the answer is yes...then give them the boot.
If you are achieving better performance by specifiying join hints, then there is somthing wrong with your underlying design or indexes.
The optimizer is smarter than you, let it do its job. - MattL920, on 10/12/2007, -6/+1The key phrase there is "years ago".
- Tredici, on 10/12/2007, -7/+0Oops...
- martian, on 10/12/2007, -15/+5How about "why the hell are you using SQL Server?"
- ABadInAlbany, on 10/12/2007, -20/+2weak.
© Digg Inc. 2009
— Content created and posted by Digg users is