THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Denis Gobo

The Sad State Of Programmers Part 1 : The Phone Interview

This is going to be a three part series.

Part 1 The phone interview.

Part 2 The face to face interview.

Part 3 Some tips and observations

 

A while back I posted that we are looking for a SQL/.NET/FoxPro developer. I did this because we had a real hard time finding this person. I am happy to inform you that we did find this person and he will start in two weeks. Interestingly enough we hired the person with the least years of experience (on paper). This person knew more than people with three times his experience in years.

These days when looking for a programmer you have to do phone interviews if you don’t want to waste an incredible amount of time. A phone interview enables you to assess the skill set of a potential employee without wasting time by picking him up, getting a security badge, booking a conference room etc.  A phone interview is also good for the candidate since he/she doesn’t have to travel or dress up to do the interview.  

Some things are difficult to ask over the phone but if the candidate looks (or should that be sounds) good then you can ask those questions when you bring the person in. Some people will prepare for a phone interview by having all their books and notes in front of them. They will ask you to repeat the question and while you do so you can hear them flipping pages frantically. So you might be able to cheat on the phone interview but be assured that if you do not know your stuff that you will fall flat on your face on a face to face interview (no pun intended).

One thing I never understood is the fact that it takes a person one minute to answer a question. You either know or don’t know the question. Keep your answers concise, do not spend 3 minutes explaining to me what the difference is between a clustered and non clustered index.

I had to reword my questions slightly because when I asked a question like “Do you know what the difference is between a clustered index and a non clustered index?”  some people would reply “yes”.  Because of that I changed the question to “Describe what the difference is between a clustered index and a non clustered index?”

Do not shoot yourself in the foot by giving me additional information which is wrong. I asked for the fastest way to empty a table. Almost every single person who knew about truncate added that you cannot rollback a truncate statement. I wrote about that myth a couple of months ago: SQL Myth: Truncate Cannot Be Rolled Back Because It Is Not Logged

I tend to ask between 20 and 40 questions, if I see the candidate’s skill is not good enough I don’t ask everything. Some of the questions are esoteric but I simply ask these questions to get a feel of the overall skill level; it doesn’t matter if they answer these wrong. You can find a list of question here: How Well Do You Interview And Do You Use Wizard Driven Programming?

Here are some interesting answers from the interviews.

Almost every single person answered that an index scan is better than an index seek.

There were several people with SQL Server 2005 experience, these people couldn’t name one single new thing introduced in SQL Server 2005. I asked about windowing functions, DMVs, pivot, apply and more, this was all Greek to them. One person had on her resume that she developed an app in SQL Server 2005. When I asked about her experience she told me she just started to read about SQL Server 2005. This is a big show stopper, sometimes headhunters/recruiters will tell you to just add it to your resume, I wouldn’t do it because it makes you look bad. If the SQL Server 2005 experience is not true what else could be made up? One person had on his resume that he optimized complex stored procedures, when I asked how he did it, he replied that he only selected the rows he needed instead of the whole table. This obviously didn’t answer my question.

 

That is it for the phone interview, part 2 will be up in a day or two.

 

 

Published Sunday, December 02, 2007 3:47 PM by Denis Gobo

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Adam Machanic said:

Great post!  Looking forward to more.

December 2, 2007 5:48 PM
 

Bart Czernicki said:

First, I hate these kind of articles.  Because, while in spirit I agree with a lot of what you have to say...it has the I am "more well read than you" theme.

For example, the "truncate myth".  First, a lot of people say this because the information on a lot of sites is INCORRECT.  How can u hold that against someone?  Basic understanding of the truncate vs. delete is enough for a jr. and even maybe a sr. developer (depending their primary role as a DBA or front-end developer).  Unless your looking for an architect position ur NOT going to find someone that is going to be able to tell u answers to proper myths/answers especially now that someone has to be very well versed in a wide array of developer tools.

A PERFECT example materialized itself in this month's SQL Server magazine in the article by "Itzik Ben-Gan" who is a frequent author.  Here is a direct quote from the article on  read uncommited vs. commited:

"Most of this article's findings are fairly recent-in the past year or so--and my answers to the questions above before those findings were WRONG or INCOMPLETE."

---

A few years ago, I was asked on an interview by a similar personality "Does SQL Server support recursion".  Well SQL Server 2000 doesn't support "true" recursion, but you have recursive triggers (limited by levels) and SQL Server 2005 does with CTEs (it was in beta then).  The funny thing is the answer suprised them because they were expecting a hardy..."No".

December 2, 2007 11:09 PM
 

Denis Gobo said:

Bart,

I really though about it a long time before posting this. I did however try my best to make it as non acerbic as possible.  I did not create a post which listed a bunch question with all the crazy answers I got.

I did not ask about rollback with truncate and don’t consider that as something that will influence my decision to hire this person. I did ask when can you not do a truncate, I expected the answer to be “when you have pk fk relationship”, only 2 or 3 people got that one right. I also did not ask about undocumented procs like the for each table proc (sp_MSforeachtable) or sp_who2.

Take the following question “How can you ensure that only values between 1 and 10 are allowed in a column?”

I got several answers

One person answered that all that should be done at the application level

Several people answered trigger

A couple of people had no answer

A handful of people answered constraint

The ultimate goal of this series is not to say look at all these n00bs but to try to provide some tips about the interview process itself. The 2nd and 3rd part will make that more clear.

Denis

December 3, 2007 7:15 AM
 

andyleonard said:

Denis,

  I like the article and did not interpret your style as acerbic.

  Since you mentioned recruiters, I'm curious how you attracted candidates for this position. Did you use recruiters?

:{> Andy

December 3, 2007 10:53 AM
 

mksql said:

Having been on both sides of that call, I try to follow the concept "It's not as much what you know, as what you can figure out." Phone interviews that test a candidates ability to recite Books Online are not terribly useful, but those that test _understanding_ and research skills are more telling.

Having multiple approaches to an example problem, or being able to articulate a research path to locate unknown answers is a skill I find is in the minority. I find plenty can precisely state single approaches as described in the documentation, but few can describe the path to take when the "common" approach fails.

I am not disagreeing with Denis... many initial interviews are about finding what on a resume is accurate, and what is "marketing".

December 3, 2007 11:31 AM
 

david burnett said:

In fairness to some of these people, I have had headhunters modify the resume I gave to them adding claims that I had experience that I did not have. Clearly, you don't deal with that headhunter again but you only find out they did this the hard way in the middle of the interview.

On Sybase at least through 11.9.2, you could not include Truncate in a transaction so you couldn't do a rollback. Perhaps, some of the people you interviewed came from the Sybase world.

December 3, 2007 1:54 PM
 

Denis Gobo said:

Andy,

yes most of them came through recruiters

December 3, 2007 2:01 PM
 

Hugo Kornelis said:

If I were ever hiring, I wouldn't mind people admitting ignorance. I'd much rather hear an honest "hey I don't know but if it ever comes up, I'l check BOL or use google to find out" than have someone make up an incorrect answer on the spot.

If a day passes by without me starting up Books Online, it's a day in which I didn;t work!

December 3, 2007 2:02 PM
 

Denis Gobo said:

David,

Most of the people had SQL Server experience since version 6/6.5

And like I said, I did not ask if you could rollback a truncate, they gave that additional info  ;-(

December 3, 2007 2:04 PM
 

Denis Gobo said:

mksql,

during the face to face interview I actually have people write T_SQL on a whiteboard. A simple 3 column table with a primary key

December 3, 2007 2:40 PM
 

Denis Gobo said:

Hugo,

I know what you mean, every time I have to create a function I have to look it up

December 3, 2007 2:41 PM
 

Bart Czernicki said:

Denis,

Like I mentioned...I do agree with ur approach.  My point was that there are sometimes people who ask interview questions like the "truncate myth" without understanding that information on the web/blogs has been wrong in a lot of places.  The example I listed I read last week in SQL Server was a perfect example.

However, if you are taking the answers with a grain of salt that is fine.  It is actually interesting because u can tell a lot as an interviewer/interviewee how difficult this person is going to be to work with depending on their answers or questions.  I know I am always trying to avoid the "I am always right" personality

December 3, 2007 4:18 PM
 

dmarkle said:

Denis:

Your experience jibes with what I see when I do interviews.  And I must say that you are right to call out people who believe in these myths -- someone who blindly reads something on a blog and without questioning or understanding it is not a good asset to have on a team, especially if that person takes their knowledge personally.  

Why?  Because sometimes it can be SO HARD to undo the damage that has been done by "experience".  Sometimes, I think you should just hire recent college graduates and teach them yourself instead of hiring "experienced" DBAs.  How many people do you interview honestly believe that every table must have an integer "ID" column as the PK?  That's so much worse than the TRUNCATE myth for me, because the wrong answer can't be disproved in less that 30 seconds.  And then, ask them why.   "uh..., uh because it's faster".  

And I do agree with Bart -- it can be rough when an interviewee asks a question about something like the TRUNCATE myth and doesn't follow up.  That's why, when I'm interviewing, I make a point to interview the interviewer when I'm being quizzed.  When someone asks me a question and checks my answer against something that's wrong, I need to know, because I am going to call them out on it.  If they respond negatively, is that a place I really want to work?

Here's another question for you, to see if you have someone who's really into SQL Server:  What does DBCC DBREPAIR do?  (LOL)  

Answer: Nothing, in Sql Server 2005.   ;-)  

December 4, 2007 7:27 AM
 

Denis Gobo said:

dmarkle ,

What does DBCC PINTABLE doe in SQL server 2005?  :-)

I usually don't ask any DBCC commands since we usually developers only, I don't expect them to know DBCC commands or trace flags

December 4, 2007 10:05 AM
 

Adam Machanic said:

A long time ago I worked with an "architect" who demanded that every table have an IDENTITY primary key.  Reason given: "if you don't, SQL Server will complain."

Personally, I've never seen SQL Server whine, moan, or mutter under its breath due to lack of an IDENTITY column, but apparently this guy had, at some point :-)

December 4, 2007 10:13 AM
 

Denis Gobo said:

>>"if you don't, SQL Server will complain."

yes..if you have duplicate rows you can't delete it from Enterprise Manager because it doesn't know which row to delete.....an identity will 'fix' that   :-}

December 4, 2007 10:18 AM
 

Alexander Kuznetsov said:

Denis,

this is a very interesting post, thanks, but could you please not post any more interview questions? I found some of my favorite ones, and now I need to come up with something else.

December 4, 2007 11:14 AM
 

Kalen Delaney said:

Adam -- When parameter sniffing has my SQL Server use a NC index to access  every row in a huge table, or when I have shrunk my log down to a couple of MB and then do a large SELECT INTO, the harddrive on my laptop makes a nasty sound that I always considered to be my SQL Server whining and complaining ...

(However, it never did that due to lack of an IDENTITY Primary Key.)

:-)

Kalen

December 4, 2007 2:44 PM
 

David Markle said:

Oh thank God Joe Celko hasn't discovered this site yet...

And Denis, the answer to your question is, of course, that DBCC PINTABLE puts your whole table in memory, which is what you'll need if you forgot to put an INT IDENTITY primary key on your table.  But not even that will save you when the time comes to write your queries -- if you don't have an INT IDENTITY column on each table, it's going to be mighty hard to write your queries in the Query Designer -- where will the lines go??!  

OK, enough of that.  Now for a classic that I encountered 2 years ago.  I worked with this DBA/developer that had > 12 years "experience", and I was looking at their code, only to see something like this in a proc called something like (ha) sp_InsertWhatever:

   DECLARE @whateverID INT

   SELECT @whateverID = MAX(whateverID) + 1

   FROM whatever

   INSERT whatever (whateverID, col1, col2 ...)

   SELECT (@whateverID, col1, col2 ...)

Ah, and not even the common courtesy of using a transaction as a "reach around".  I asked this True Champion why they didn't at least use an IDENTITY on the whateverID column:

"Because it's not Best Practice."

I love it.  By the way Kalen, this person had your book.  It was in fantastic condition!

December 4, 2007 10:37 PM
 

Denis Gobo said:

dmarkle,

DBCC PINTABLE on SQl Server 2005 does absolutely nothing, you can run it, nothing happens

December 5, 2007 4:21 AM
 

dmarkle said:

I was being sardonic.  It was a long day at work.

December 5, 2007 6:47 AM
 

Vadivel said:

I second hugo's comment :)

Btw, last year I wrote couple of articles on 'Tips to prepare for interviews' .. at ur lesiure do check out and lemme know your thoughts  http://vadivel.blogspot.com/2006/07/tips-to-prepare-for-interview.html and http://vadivel.blogspot.com/2006/10/tip-to-prepare-for-interview-part-ii.html

Regards

Vadivel

December 5, 2007 1:27 PM
 

Denis Gobo said:

vadivel,

In your 2nd article under In Person add

Dress in business attire  

I will cover that in part 3

December 5, 2007 1:44 PM
 

Vadivel said:

Denis,

Yep thats what I meant by "2. Present yourself with formals.". May be i would change the phrase as u have pointed out. Thx.

December 5, 2007 11:01 PM
 

Paul Nielsen said:

David, Joe Celko has discovered this site, and even commented favorably about my post on Columnar Databases, whcih worried me a bit.

December 7, 2007 2:53 PM
 

Denis Gobo said:

This is part two of a three part series. Part one was about the phone interview , this part is about

December 10, 2007 3:01 PM
 

Geoff said:

Hey Denis,

I interviewed with you, primarily to shake off the interviewing rust. I can't speak for everyone, but asking you to repeat questions was a function of not quite being able to understand you, esp. over the phone. I wouldn't interpret it any other way than that.

December 13, 2007 10:05 AM
 

Denis Gobo said:

Geoff,

This didn't apply to you, there were several people who asked me to repeat the question and I could hear the pages flip in the background.

Denis

December 13, 2007 10:15 AM
 

Geoff said:

Gotcha. No offense was taken originally. I have a thick skin. But glad it worked out for you.

December 13, 2007 1:44 PM
 

Ben Amada said:

Denis,

Nice post.  Regarding the "SQL Server 2005" experience, I think your expectations are a little unfair.  I'm sure there are lots of developers whose first experience with SQL Server was with SQL 2005 or at least some of their more recent projects have been with SQL 2005.  For these developers (specifically ones that never used SQL 2000), what do you expect them to put on their resume?  SQL 2000?  That would definitely not be accurate.  Because these developers haven't used any of new functionality that came with SQL 2005, they can't list SQL Server 2005 on their resume?  I can't think of anything that would need to be done in a database to support an application that has to be done using the new functionality introduced in SQL 2005.

This same argument can be applied to other technologies, such as MS Office.  If a person has used Office 2000, 2002, 2003 and most recently Office 2007, but has never used a feature that was introduced after Office 2000, does that mean a person can only list Office 2000 on their resume?

Anyhow, just something I wanted to throw out there.

Thanks,

Ben

December 22, 2007 9:57 AM
 

Denis Gobo said:

Hi Ben

All of the people we interviewed had at least SQL 2000, most of them had also SQL 7, some of them had also SQL 6x and one or two had SQL 4X

When these people list SQL 2005 and then can't give me one new feature that they like besides the CLR then I find that a little strange.

If a person started with SQL 2005 then they would not have a minimum of 4 years experience in sql server, however if that person had other RDBMS experience I would definitely set up an interview.

>>If a person has used Office 2000, 2002, 2003 and most recently Office 2007, but has never used a feature that was introduced after Office 2000, does that mean a person can only list Office 2000 on their resume?

The problem is that the person can't answer the questions about the new versions and would look like he did not use all the newer Office versions. That said with Office 2007 it is pretty hard not to use the Ribbon

December 22, 2007 10:12 AM
 

Denis Gobo said:

The Sad State Of Programmers Part 3 : General Tips This is the final part of this series. You can find

December 27, 2007 12:29 PM
 

Jon Nolan said:

>>One thing I never understood is the fact that it takes a person one minute to answer a question. You either know or don’t know the question.

I'm usually nervous during an interview, so I don't do very well in general, but in particular it almost always takes me a minute to answer questions, even when I know the answers.

December 30, 2007 12:49 PM
 

mos said:

I'm going to give a phone interview tomorrow to someone who will be doing some SQL and some C# work, and I stumbled upon this page looking for some SQL question tips.  But having read it all, I'm wondering why people look down their noses at naming something "sp_Whatever" (I am not a SQL programmer, but our DBA does name things that way).

February 20, 2008 6:25 PM
 

Denis Gobo said:

After my The Sad State Of Programmers Part 1 : The Phone Interview series I got an email from a person.

May 16, 2008 12:23 PM
 

TC@Kin said:

Thanks for your post!

Actually I agreed with the opinion came from 'Bart Czernicki'.

Correct and complete is required.

If you are in hurry, ask to them stop.

October 14, 2008 4:38 AM
 

nasherooy said:

nice blog brother

May 25, 2010 12:43 AM

Leave a Comment

(required) 
(required) 
Submit

About Denis Gobo

I was born in Croatia in 1970, when I was one I moved to Amsterdam (and yes Ajax is THE team in Holland) and finally in 1993 I came to the US. I have lived in New York City for a bunch of years and currently live in Princeton, New Jersey with my wife and 3 kids. I work for Dow Jones as a Database architect in the indexes department, one drawback: since our data goes back all the way to May 1896 I cannot use smalldates ;-( I have been working with SQL server since version 6.5 and compared to all the other bloggers here I am a n00b. Some of you might know me from http://sqlservercode.blogspot.com/ or even from some of the newsgroups where I go by the name Denis the SQL Menace If you are a Tek-Tips user then you might know me by the name SQLDenis, I am one of the guys answering SQL Questions in the SQL Programming forum.

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement