3 ms·

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'

by lrobb 15y ago

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.

matwood 15y ago
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.
ap22213 15y ago
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 15y ago
  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.

by lrobb 15y ago

matwood 15y ago

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.

ap22213 15y ago

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 15y ago
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.