
An open letter to anyone with “SQL Server” on their resume - yread
http://pulse.sqlserverpedia.com/blog/an-open-letter-to-anyone-with-sql-server-on-their-resume/
======
lrobb
Those are mostly valid points/questions... I think some, such as knowing all
of the date/time types and their precision really depends on _what kind of
work_ you're doing.

I've noticed a big difference in interviews between software companies vs.
internal IT departments. IT departments tend to favor how much _product_
knowledge you have. So they think a senior person should know what's new in
sql-server 2005 vs 2000... or be able to rattle off the differences between
all of the various ways to store date/time.

Software companies, on the other hand, care more about how you think and
design things, and what you've built. Design an algorithm to do "X"... Make
"X" scale... etc... I saw you built "X"... How did you do it?

I put down that I had used C# on a resume... My first experience with it was
writing a server that monitored a directory for alerts, then did some
processing on the alerts, and routed them to various other 3rd party boxes...
I used the file notification, threadpool, and http client libs, wpf... I
subsequently used it for some Project Euler problems.

Do I "know" C#? Well... After a couple of interviews full of questions such as
"explain what a delegate is... what a mutable class is... explain IOC..." I
would have to say no, I don't really know C#.

That hasn't kept me from using it to bring in hundreds of thousands in
revenue.

~~~
ap22213
Yes - good insight.

I have been wondering about this too. For my 15 years, I've only ever worked
for software companies doing new product development. So, there's a disconnect
when I'm talking to people who come from IT backgrounds. Developing new
products requires different skills, and knowing intimate details of specific
tools isn't as useful as knowing the full capabilities of what that tool can
do.

The worst part of my background, and for these types of interviews, is that I
typically switch stacks every couple years. Generally, every time I start a
project, I have to re-evaluate the stack. And, choosing one depends on so many
variables.

In the past I've spent spent probably 50+ months killing it on SQL Server, but
sadly all those details have been wiped from my working memory, because I
haven't touched it in 12 months. But, that doesn't mean I'm not effective. It
just takes me a week to re-engage and get effective. But, there's never been a
job where I didn't become one of the top performers in just a few weeks.

My brain just works differently.

~~~
georgieporgie
_sadly all those details have been wiped from my working memory, because I
haven't touched it in 12 months._

You may not be able to interview on it well, but I'd bet that a large part of
what you learned is still there, dormant.

I've always been surprised that after a year or more of not using a particular
technology, if I come back to it, it's completely foreign to me. But within a
few hours, things are coming more naturally, and within a couple of weeks I'm
nearly as good as I was when I left off.

------
shrikant
I would definitely NOT put any level of SQL Server of my resume, but I'm
actually pretty comfortable with writing/optimising queries, stored procs and
cursors, and some very simple administrative tasks (as a PM, day to day tasks
don't necessarily involve dealing with SQL Server all the time - if they did,
then something's badly wrong somewhere...)

I hope this doesn't sound like tooting my own horn, but the lead-up is to
this: there's a link in there that should be a submission by itself:
<http://www.midnightdba.com/DBARant/?p=443>

That interview experience is horrifying.

I've done only a couple of interviews, and they've been on the business side
of things, so could someone shed some light on the following:

1) Are there really people who claim SQL Server 'expertise' and then not know
things like the difference between _DELETE_ and _TRUNCATE_?

2) If above is true, then am I short-selling myself by not putting SQL Server
in my resume?!

~~~
arethuza
From what I've seen of applicant CVs recently it is now traditional to include
a page made up of nothing but a long list of acronyms - presumably to ensure
as many hits as possible from recruiter searches.

The inclusion of items in this list is often "acronyms I can spell" or
"software I have been in the same building as".

I don't know if recruiters actually encourage this approach - it wouldn't
surprise me if they did.

~~~
eftpotrm
They seem to, unfortunately.

I know MS SQL Server a little better (ahem) than the individuals who inspired
this post and have years of use and multiple versions of it on my CV. Yet I
was still asked to specify that it included stored procedures and UDFs.

At a former job we could reject 80-90% of candidates for a heavy SQL Server +
VB6 position on the grounds they couldn't write a SELECT with an INNER JOIN in
it. But really, in all honesty, if I interviewed you and found you weren't
properly familiar with stored procedures and UDFs, I wouldn't let you near my
database. If you don't know them why should I expect you understand (say)
nulls, join types, collations, locking, avoiding RBAR, use of tally
tables..... Come for a trainee post, sure, but nothing that assumes
experience.

~~~
matwood
_At a former job we could reject 80-90% of candidates for a heavy SQL Server +
VB6 position on the grounds they couldn't write a SELECT with an INNER JOIN in
it._

It is scary. I interview people for MSSQL positions and have seen way too many
'expert MSSQL' people who can't write a simple inner join much less anything
with some sort of outer join.

IMHO, if someone is going to put MSSQL server on their resume they also better
be familiar with MSAS, SSIS, DTS, etc... Even if they don't know details they
better know that they exists and what they are used for.

BTW, UDFs are great in theory in MSSQL but horrible in practice unless
constructed just right. Scalar UDFs will lock in the query into a single
threaded mode and destroy performance. So only use table value UDFs without
return clauses :)

~~~
shrikant
_> IMHO, if someone is going to put MSSQL server on their resume they also
better be familiar with MSAS, SSIS, DTS, etc... Even if they don't know
details they better know that they exists and what they are used for._

Strongly agree with this. "MS SQL Server" is rather specific (and versions
even more so!), so if someone has just created a simple CRUD app using VB/ASP
and SQL Server (the canonical Indian examples being "Library Information
System" or "Student Performance Management System"), the correct thing to do
would be to state that clearly.

It is entirely possible that the above 'projects' were indeed heavily reliant
on SQL Server-specific features (and not just Transact-SQL quirks), but
personal experience has so far not backed that up.

As a result, claiming to be an "MS SQL Server" 'expert' because you've
happened to run queries in SQL Server Management Studio (or used some variant
of _PreparedStament.executeQuery()_ ) : totally dishonest.

------
tocomment
I've used SQL server for years and am completely comfortable with it, but for
the past year I've been using MySQL and I think it's kind of overwritten
anything I had memorized about SQL server.

So I would fail this interview.

------
adamlindsay
This reminds me when I use to see a ton of resumes which had "TCP/IP, NetBeui
and IPX/SPX" listed on them. Of course these were the 3 checkboxes in the
Windows control panel. I am sorry but clicking a checkbox does not denote
experience with a particular technology. At first I wasn't allowed to reject
them based on just that, after a while it was obvious that anyone that did
that usually weren't worth speaking to. We eventually taught HR to not even
pass those resumes along for us to review. It really reduced the number we had
to look when interviewing for a position.

~~~
groby_b
Which is sad for the few of us who actually implemented network protocols :)

------
DenisM
This thread is full of people who claim that if you don't know "my favorite
facet of SQL Server, chosen merely because I had experience with it", you
don't know SQL Server.

This is probably just as sad as people who know nothing.

------
DenisM
So I'm a bit of an expert in SQL Server and in my not so humble opinion there
is one question that is the most telling when it comes to SQL Server
expertise:

 _What is a join, what are the different algorithms to implement a join, and
when is each one suitable or not suitable._

That's it. Someone who answers this question completely can be trusted to
learn the rest of the nitty-gritty from the docs, and someone who can't answer
it will most certainly screw up your product by implementing a join manually
by using a cursor.

------
MindTwister
That page is horribly garbled in Chrome 17: <http://i.imgur.com/xsBet.png>

~~~
gazrogers
Looks ok for me - Chrome 17.0.963.46 m, Windows XP?

------
stoolpigeon
Oracle - in a number of situations is most certainly 'better'. I can think of
3 things that prove this to be so, " = NULL", RAC and running an OS other than
MS Windows on your server.

~~~
cafard
Sorry, I don't quite get the first point. Do you mean that you prefer empty
strings to be treated as NULL?

~~~
stoolpigeon
MS SQL Server allows statements that include '= NULL' in them. Like, 'SELECT *
from foo WHERE foo_id = NULL'. One cannot do this in Oracle. This, in my
opinion, indicates that Oracle is a better RDBMS.

~~~
yread
I wouldn't argue for a "better" RDBMS with such a small silly feature.
Obviously SQL Server is meant for developers (not DBAs) who are used to
writing myCSVar = null. Besides you can turn it back on with SET ANSI_NULLS
ON. Oracle also has a plenty of features which are not compatible with the
standard (and which can't even be turned off)

'' (empty string) being the same thing as null is really neat though!

~~~
stoolpigeon
That's just a pet peeve. The other two are bigger. But really it just irked me
that he felt it necessary to add that Oracle wasn't better than MS SQL Server.
There are cases where it most definitely is better. There may be cases where
MS SQL Server is better (probably especially if one is running an all MS
stack) but having worked as a full time DBA with both I know where I prefer to
work. Of course I'm not a fan of windows either - so some of my preference for
Oracle and PostgreSQL come from the fact that I get to manage them in my
preferred environment.

------
TomGullen
Great read thanks, love HN, I'm a clot who didn't realise what SP really meant
until now.

------
Craiggybear
Seriously. Data types -- surely anyone who has used any SQL database knows
their internal data types? Although, true, I have seen a few odd table schemas
in my time. Mainly in SQL Server databases it has to be said.

~~~
meepmorp
I've interviewed developers with (claimed) years of database experience who
couldn't articulate the difference between char and varchar.

Another thing I've noticed more recently - rails developers who know almost
nothing about how the database works. Like they might barely be able to write
a inner join among 3 tables; left/right joins flummox them entirely. This is
by no means universal, but I've encountered it several times in the last year,
enough to be a trend in my mind.

~~~
richardlblair
This makes sense. The models in rails do all the heavy lifting. Unfortunately
all too often the developers aren't aware of the abuse they are putting the DB
through.

Personally I use Django. When it comes time for me to perform a query that
might require multiple inner joins, a group by, and aggregates I will often
write the query by hand. This allows me to figure out the requirements of the
query. From there I figure out how to accomplish that with the ORM.

I think more people should take this approach. It would help people understand
what it is they are doing with the database.

EDIT: That being said, having an ORM do exactly what you want can be like
pulling teeth sometimes. I must say, I'm not fully sold on the ORM.

~~~
jacques_chester
The description I give is that rails programmers think of databases as files
with a funny accent.

The classic CF in rails is a form that ultimately deals with > 1 table. Multi-
table forms are a pain for everyone, but with a bit of database juju you could
disguise the complexity with, say, an updateable view.

