5 ms·

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 version

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 15y ago
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 :)
- eftpotrm 15y ago
  Oh, yeah, UDFs are something that I want a dev to know about but I also want them to understand why most of the time they shouldn't use them ;-) Triggers, too. I would say there are some positive cases for using scalar UDFs in live-run queries, but certainly not where the UDF's result is in any way dependent on the value of a field in the dataset. There lies the path to horrendous performance problems....
- shrikant 15y ago
  > 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.

matwood 15y ago

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 :)

eftpotrm 15y ago
Oh, yeah, UDFs are something that I want a dev to know about but I also want them to understand why most of the time they shouldn't use them ;-) Triggers, too. I would say there are some positive cases for using scalar UDFs in live-run queries, but certainly not where the UDF's result is in any way dependent on the value of a field in the dataset. There lies the path to horrendous performance problems....
shrikant 15y ago
> 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.