12 ms·
An open letter to anyone with “SQL Server” on their resume
- MindTwister 15y agoThat page is horribly garbled in Chrome 17: http://i.imgur.com/xsBet.png http://i.imgur.com/xsBet.png
- gazrogers 15y agoLooks ok for me - Chrome 17.0.963.46 m, Windows XP?
- omarqureshi 15y agoconcur - looking a little garbled, but not that bad 17.0.963.46 Linux.
- acidblue 15y agoRenders fine on Chrome 17.0.963.46 on OS X. Though, I do see an exception being thrown in some javascript on the page.
- pedrolll 15y agoLooking ok on 17/OSX.
- Craiggybear 15y agoSeriously. 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 15y agoI'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.
- Craiggybear 15y agoAaaahhhhh ... rails developers. I take your point. As to CHAR vs VARCHAR -- well, is it fixed length or constantly changing? The clue is in the name. And CHAR is usually up to 50% faster on overhead and VARCHAR uses padding which can be a huge waste of space. They should just know this. Then, SQL Joins are plain English and should be easily visualised in the abstract (it does help if you can see the data in front of you though, I can't deny). Date vs Time is something I am finding confuses lots of people. Precision as well.
- Skalman 15y agoRegarding CHAR/VARCHAR: At least in MySQL VARCHAR only has one byte of padding, while CHAR is a huge waste of space if you don't use mostly full-length strings. Edit: http://dev.mysql.com/doc/refman/5.6/en/char.html http://dev.mysql.com/doc/refman/5.6/en/char.html
- Erwin 15y agoWell, that's database dependent -- for Postgres there's no real performance difference: http://wiki.postgresql.org/wiki/FAQ#What_is_the_difference_between_the_various_character_types.3F http://wiki.postgresql.org/wiki/FAQ#What_is_the_difference_b... It's CHAR that pads with spaces, not VARCHAR.
- meric 15y agoI used to write lots of SQL a couple of years back in university, I even think I was quite good at it because I scored near the top of the class, but since that database class I haven't written many more lines of SQL. These days the ORM takes care of a lot of use cases... I think I still know what a left/right join but I am no longer confident in my knowledge. I think a lot of people my age are similar. We aren't 30 year olds who have had 5 years of actual SQL experience before ORMs got popular. We've had maybe 1 year or so and then after that its all just ORM.
- richardlblair 15y agoThis 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.
- ams6110 15y agoMy peeve in any flavor of database is people who bastardize some other datatype when a more appropriate one is available, e.g. storing dates as epoch offsets in an INT or BIGINT column rather than just using a DATETIME data type.
- jcromartie 15y agoI've found several columns using floating point to store monetary amounts in the system I'm working on. It makes for some real problems down the line.
- shrikant 15y agoI 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 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?!
- mgkimsal 15y ago1) yes. but not just sql server - mysql as well. probably postgresql, oracle and others too. 2) that depends on what you want to do. if you want to get more work doing sql server work, put it on the resume. there's things I've taken off my resume simply because I don't want to do work involving that tech anymore, not because I'm not capable or don't want people to know. In person, I'll tell them if they ask. re: #1 - people lie on their resumes all the time. people also exaggerate the truth a lot. lastly, some people really do honestly think they "know" a technology if the icon is on their desktop and they've clicked it a few times while working at company X. they may not really even know that they don't know anything substantial about tech X.
- dspillett 15y ago> 1) Are there really people who claim SQL Server 'expertise' and then not know things like the difference between DELETE and TRUNCATE? Yes, but this isn't specifically a SQL Server thing. People will often inflate their skills ridiculously on their CV, sometimes just telling bare faced lies. I once had to deal with an idiot who despite his CV listing him as knowing Javascript to an "advanced" level and jQuery specifically at an "intermediate" level, did not understand what $(<function>); did and was no wiser when we took out all the shortcuts to produce jQuery(document).ready(<function>); I wish I was jesting or exaggerating here. You should have seen the vacant look on his face when we tried to explain a very simple closure. Advanced indeed... > 2) If above is true, then am I short-selling myself by not putting SQL Server in my resume?! Possibly. If you understand all the basics covered in that document and have actually used them (rather than just having read about them) then yes. But be very careful to stay aware that knowledge does not necessarily imply experience (nor vice versa) - chose your wording carefully to put yourself in the best light you can without bending the truth (or seeming like you are trying to) implausibly. Claiming expertise is another step forward: if you say you are an expert that sets the level of expectation very high - you will be expected to have an excellent level of both practical and theoretical knowledge (the how and the why) and a lot of experience to back this up. If you ever claim to be an expert be quite explicit what you are an expert in. If your expertise is in the DBA side of things or from a programmers perspective (to give two generic examples) say so - databases cover a large area of subject matter and you can command a high price if you are truly an expert in the lot! Basically out on your CV the level that you would be comfortable being asked questions about. If you have some experience or knowledge of SQL Server then by all means say so but try not to exaggerate. If you have experience with SQL based RDBMSs other than SQL server then put that instead (as the basics and some of the not-so-basics are very much transferable) but don't claim SQL Server specific experience unless that is what you actually have.
- tocomment 15y agoI'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.
- TomGullen 15y agoGreat read thanks, love HN, I'm a clot who didn't realise what SP really meant until now.
- stoolpigeon 15y agoOracle - 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.
- sjwright 15y agoNULL shouldn't equal NULL. If two customers have a phone number of NULL, that doesn't mean they have the same phone number.
- stoolpigeon 15y agoPrecisely my point. Nothing equals null, but SQL server allows queries that use '= NULL' in them.
- jrockway 15y agoBut that doesn't prevent = NULL from parsing into an AST containing the "IS NULL" opcode. It's syntax sugar.
- dspillett 15y agoOnly if you explicitly turn the ANSI_NULLs option off, IIRC more conformant behaviour has been the default since at least version 7. Of course it does still have irritations like trailing spaces not being considered significant in string comparisons (to pluck a random example from the air) but so do other databases, especially those that have been around many years so have their on legacy to be backwardly compatible with lest the users revolt, including Oracle (empty strings being considered NULL for instance).
- cafard 15y agoSorry, I don't quite get the first point. Do you mean that you prefer empty strings to be treated as NULL?
- stoolpigeon 15y ago
- lrobb 15y agoThose 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.
- matwood 15y agoI think some, such as knowing all of the date/time types and their precision really depends on what kind of work you're doing. IMHO, knowing there are differences should be enough. Documentation is for looking up exactly how precise each datatype might be, and in general going to the documentation for specifics is preferred since it can and does change.
- ap22213 15y agoYes - 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.
- adamlindsay 15y agoThis 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 15y agoWhich is sad for the few of us who actually implemented network protocols :)
- DenisM 15y agoSo 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.
- DenisM 15y agoThis 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.