When it comes to salaries, I'm not average

  • Jeff Moden - Saturday, June 23, 2018 10:26 PM

    xsevensinzx - Saturday, June 23, 2018 8:52 PM

    Jeff Moden - Saturday, June 23, 2018 6:07 PM

    xsevensinzx - Saturday, June 23, 2018 5:50 AM

    Jeff Moden - Saturday, June 23, 2018 4:37 AM

    xsevensinzx - Friday, June 22, 2018 10:24 PM

    Jeff Moden - Friday, June 22, 2018 5:50 PM

    @Andy... yes, I absolutely understand that.  And it's all very well stated.  What I'm getting at is that everyone is going to use this once they become aware of it and, according to the interviews I've conducted, very few are deserving of saying they're "above average".  It's kind of like all those internet articles base on "If you say this one thing, the employer is going to hire you".  Hopefully, people know better than that, as well.

    It's damn hard to rate a candidate in the interview process. You don't truly know until they start work and you see them in action. This is why I try not to kneecap my interviews before I actually interview them. Everybody is above average until proven otherwise.

    I'll have to totally disagree with that.   There are certain basics that people must know to even have a chance of being a decent Database Developer or DBA.  It's like asking a tennis player what type of racket they prefer.  If they come back with "Ummmm.... what's a racket", then you can be pretty sure they're not a tennis player.

    For most of the people I've interviewed, I'm not sure why they're even in the business... it's that bad.

    And, no... we're not trying to hire rookies.  We're trying to hire senior people that actually know things.

    That's entirely subjective to the person conducting the interview on what those basics are. I've never interviewed someone who didn't know what a racket is for a tennis player for example unless their resume was entirely fabricated and or they really didn't play tennis as a tennis player.

    I know from your past posts it's more along the lines that they did not play tennis as a tennis player in regards to for example, senior DBA's not knowing how to get the system time. But that's your professional opinion on what those basics should entail to be above average for that position. I used to think it was a huge deal. But now, I've come to realize that I personally do not care about memory capacity of mundane syntax that is insanely easy to lookup on your own. I myself could likely fail to know some basics you may find as a need-to-know for those basics as well. It doesn't negate the fact that I am a data architect who has developed complex data platforms from scratch because I have the ability to solve problems on my own.  And therefore, be paid above average.

    I'm sure you could tell that I am a type of interviewer who cares less about code tests, coding on whiteboards and all that jive. I'm more interested in what problems you have solved, if you could tackle the problems we need solving, and how you may have solved the problems in the past we are facing as a business. Then the difference between a DBA and a Senior DBA is just how much more exposure to those problems you have had along with your ability to move into a leadership role as your next career steps. I.e.: if the only difference between your seniors and your normal employees is one knows how to get system time and the other does not, then that's not enough to separate between a senior or not.

    The trouble is, you can't solve the problems if you don't even have a handle on the basics.  It do get that a person that is prone to being able to solve problems can solve just about any problem whether they know something or not.  If we were hiring with the aim to train, things could be a bit different.  But, then there's the subject of the resume.  If you've advertised yourself as a DBA with 10 years of experience and you don't know things like how to get the current date and time using T-SQL or you don't know what a TailLog backup is, then either you've lived a very sheltered life or you're a liar.  Either way, you're not Senior DBA material.  The same holds true for Developers.

    Of course, that's just my opinion but I wouldn't even think of letting the company pay even the low side of the salary range for a DBA that doesn't know the basics.

    T-SQL is essentially a means to accomplish something; a tool. Knowing how to use a tool is nothing to do with knowing how to solve a problem. Plenty of people think of how to solve a problem first and then see if they have a tool that can help solve that problem. For example, I need to query a set of data for the past 7 days of the current date. While they may not know how to get the current date using T-SQL, they will likely need to know if their current tools support it, which will land them to the syntax of pulling the current system time in SQL.

    However, I'm not trying to shoot you down here. You're better off making the stance that while you were Googling how to do a Point-in-Time recovery, the business lost 20 million dollars versus if you just knew it and recovered right away where the business only lost 5 million. :laugh:

    I thought it (things like your last paragraph) was obvious that's one of the most important parts of the stance that I've taken, especially with Senior DBAs.  Apparently it wasn't so obvious.

    The other part is that we require the front-end developers to do a lot of development in T-SQL, specifically in stored procedures.  If you don't know how to get the current date and time, then you don't know enough about T-SQL to satisfy the requirement for employment, especially if you've claimed that you've written stored procedures for the last 5 or 10 years on your resume.

    Also and to reiterate, we don't end the interview if they don't know that first question.  But, so far, it has been a litmus strip as to just how bad the rest of the interview will be if they can't answer it.

    We require our developers to do almost all of their own t-sql. The last couple rounds of hiring I used this question having seen Jeff mention it so many times. It is truly shocking how many people that rate themselves as advanced with t-sql and writing procedures for 5-10 years can't answer that. Two rounds ago we interviewed about 12-15 candidates just for a 6 month contract (it took that many interviews to find one). I started each interview the same way by explaining how our devs write their own procedures and we require some level of competence. And by telling them we will have technical questions that will increase in difficulty but none of them are trick questions and the simple answer is really what we are looking for. My first question was "can you tell me how to get the current system time using t-sql". Out of those 12-15 exactly one of them knew the answer. That person tentatively said "getdate" with a question mark. You could tell the response was "seriously? Is it really that simple?". Of the others they either say they don't know or make up some incredibly interesting stories about how they never needed to know the current time for anything or say things like "DateTime.Now".

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Sean Lange - Monday, June 25, 2018 7:26 AM

    We require our developers to do almost all of their own t-sql. The last couple rounds of hiring I used this question having seen Jeff mention it so many times. It is truly shocking how many people that rate themselves as advanced with t-sql and writing procedures for 5-10 years can't answer that. Two rounds ago we interviewed about 12-15 candidates just for a 6 month contract (it took that many interviews to find one). I started each interview the same way by explaining how our devs write their own procedures and we require some level of competence. And by telling them we will have technical questions that will increase in difficulty but none of them are trick questions and the simple answer is really what we are looking for. My first question was "can you tell me how to get the current system time using t-sql". Out of those 12-15 exactly one of them knew the answer. That person tentatively said "getdate" with a question mark. You could tell the response was "seriously? Is it really that simple?". Of the others they either say they don't know or make up some incredibly interesting stories about how they never needed to know the current time for anything or say things like "DateTime.Now".

    Heh... glad to hear I'm not the only one that has experienced this.

    Like I said before, I originally started asking the question to set people at ease because I thought it was such a simple question.  I couldn't believe that it turned out to be a litmus strip.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden - Monday, June 25, 2018 8:26 AM

    Sean Lange - Monday, June 25, 2018 7:26 AM

    We require our developers to do almost all of their own t-sql. The last couple rounds of hiring I used this question having seen Jeff mention it so many times. It is truly shocking how many people that rate themselves as advanced with t-sql and writing procedures for 5-10 years can't answer that. Two rounds ago we interviewed about 12-15 candidates just for a 6 month contract (it took that many interviews to find one). I started each interview the same way by explaining how our devs write their own procedures and we require some level of competence. And by telling them we will have technical questions that will increase in difficulty but none of them are trick questions and the simple answer is really what we are looking for. My first question was "can you tell me how to get the current system time using t-sql". Out of those 12-15 exactly one of them knew the answer. That person tentatively said "getdate" with a question mark. You could tell the response was "seriously? Is it really that simple?". Of the others they either say they don't know or make up some incredibly interesting stories about how they never needed to know the current time for anything or say things like "DateTime.Now".

    Heh... glad to hear I'm not the only one that has experienced this.

    Like I said before, I originally started asking the question to set people at ease because I thought it was such a simple question.  I couldn't believe that it turned out to be a litmus strip.

    The other interesting one I like to ask is if they know what sql injection is and some simple ways to avoid it. You should try that one out. I have heard some unbelievably interesting responses that. One guy was going on for nearly 5 minutes discussing how you can use dotnet reflection to use sql injection for performance benefits. I am not kidding.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Sean Lange - Monday, June 25, 2018 7:26 AM

    We require our developers to do almost all of their own t-sql. The last couple rounds of hiring I used this question having seen Jeff mention it so many times. It is truly shocking how many people that rate themselves as advanced with t-sql and writing procedures for 5-10 years can't answer that. Two rounds ago we interviewed about 12-15 candidates just for a 6 month contract (it took that many interviews to find one). I started each interview the same way by explaining how our devs write their own procedures and we require some level of competence. And by telling them we will have technical questions that will increase in difficulty but none of them are trick questions and the simple answer is really what we are looking for. My first question was "can you tell me how to get the current system time using t-sql". Out of those 12-15 exactly one of them knew the answer. That person tentatively said "getdate" with a question mark. You could tell the response was "seriously? Is it really that simple?". Of the others they either say they don't know or make up some incredibly interesting stories about how they never needed to know the current time for anything or say things like "DateTime.Now".

    The problem with the current date/time question is that, even if answered correctly, it doesn't come close to qualifying someone for the job. If the candidate can't answer that one, then there is something seriously wrong with the vetting process.

    My opening question is to ask the candidate to tell me their story. What have they been doing for the past year, and which of their past projects do they feel would be most relevant to the job they are currently applying for. After that, the first, and perhaps only, technical question would go something like this:

    "Let's assume a stored procedure normally runs in less than 10 seconds, but today it's been consistently running for a minute or longer."
    (pause and let it sink it)
    "Here is what I need to know from you: First tell me at least a half dozen common causes for this type of performance degradation, and then describe in more detail how you would diagnose the actual root cause."

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Jeff, following up a little, my view is that if everyone started using this approach it would be a good thing! Not that everyone is above average, but it drives the conversation in a way I think useful to both sides. The worst case is if I think Im above average and they don't? Even if Im NOT above average, understanding why they don't think so is incredibly useful (and possibly incredibly humbling too). But maybe I interviewed badly, or the interviewer doesn't know how to figure out the offer.

    In practice its not a strategy for everyone or every situation and using it takes some confidence. What I hope is that it sparks some thought about handling that part of the interview because in the end the best time (and often only time) to really adjust your salary is when you're hired.

  • Eric M Russell - Tuesday, June 26, 2018 8:11 AM

    Sean Lange - Monday, June 25, 2018 7:26 AM

    We require our developers to do almost all of their own t-sql. The last couple rounds of hiring I used this question having seen Jeff mention it so many times. It is truly shocking how many people that rate themselves as advanced with t-sql and writing procedures for 5-10 years can't answer that. Two rounds ago we interviewed about 12-15 candidates just for a 6 month contract (it took that many interviews to find one). I started each interview the same way by explaining how our devs write their own procedures and we require some level of competence. And by telling them we will have technical questions that will increase in difficulty but none of them are trick questions and the simple answer is really what we are looking for. My first question was "can you tell me how to get the current system time using t-sql". Out of those 12-15 exactly one of them knew the answer. That person tentatively said "getdate" with a question mark. You could tell the response was "seriously? Is it really that simple?". Of the others they either say they don't know or make up some incredibly interesting stories about how they never needed to know the current time for anything or say things like "DateTime.Now".

    The problem with the current date/time question is that, even if answered correctly, it doesn't come close to qualifying someone for the job. If the candidate can't answer that one, then there is something seriously wrong with the vetting process.

    My opening question is to ask the candidate to tell me their story. What have they been doing for the past year, and which of their past projects do they feel would be most relevant to the job they are currently applying for. After that, the first, and perhaps only, technical question would go something like this:

    "Let's assume a stored procedure normally runs in less than 10 seconds, but today it's been consistently running for a minute or longer."
    (pause and let it sink it)
    "Here is what I need to know from you: First tell me at least a half dozen common causes for this type of performance degradation, and then describe in more detail how you would diagnose the actual root cause."

    I also start with hearing their story, I sort of assumed that was pretty standard. But once we get to the meat of the interview it is a good place to start on the technical side of things. It certainly doesn't mean they are qualified but if they flat out don't know then it is painfully obvious that are NOT qualified. Of course the vetting process for hiring has broken across all disciplines for a long time thanks to the proliferation of staffing agencies. Then there is a phone interview with the HR department but of course they don't have any technical knowledge. So the candidate has a decent looking CV and is personable, therefore an interview. All too often they just don't have the knowledge to back up what they claim on their CV.

    Part of the blame lies on the shoulder of these staffing agencies. On more than one occasion I have seen them add things to my resume without discussing it with me. One such example, I was applying for a developer role. This role was going to be somebody super deep in the security of things and transmitting sensitive medical information. They wanted somebody who was going to help them ensure that the encryption was up to par. They wanted someone with in depth knowledge and experience. Specifically they wanted someone that really understands X.509 implementation to ensure everything was secure. I was asked about my knowledge of this during an interview to which I responded something like "well I have installed a few ssl certificates here and there but nothing in depth to understand the inner workings of the technology". The interviewer said, "well it is right here on your resume". Hmmm....that didn't get there from me. I asked them if I could see their copy. The staffing agency added X.509 experience to my CV without my knowledge or consent. Fortunately I had a copy with me that was written by me. I shared that with them and they read it over. The interview ended right then and there. They said I had great credentials but they were not looking for anybody with my skill set. To say the least that place got an earful from me and is a business I will never use again.

    The point of the story is that using something super basic as a litmus test is something I have seen be successful on both sides of the interviewing process. Once a candidate can answer how to use getdate() or any other method then we can get to the real questions.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Eric M Russell - Tuesday, June 26, 2018 8:11 AM

    Sean Lange - Monday, June 25, 2018 7:26 AM

    We require our developers to do almost all of their own t-sql. The last couple rounds of hiring I used this question having seen Jeff mention it so many times. It is truly shocking how many people that rate themselves as advanced with t-sql and writing procedures for 5-10 years can't answer that. Two rounds ago we interviewed about 12-15 candidates just for a 6 month contract (it took that many interviews to find one). I started each interview the same way by explaining how our devs write their own procedures and we require some level of competence. And by telling them we will have technical questions that will increase in difficulty but none of them are trick questions and the simple answer is really what we are looking for. My first question was "can you tell me how to get the current system time using t-sql". Out of those 12-15 exactly one of them knew the answer. That person tentatively said "getdate" with a question mark. You could tell the response was "seriously? Is it really that simple?". Of the others they either say they don't know or make up some incredibly interesting stories about how they never needed to know the current time for anything or say things like "DateTime.Now".

    The problem with the current date/time question is that, even if answered correctly, it doesn't come close to qualifying someone for the job. If the candidate can't answer that one, then there is something seriously wrong with the vetting process.

    My opening question is to ask the candidate to tell me their story. What have they been doing for the past year, and which of their past projects do they feel would be most relevant to the job they are currently applying for. After that, the first, and perhaps only, technical question would go something like this:

    "Let's assume a stored procedure normally runs in less than 10 seconds, but today it's been consistently running for a minute or longer."
    (pause and let it sink it)
    "Here is what I need to know from you: First tell me at least a half dozen common causes for this type of performance degradation, and then describe in more detail how you would diagnose the actual root cause."

    I absolutely agree that the question does not qualify someone for the job.  It's just a litmus strip or proverbial finger in the air or toe in the water to see what the rest of the interview is going to be like because, if they don't know that particular basic, there will be a lot of basics that they don't know.

    As for the vetting process, I'm loath to use traditional methods such as trying to interpret what someone has written in a resume.  It seems that both sides of the Dunning-Kruger Effect are at play on resumes and then there are the "enhancements" that some recruiters add to the resumes to "make the resume fit the job requirements".

    And, yes... we do talk to the resume and ask the applicant about such things as you have mentioned.  For example, if they state that they've written stored procedures on their resume, we ask them which stored procedure they were most proud of, what it did, and how they scienced it out.  As a bit of a sidebar, you know there's been some embellishment on the resume when they can't even "remember" a project they wrote stored procedures for.

    I normally don't have to deal with tens or hundreds of applications for a given position.  Typically, it's less than a dozen.  With the idea that "some people just can't take a written test" and that "some people can't write a resume to save their soul", I don't ever want to miss the proverbial diamond in the rough.  The other interviewers are of the same ilk.  And so we'll typically interview anyone that takes the time to expose themselves with a resume.

    It's not just answers to questions in interviews that we go by.  We are looking not only for people that know their stuff but, as many have said, people that can also solve problems (in T-SQL because that's most of what we're hiring for) they may not have run across using whatever knowledge they have to science out  a problem.  We do have another fairly simple question that a whole lot of people seem to miss (most of the people on this thread would solve it easily) and we try to coach them through the problem during which we consider things like the thought process, level of frustration, and several other "human" attributes.

    Not so oddly though, everyone that misses the current-date-and-time question (which was originally used to try to set nervous candidates at ease and to demonstrate there were going to be no trick questions) fails the interview especially when it comes to the walk-through process of the other telling question.

    We have had the rare bird that knows everything but wouldn't fit on the team because of arrogance or a superiority complex, which we're very careful not to confuse with a display of confidence.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Andy Warren - Tuesday, June 26, 2018 9:42 AM

    Jeff, following up a little, my view is that if everyone started using this approach it would be a good thing! Not that everyone is above average, but it drives the conversation in a way I think useful to both sides. The worst case is if I think Im above average and they don't? Even if Im NOT above average, understanding why they don't think so is incredibly useful (and possibly incredibly humbling too). But maybe I interviewed badly, or the interviewer doesn't know how to figure out the offer.

    In practice its not a strategy for everyone or every situation and using it takes some confidence. What I hope is that it sparks some thought about handling that part of the interview because in the end the best time (and often only time) to really adjust your salary is when you're hired.

    It certainly DID spark up some great conversations on the subject, Andy, and so I most definitely thank you for taking the time to write up the article and post it.  Well done!

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Sean Lange - Tuesday, June 26, 2018 9:51 AM

    Eric M Russell - Tuesday, June 26, 2018 8:11 AM

    Sean Lange - Monday, June 25, 2018 7:26 AM

    We require our developers to do almost all of their own t-sql. The last couple rounds of hiring I used this question having seen Jeff mention it so many times. It is truly shocking how many people that rate themselves as advanced with t-sql and writing procedures for 5-10 years can't answer that. Two rounds ago we interviewed about 12-15 candidates just for a 6 month contract (it took that many interviews to find one). I started each interview the same way by explaining how our devs write their own procedures and we require some level of competence. And by telling them we will have technical questions that will increase in difficulty but none of them are trick questions and the simple answer is really what we are looking for. My first question was "can you tell me how to get the current system time using t-sql". Out of those 12-15 exactly one of them knew the answer. That person tentatively said "getdate" with a question mark. You could tell the response was "seriously? Is it really that simple?". Of the others they either say they don't know or make up some incredibly interesting stories about how they never needed to know the current time for anything or say things like "DateTime.Now".

    The problem with the current date/time question is that, even if answered correctly, it doesn't come close to qualifying someone for the job. If the candidate can't answer that one, then there is something seriously wrong with the vetting process.

    My opening question is to ask the candidate to tell me their story. What have they been doing for the past year, and which of their past projects do they feel would be most relevant to the job they are currently applying for. After that, the first, and perhaps only, technical question would go something like this:

    "Let's assume a stored procedure normally runs in less than 10 seconds, but today it's been consistently running for a minute or longer."
    (pause and let it sink it)
    "Here is what I need to know from you: First tell me at least a half dozen common causes for this type of performance degradation, and then describe in more detail how you would diagnose the actual root cause."

    I also start with hearing their story, I sort of assumed that was pretty standard. But once we get to the meat of the interview it is a good place to start on the technical side of things. It certainly doesn't mean they are qualified but if they flat out don't know then it is painfully obvious that are NOT qualified. Of course the vetting process for hiring has broken across all disciplines for a long time thanks to the proliferation of staffing agencies. Then there is a phone interview with the HR department but of course they don't have any technical knowledge. So the candidate has a decent looking CV and is personable, therefore an interview. All too often they just don't have the knowledge to back up what they claim on their CV.

    Part of the blame lies on the shoulder of these staffing agencies. On more than one occasion I have seen them add things to my resume without discussing it with me. One such example, I was applying for a developer role. This role was going to be somebody super deep in the security of things and transmitting sensitive medical information. They wanted somebody who was going to help them ensure that the encryption was up to par. They wanted someone with in depth knowledge and experience. Specifically they wanted someone that really understands X.509 implementation to ensure everything was secure. I was asked about my knowledge of this during an interview to which I responded something like "well I have installed a few ssl certificates here and there but nothing in depth to understand the inner workings of the technology". The interviewer said, "well it is right here on your resume". Hmmm....that didn't get there from me. I asked them if I could see their copy. The staffing agency added X.509 experience to my CV without my knowledge or consent. Fortunately I had a copy with me that was written by me. I shared that with them and they read it over. The interview ended right then and there. They said I had great credentials but they were not looking for anybody with my skill set. To say the least that place got an earful from me and is a business I will never use again.

    The point of the story is that using something super basic as a litmus test is something I have seen be successful on both sides of the interviewing process. Once a candidate can answer how to use getdate() or any other method then we can get to the real questions.

    +1000  It's kind of like when trying to hire a carpenter... if you hold up a hammer and ask "What is this called?" and they can't answer, you just know the rest of the interview is going to be a chore.  I have been seriously tempted (and actually did, on one occasion) to end the interview on that first question but I do take into account that the candidate may be crapping their britches and need to "settle in" a bit and so will normally continue the interview even as a professional courtesy because they did take the time to make an appearance.

    What's truly amazing is that I have done some interviews where the candidate never actually answer the questions being posed and, instead, rambled on with a seriously thick and prolonged line of total BS and then had the nerve to ask "Where do we go from here?" at the end of the interview.  I leave the answer to that question to the other interviewers because politically correct answers are not my forte` in such matters. 😉

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • If you disqualify them for the job over it, then you are saying they are qualified if they answer it right. The same logic applies when dipping you toe into the water. If it's too cold, you just disqualified the water to touch your body if you walk away and not jump in. Everything said here sounds like you're all disqualifying them for the job if they answer it wrong. :Whistling:

    The thing is, it's insanely easy to learn how to pull a trigger (i.e.: learn how to get the system time). It's not easy to pull that trigger when it counts in war (i.e.: know when to use it). That's why the journey--the story--is always going to be more relevant than anything else.

  • xsevensinzx - Tuesday, June 26, 2018 10:19 AM

    If you disqualify them for the job over it, then you are saying they are qualified if they answer it right. The same logic applies when dipping you toe into the water. If it's too cold, you just disqualified the water to touch your body if you walk away and not jump in. Everything said here sounds like you're all disqualifying them for the job if they answer it wrong. :Whistling:

    The thing is, it's insanely easy to learn how to pull a trigger (i.e.: learn how to get the system time). It's not easy to pull that trigger when it counts in war (i.e.: know when to use it). That's why the journey--the story--is always going to be more relevant than anything else.

    Your logic is tragically flawed. Just because they clearly are not qualified answering an absolute basic question does NOT mean they are qualified if they do. But if said person claims 5-10 years of sql development and can't tell you how to get the current system time then it means 1 of 2 things. Either they a month of experience over and over for the last several years and have shown zero signs of growth OR they flat out lied on their CV. Anybody with anywhere close to 5-10 years experience in sql server will know how to get the current system time. It is like Jeff's example of a carpenter with a hammer. If they don't know what that tool is used for you can be damned sure they are totally incompetent as a carpenter. And yes, I would say that if they can't get the system time in a query they are not qualified. There have been several people over the years who Jeff would say is the diamond in the rough. They are intelligent people who would be quick learners. But when hiring for a contract position or a mid-level person they are not at the right level of experience.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • xsevensinzx - Tuesday, June 26, 2018 10:19 AM

    If you disqualify them for the job over it, then you are saying they are qualified if they answer it right. The same logic applies when dipping you toe into the water. If it's too cold, you just disqualified the water to touch your body if you walk away and not jump in. Everything said here sounds like you're all disqualifying them for the job if they answer it wrong. :Whistling:

    Not sure why that would actually be a problem but, again, I do give folks a chance after that because they just might be nervous as hell.  To continue to "toe in the water" analogy, it may be that the candidate simply forgot to heat the water but it does turn out that they normally don't know what water is if they don't get that first question right.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden - Tuesday, June 26, 2018 10:15 AM

    ...
    What's truly amazing is that I have done some interviews where the candidate never actually answer the questions being posed and, instead, rambled on with a seriously thick and prolonged line of total BS and then had the nerve to ask "Where do we go from here?" at the end of the interview.  I leave the answer to that question to the other interviewers because politically correct answers are not my forte` in such matters. 😉

    The arrogant attitude and nonsensical rambling that avoids the question is probably the result of the self-entitled "fake it until you make it" culture. Contemporary society rewards flashy posers with jobs they don't deserve, up to and including the highest levels of political office. But in the industries of IT and engineering, zero plus zero equals zero regardless of context, because it's our job to guard to gates and keep the trains running on time.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell - Tuesday, June 26, 2018 12:09 PM

    Jeff Moden - Tuesday, June 26, 2018 10:15 AM

    ...
    What's truly amazing is that I have done some interviews where the candidate never actually answer the questions being posed and, instead, rambled on with a seriously thick and prolonged line of total BS and then had the nerve to ask "Where do we go from here?" at the end of the interview.  I leave the answer to that question to the other interviewers because politically correct answers are not my forte` in such matters. 😉

    The arrogant attitude and nonsensical rambling that avoids the question is probably the result of the self-entitled "fake it until you make it" culture. Contemporary society rewards flashy posers with jobs they don't deserve, up to and including the highest levels of political office. But in the industries of IT and engineering, zero plus zero equals zero regardless of context, because it's our job to guard to gates and keep the trains running on time.

    Agreed.  And I also look at it as an affront to "integrity".  I can't afford to have such people on the job because they don't understand the principle of "absolute honestly".

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Sean Lange - Tuesday, June 26, 2018 10:44 AM

    xsevensinzx - Tuesday, June 26, 2018 10:19 AM

    If you disqualify them for the job over it, then you are saying they are qualified if they answer it right. The same logic applies when dipping you toe into the water. If it's too cold, you just disqualified the water to touch your body if you walk away and not jump in. Everything said here sounds like you're all disqualifying them for the job if they answer it wrong. :Whistling:

    The thing is, it's insanely easy to learn how to pull a trigger (i.e.: learn how to get the system time). It's not easy to pull that trigger when it counts in war (i.e.: know when to use it). That's why the journey--the story--is always going to be more relevant than anything else.

    Your logic is tragically flawed. Just because they clearly are not qualified answering an absolute basic question does NOT mean they are qualified if they do. But if said person claims 5-10 years of sql development and can't tell you how to get the current system time then it means 1 of 2 things. Either they a month of experience over and over for the last several years and have shown zero signs of growth OR they flat out lied on their CV. Anybody with anywhere close to 5-10 years experience in sql server will know how to get the current system time. It is like Jeff's example of a carpenter with a hammer. If they don't know what that tool is used for you can be damned sure they are totally incompetent as a carpenter. And yes, I would say that if they can't get the system time in a query they are not qualified. There have been several people over the years who Jeff would say is the diamond in the rough. They are intelligent people who would be quick learners. But when hiring for a contract position or a mid-level person they are not at the right level of experience.

    Sean,

    A couple thoughts for the conversation 'grist mill' if you will.

    Stuff I never Needed
    ----------------------------
    I have started using the dBASE alternative, FoxBase some 30 years back.  While I have not used the latest version of the product recently, when I have it comes back relatively quickly.  Even now then there are functions and features I would consider myself unaware of.  The reason is that I have never had a need to use them.  Perhaps some functions like SIN() or COS() never were needed.  It was certainly a surprise to me that so few knew about GETDATE() but candidly, not having been immersed in T-SQL recently, I had to take a quick peek to remember.  Maybe that's age (an increasingly useful excuse 😉) or the way my mind processes and stores information.

    Panic Time
    ---------------------------------
    I do not like in-person interviews at all.  I tend to 'lock up.'  It wasn't until I took an online Meyers-Briggs self-analysis that I discovered this sort of approach didn't look to be the best way someone like me would normally approach and resolve thorny technical issues.  That is, the typical interview venue, for me at least, is an extra hurdle.  I understand that under pressure we need to not 'lock up' and, interestingly enough, I do not, except during the interview.  I do not tie my assessment of others to on-the-spot answers primarily because I understand that this stuff can be complex.  Given that I prefer proper and precise answers I am always thinking I will run out of time and that a correct answer often does not fit into "soundbite thinking."  I'd prefer a setting more like real life.

    What Was That Again?
    --------------------------------
    I can remember my driver's license, from another state 30 years ago. A0954063, for what it's worth. And, my phone number from when I was 5 years old 544-1972, my neighbor's, 544-1793 (there's the hook, right?) and my late aunt & uncles from 40 years back; 846-1402.  I struggle terribly with names.  They take longer to settle in.  I mention this because I am paid to resolve issues which in turn should simplify some process which also, in turn, ought to demonstrate, in a very measurable fashion that my time and the whole of the entire correlated expense of reaching a suitable end will satisfy the one concern of management; ROI.  An arbitrary example would be; Doug takes $5,000 start-to-finish 'X'.  Over the next year, we will realize $6,500 in savings and $3,500 in additional projected revenue.  That makes the chore a $5,000 net to the company. 

    I don't care to remember every little bit and I am not, at least in my own thinking, 'better' or 'worse' should I remember some approach.  Now, this is within reasonable limits naturally but I do see this often the basis of one's corporate social standing and is even weaponized as others climb the ladder to what?  I want to figure things out and write code.  I can find answers, and better at that, already available and freely licensed by those more generous.

    I would want to see some coding samples though.  Or an over-the-weekend type test perhaps?

    It was the Woman Lord
    ---------------------------------
    Those who provide any kind of training whatsoever will, in my opinion, always be trailing edge rather than leading edge. Why?  They are reacting and attempting to be the best or first to get in front at the earliest possible moment.  This is great and these folks provide fabulous resources but it does raise, for me, a question.  If the company is wanting to keep current and competitive, which does require knowing the latest and greatest trends, how can this not lead to a sort of perpetual looking for, finding and more often than not realizing that candidate 'Y', who did, in fact, know the proper buzzwords and the automated recruiter filtering engines fished out, be a total dud?  It's always someone else's fault so the manager's blame the agency or the hire and the recruiting firm, after discussing the issue with the hire (because they really want to place them elsewhere) decide that it was the manager.  

    It always seems to be someone else's fault and when you stand up and take responsibility you may well be blamed for the decisions of others.  I prefer to take personal responsibility and value my character over employment.  I can do this financially now but I've done it before when not so.  I am nothing special as I think everyone should do this but that is not the world we live in.

    The Real Issue?
    ----------------------
    So, does the candidate demonstrate good character?  If they honestly state that they don't know something rather than try and bluff, I prefer this to the alternative.

    Given the above and the other valid concerns, discarding the moaning and groaning about how difficult it all is, and unfair, and a royal pain in the *** to deal with politics and agendas and so forth, what are the best suggestions on how to meet and overcome them?  I have a few which include making sure to take time off (like I am doing now) to ensure there is balance in life, catching up on technical skills, cleaning out the garage 🙂 and all of the rest.

    What sort of approach would be the best way to bring someone on and get them in synch with the company, the standards, the goals, culture and all of the rest?

Viewing 15 posts - 31 through 45 (of 64 total)

You must be logged in to reply to this topic. Login to reply