Monday, December 10, 2007

The Sad State Of Programmers Part 2 : The In Person Interview

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

The point of the in person interview is to see if the person will fit in with the rest of the people in the organization. This is where you get asked such wonderful questions like:
How many gas stations are there in the state of New Jersey?
How would you move Mount Fuji?

These questions are usually asked by managers to see how you handle pressure. There is usually no real answer to these questions, you have to logically come up with an answer and solve this puzzle. For example there are 8 million people in New Jersey, these people have 6 million cars. A gas station gets between 3 and 4 cars per minute; this adds up to 4320 cars per day. You would need about 2000 gas stations to serve all these people. All these numbers could be completely wrong; the point is can you logically figure out the steps to ‘solve’ this problem. It doesn’t matter how brilliant you are, if the people that interview you feel that you are a mismatch personality wise you won’t get hired.

Some observations about the process
Dress in business attire

One person dressed very inappropriate, in fact when picking him up at the security desk we thought he was a delivery person. This is not a way to start the face to face interview. I will get into more detail in part 3 of what to wear and not to wear.

You are your own worst enemy
A person was given source code after the phone interview to study. When asked about the code during the face to face interview she mentioned that she just glanced over the code and did not really look at it. Why would you say something like that if you want to get hired? Now, would you consider hiring this person?

Be proper
Do not grimace like you have a squirrel chewing on your big toe while thinking about an answer. Do not chew on your glasses either while thinking about the answer. When you answer the question wrong, the interviewer gives the correct answer don’t say that is what I meant. If that is what you meant then you should have said so, there are of course exceptions but I am talking about real black and white scenarios.

Bring good code
When you bring source code make sure it is the best code you could possible bring. One person was asked about best practices and error handling; he seemed to know this pretty good. Then he offered to show his code, we noticed that he didn’t have any of these best practices in his code. His proc was called sp_ProcName, error handling was wrong and a bunch of other things. In this case it would have been better if the person did not volunteer to show the code.

And now the questions.

I decided to ask every person these exact questions in the face to face interview; depending on how these were answered I would ask a bunch more questions. There are a couple of questions which you couldn’t answer wrong and I did not count them as toward the total score. Here is a list of some of the questions (Alex don’t get mad), I will comment on these questions and give the answers.

How many bytes can you fit in a row, do you know why
How do you enforce that only values between 1 and 10 are allowed in a column
How to check for a valid date if it is passed in as a string
Can you name the 4 isolation levels in SQL Server 2000
How would you select all rows where the date is 20061127
Name some differences between isnull and coalesce
If you create a local temp table and then call a proc is the temp table available inside the proc
What is a SQL injection
Update trigger to capture changed information
Which naming conventions did you use?
Name some best practices which you implemented
Select 3/2
Create table with PK symbol 10 characters, price 8 digit precision
Add clustered index to that table
What does set xact_abort on
Select * from table where ID <> 1
Favorite SQL Server book
How do you keep your SQL skills up to date?

How many bytes can you fit in a row, do you know why?
I am looking for one of these answers
8060 bytes
Same as a page
8K + overflow column/text columns
If a person does not know the answer to this question then that is ok.

How do you enforce that only values between 1 and 10 are allowed in a column?
I am looking for check constraint as the answer. A bunch of people didn’t answer anything, some answered trigger and one said you should never check in the DB but in the application itself.

How to check for a valid date if it is passed in as a string?
The answer I am looking for is ISDATE() Some people knew this answer, some people answered “convert to datetime and then check for the error” one person said “parse the string”. A bunch of people didn’t answer anything at all

Can you name the 4 isolation levels in SQL Server 2000?
Another nice to have question, if you don’t know it then is not the end of the world. I will also ask the default transaction level

How would you select all rows where the date is 20061127?
I will draw a table on the board with values like these
2007-12-06 15:36:10.293

2007-12-07 00:00:00.000
2007-12-07 15:36:10.293
2007-12-07 15:36:10.293

2007-12-08 00:00:00.000

I am looking for the 3 rows which start with 2007-12-07
The answer I want is this

WHERE date >= ‘20061127’
AND date < ‘20061128’ I don’t want between because it will grab the 2007-12-08 value also, I don’t want convert because that causes an index scan. Less than half the people get the correct answer. Some stuff to read: Do You Know How Between Works With Dates?

How Are Dates Stored In SQL Server?

The ultimate guide to the datetime datatypes

Name some differences between ISNULL and COALESCE
The main answer I am looking for is that ISNULL can only use 2 values while COALESCE can use a lot more. If the person knows other differences then that is also good. I was surprised at the number of people who never heard of COALESCE. Below is some code which shows the differences

There are three major differences besides being ANSI or not between COALESCE and ISNULL
1) COALESCE correctly promotes its arguments to the highest data type in the expression list, ISNULL does not
2) ISNULL can only work with 2 values while COALESCE can take a lot more
3) The alternate value takes the length of the first vale with ISNULL, with COALESCE this doesn't happen

Let's get started, run the following blocks of code

The result is 7, integer math


The result is 7.5, which is correct


You will see that the result is not the same ISNULL does integer math while COALESCE does not

COALESCE correctly promotes its arguments to the highest data type in the expression list.
ISNULL just looks at the first datatype, which is an integer (15) and makes everything an int
COALESCE looks at 2.00 and 15 and then promotes the integer to decimal

Another example is returning the first non null value, ISNULL can only take 2 values while COALESCE can take a whole lot more
Here we have 4 variables and all except for one are null

SELECT @Var4 = 'ABC'

--This will return ABC
SELECT COALESCE(@Var1,@Var2,@Var3,@Var4)

Last example.
ISNULL returns NOT while COALESCE returns Not There.

SELECT ISNULL(@v,'Not There')

The alternate value takes the length of the first value with ISNULL, with COALESCE this doesn't happen

If you create a local temp table and then call a proc is the temp table available inside the proc?
The answer is yes and the code is below

--create proc



--create our temp table
CREATE TABLE #temp (id int)


--exec proc
EXEC TestProc

What is SQL injection?
People either knew or did not know about SQL injection, the ones who knew also knew what to do to prevent it. A little less than half the people interviewed knew what it was.

Some stuff to read:
SQL injection cheat sheet.

The Curse and Blessings of Dynamic SQL

Update trigger to capture changed information
In drew two tables on the whiteboard and explained to the people that I wanted to move data into a history table only when the value in a certain column changed. I was looking for several things
If the person knew about inserted and deleted tables
If the person would code the trigger for multi row statements and not assign the value to a variable
If the person knew about IF UPDATE(Column) and that this was true even if the table was updated with the same value
If the person would join inserted and deleted to make sure no row would be inserted if the value didn’t change

Some stuff to read:
Fun With SQL server Update Triggers

What naming conventions did you use?
Here I wanted to hear if the person had any standards, I would also ask for an example of a proc name hoping sp_ProcName wouldn’t be answered

Some stuff to read:
The ISO organization has a document on their site. The one that deals with naming conventions is 11179-5 The link will point to a zip file which has a pdf file in it. The TOC of this pdf file is below Contents Foreword 1 Scope 2 Normative references 3 Terms and definitions 4 Data Identifiers within a registry 5 Identification 6 Names 6.1 Names in a registry 6.2 Naming conventions 7 Development of naming conventions 7.1 Introduction 7.2 Scope principle 7.3 Authority principle 7.4 Semantic principle 7.5 Syntactic principle 7.6 Lexical principle 7.7 Uniqueness principle Annex A (informative) Example naming conventions for names within an MDR registry Annex B (informative) Example naming conventions for Asian languages

What best practices did you implement?
There is a whole range of possible answers here and I won’t get into detail.

Select 3/2
When I wrote Select 3/2 on the board and ask what this would return several people looked at me if I was crazy. The answer is of course 1 because of integer math. I ask this question because we run reports which deal with calculation with integers. Take a look at this code to see what you can do to ‘fix’ the issue

Run this
--Integer math
SELECT @Val1 =3, @val2 =2
SELECT @Val1/@Val2

It returns 1

Now run this
SELECT @Val1 =3, @val2 =2

SELECT @Val1/(@Val2*1.0)


Both of those return 1.50000000000000

So what does @val2*1.0 do? well run this

SELECT @Val1 =3, @val2 =2
SELECT CAST(SQL_VARIANT_PROPERTY(@val2*1.0,'BaseType') AS VARCHAR(20)) + '(' +
CAST(SQL_VARIANT_PROPERTY(@val2*1.0,'Precision') AS VARCHAR(10)) + ',' +
CAST(SQL_VARIANT_PROPERTY(@val2*1.0,'Scale') AS VARCHAR(10)) + ')'

As you can see it is numeric(13,1)

What is the greatest value that Decimal(6,5) can hold? A lot of people answered 999999.99999 which is wrong of course. The total number of numbers is 6 and 5 of those are after the comma. So the answer is 9.99999. Run this to try it out for yourself.

Create table with PK symbol 10 characters, price 8 digit precision
I would tell people to create a table with 2 columns
1 with a column named symbol variable character 10 in length, it would also be a primary key
Price which was decimal and can hold a number as big as 999999.99999999
They had to do this on the whiteboard in T-SQL (create table…..)
Most people got the PK syntax wrong; some people got the decimal wrong. The reason I am asking this question is because we can’t go on a production machine with Enterprise Manager and start clicking. You might not have permissions to make changes, you need to supply a script which other people might run.

Add clustered index to that table
My next question would be to add a clustered index to that table. The correct answer would be you can’t since the table has a primary key which is a clustered index by default

What does set xact_abort on do
Only one person answered this question correctly, this was another nice to know question. I did explain to people why you would use this, sometimes you cannot trap the error and this statement will enable you to rollback everything up until that point.

Some stuff to read:
Implementing Error Handling with Stored Procedures

Error Handling in SQL Server – a Background.

Select * from table where ID <> 1
I would draw a table with three rows, the values being 1, 2 and null. Then I would ask what would be returned after running this query

SELECT * FROM #temp WHERE id <> 1

A lot of people chocked on this one, the answer is 2 of course, null will not be returned. Test it out for yourself

CREATE TABLE #temp (id int)
INSERT #temp VALUES(null)

SELECT * FROM #temp WHERE id <> 1

Some stuff to read:
NULL trouble In SQL Server Land

NULL - The database's black hole

The logic of three-valued logic

Dr. Unknown, or how I learned to stop worrying and love the NULL

What if null if null is null null null is null?

Favorite SQL Server book
Here something bizarre happened; there were several people who did not have a SQL Server book at all. I did not understand this; how do you not have a SQL server books as a developer? A bunch of people listed Ken Henderson’s Guru book, some of them listed Inside SQL Server and one person answered SQL Server 2005 unleashed (I have the 2000 version, I should check this one out). In part three I will give you a list of my favorite books.

How do you keep your SQL skills up to date?
I am looking for websites, books, blogs, conferences, webinars, podcasts etc. Some people answered Books On Line. One person answered certification (I will address certification and my dislike of them in part 3). I was surprised by the difficulty that people had in answering this question. SQL Server Central was a popular website as well as DevX and MSDN. Nobody answered podcast at all. I would ask people if they played around with the latest CTP of SQL Server 2008, most of them were not aware that this was available to the general public. I did interview a bunch of SQL Server authors and I asked them what they did or would do to master SQL. You can read those interviews by clicking on the links below

Louis Davidson
Itzik Ben-Gan
Ken Henderson
Adam Machanic
Kalen Delaney

That was it fort part two, I originally wanted to put more content here but I was afraid it would become too long, I moved some of that stuff to part three.


Nick said...

Regarding the "Be Proper" point, things like grimacing and chewing on one's glasses are usually nervous habits, not really things people consciously do. Are you saying you wouldn't hire someone (for a programming job) based on the fact that they had a nervous habit? Guess I'll never end up working for you, I have dozens of those.

Oh, you might also want to double check your arithmetic in your solution to the gas station problem. You also left out a key consideration, how often people have to stop for gas (its not once a day). So your numbers may or may not be accurate, but you failed to logically figure out the steps to solve it.

And now that I've shown my personality to be a smartass, I'll probably really never end getting hired by you.

Anonymous said...

Nick, that's why I was going to say :-)

no seriously.. the real sad state of programmers is that you are not testing anything substantial. I showed your interview questions to a number of workmates of mine; including someone with 20+ years experience, someone who has been to the world finals for the program comps, a platform developer for Eclipse and 2 PhD candidates. Your interview would discount all of them, and believe me, some of them are really good. You are testing if some kid straight out of college got to do his DB course in 4th year using SQL Server.... and if so, congrats, he got the job.

Now, if your company needs a SQL Server expert to only ever be a SQL Server expert, then your interview is fine... but if you are hiring employees for the long run, you may wish to revisit your hiring practices.

Anonymous said...

Yes, that's quite a lot of implementation-specific questioning. Goodbye anyone who's 'only' used Oracle, MySQL, Apache Derby, HSQLDB, etc.

Sheesh said...

The Sad State of Programmers is that they have to subject themselves to the dreaded "tech" interview with arrogant know-it-alls who have no experience performing job interviews (look up some of the numerous books on Amazon about the considerable skills required to design/conduct a valid job interview) and are only seeking to bolster their self esteem by asking esoteric questions like these. This is a pernicious trend in our industry, fostered by Dilbert-managers who think the server room cone-heads have a role in the interviewing process. I'd rather subject my candidates to Brainbench testing (ugh!!) than insecure I-Know-More-Than-You-Do mono-syllabic uttering coffee-stained tie wearing in-house geeks. Sheesh !!!

SQL said...


We actually are smartasses ourselves and are always looking for more....
Look I tend to chew on pens, however when I go to an interview I make sure I do not do that, you never know what the pperson who interviews will think about that

As for the gas station you are right about that, we have to also take into account other factors like how many hybrid cars are there, how many cars from other states pass through every day and such. I do agree that those are bs questions and we do not ask those, I only gave them as an example

SQL said...

@Anonymous #1, yes it is for a SQL server position

SQL said...

@Anonymous #2,

We are looking for a SQL Server position. We have 800+ IT people and plenty of Oracle, MySQL and other RMDBS talent

SQL said...

@sheesh, I agree with you and that is why we do not ask those bs questions, I only gave them as an example. The questions I have in this post should be easy to answer by anyone with 5 years of real SQl Server experience

Ex-Veep said...

I've been a hiring manager for a long time. And I've found that while asking someone many inane details about something does tell me if that person knows those inane somethings, it doesn't tell me how well that person can solve problems, how well that person will do on a team, how well that person can teach others, how well that person handles pressure, how well that person adapts to different roles, etc.

In many companies of all sizes, not just large organizations, I've found that many times the least important parts of the hire are those inane details that you seem to focus on so much.

So there is a little voice that says to me "this particular author may not have good skills other than a narrow band of technical knowledge."

Perhaps that narrow band of knowledge is the most important thing in a new hire if that person is going to replace you. But if they are not, I would suggest a much different approach in hiring people.

SQL said...


The people we interviewed would see at least 4 different people. I only focused on the SQL skills in this post

drbob said...

Ex-Veep - agree whole heartedly!!! i cant believe that "programmers" are not tested on problem solving skills vs particular technologies.

Ex-Veep said...

sql: Interviewing is tough work and like most people processes, more of an art than a science. I find what you are doing here on this blog something that I would value highly as a hiring manager. You are putting yourself in a position to learn at the same time teaching others about some things they might want to ask candidates about SQL Server. These qualities are key in any long-term employee.

Without a clear definition of the position being staffed and the overall hiring process beyond your individual role, it is difficult to make a good call from the outside on the relevance of the detailed SQL Server questions you seem to focus on.

If the person is supposed to be the "what is the SQL to do X, Y, and Z" maybe the focus of your questions makes sense.

However, if the person has a larger role, say "Design/build a high-performance storage system for our content for Product P" then there are different sorts of questions that might be the focus instead.

Either way, my regards for the work you are doing with your blog.