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.
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.
Aaaahhhhh ... 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.
Regarding 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.
I 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.
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.
Like any tool, ORMs are appropriate for some uses, and not for others.
In the Python world, I like SQLAlchemy. It performs well, it's fairly well documented (improving, though I've had to read source code to figure out options before), and it's not tied to a web framework, the way I believe Django's is.
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.
My 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.
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?!
1) 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.
> 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.
> You should have seen the vacant look on his face when we tried to explain a very simple closure. Advanced indeed...
Being able to describe a closure is only valid if you've had reason to use them before. Sure, use of jQuery pretty much implies use of closures, but in general, lack of specific knowledge within a domain does not imply lack of knowledge in the domain.
A fair point: you can get by without them completely for many tasks, or with them but not actually knowing you are using them (and/or what to call them) because you've not needed to understand the implications in detail (i.e. you might pass out an inner function and merrily call it, or hand a function that uses state outside its internal scope to some library, without knowing that these are closures).
But to not be able to grasp it at all when explained (he wasn't being asked to describe them from his own understanding), definitely marks "javascript: advanced" as an exaggeration far too far IMO.
To be honest I wasn't being really fair with the closure thing. I should have not proceeded as we'd already left his safety zone long before that point. Anonymous functions were alien to him, and I'm not sure he was even comfortable with the idea of functions being entities that you could pass around at all (i.e. do anything with other than define and call).
To put is simply: I considered his level of knowledge/experience to be no better than basic, perhaps not even that, unless you count having copied and pasted some more advanced code samples, and his CV claimed "advanced". And not recognising jQuery(document).ready() or any of its shorter equivalents made his level of anything with jQuery "none" rather than "intermediate" claimed (making that an flat out lie instead of just a gross exaggeration).
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.
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.
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 :)
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....
> 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.
I feel qualified to work with SQL Server (not for a DBA position though) and didn't know the answers to half the questions. I've never seen truncate, two types of UDF or cursors...
I believe that the thing that infuriates the interviewer is not ignorance, but the unlimited interviewee's confidence in making up the answers with "logic". If I don't know what truncate is, I just say so.
Also I do know what a clustered index is, the difference between triggers and SPs, or the select into thing. So there wouldn't be so extreme a difference between knowledge and answering impudence.
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.
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.
Only 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).
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.
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!
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.
MSSQL probably has the '= NULL' syntax around for backwards compatibility. It does support the 'is null' and 'is not null' syntax that is in Oracle (which is standard IIRC).
It's an option which can be enabled or disabled to taste. It's no more egregious than empty strings being null in Oracle, though I've no doubt there are more persuasive arguments for why Oracle is a better RDBMS.
SQL Server has a setting ANSI_NULLS, which defaults to on. In this state, the behavior is exactly as you expect. It takes explicit action to change it from the standard.
That said, the SQL standard is already inconsistent in this respect, which annoys me. You are allowed to use equality in setting a value:
update mytable set mycol=NULL where mykey=2
If I'm allowed to assign a value of null, why can't I compare it? If NULL is so special that its value cannot be compared, then what does it mean when I assign that "value"? The assignment operation makes a copy of the specified value into the target column; how can I make that copy of the specified value if it's impossible to say that two NULLs are the same?
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.
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.
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.
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.
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.
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.
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.
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.
54 comments
[ 3.0 ms ] story [ 123 ms ] threadAnother 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.
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.
Edit: http://dev.mysql.com/doc/refman/5.6/en/char.html
It's CHAR that pads with spaces, not VARCHAR.
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.
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.
In the Python world, I like SQLAlchemy. It performs well, it's fairly well documented (improving, though I've had to read source code to figure out options before), and it's not tied to a web framework, the way I believe Django's is.
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.
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?!
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.
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.
Being able to describe a closure is only valid if you've had reason to use them before. Sure, use of jQuery pretty much implies use of closures, but in general, lack of specific knowledge within a domain does not imply lack of knowledge in the domain.
But to not be able to grasp it at all when explained (he wasn't being asked to describe them from his own understanding), definitely marks "javascript: advanced" as an exaggeration far too far IMO.
To be honest I wasn't being really fair with the closure thing. I should have not proceeded as we'd already left his safety zone long before that point. Anonymous functions were alien to him, and I'm not sure he was even comfortable with the idea of functions being entities that you could pass around at all (i.e. do anything with other than define and call).
To put is simply: I considered his level of knowledge/experience to be no better than basic, perhaps not even that, unless you count having copied and pasted some more advanced code samples, and his CV claimed "advanced". And not recognising jQuery(document).ready() or any of its shorter equivalents made his level of anything with jQuery "none" rather than "intermediate" claimed (making that an flat out lie instead of just a gross exaggeration).
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.
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.
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 :)
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....
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.
I believe that the thing that infuriates the interviewer is not ignorance, but the unlimited interviewee's confidence in making up the answers with "logic". If I don't know what truncate is, I just say so.
Also I do know what a clustered index is, the difference between triggers and SPs, or the select into thing. So there wouldn't be so extreme a difference between knowledge and answering impudence.
I'm not ashamed to say that --i-am-a-dummy.
All that fake bravado may get someone hired, but eventually he or she just ends up as an object lesson on a blog somewhere.
So I would fail this interview.
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).
'' (empty string) being the same thing as null is really neat though!
That said, the SQL standard is already inconsistent in this respect, which annoys me. You are allowed to use equality in setting a value:
If I'm allowed to assign a value of null, why can't I compare it? If NULL is so special that its value cannot be compared, then what does it mean when I assign that "value"? The assignment operation makes a copy of the specified value into the target column; how can I make that copy of the specified value if it's impossible to say that two NULLs are the same?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.
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.
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.
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.
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.
This is probably just as sad as people who know nothing.