When it comes to salaries, I'm not average

  • Eric M Russell - Wednesday, June 27, 2018 8:45 AM

    If you're interviewing to fill an experienced T-SQL developer position, and only 1 candidate out of 15 can correctly answer a question related to GETDATE(), then that's not really a true reflection of the SQL community or job market. There is something wrong with your vetting process. Seriously, I would complain to the recruiter or HR to put more effort on the pre-screening process to line up better candidates.

    If you were to see the claims of knowledge on the resumes these people come up with, you'd understand why the vetting process is best not left to recruiters.  If we went by my vetting process, we'd have no candidates. 😉  From the sounds of what many people have gone through on this and other forums and the interviews that I've done for other companies that do have supposed good vetting processes (and they're actually not as I've found out the hard way... they miss "diamonds" and tolerate casual knowledge), the "average" for job related skills in this industry is in the toilet.  I've even found that to be true for people currently working for companies.  I'm not referring to casual positions, either.  I'm talking about lead developers, senior developers, and DBAs charged with the proverbial keys to the city.

    As for thinking that this isn't a reflection of what the actual SQL Server community at large is, one simply needs to browse these very forums to see how low the bar has become.

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

  • Eric M Russell - Wednesday, June 27, 2018 8:45 AM

    If you're interviewing to fill an experienced T-SQL developer position, and only 1 candidate out of 15 can correctly answer a question related to GETDATE(), then that's not really a true reflection of the SQL community or job market. There is something wrong with your vetting process. Seriously, I would complain to the recruiter or HR to put more effort on the pre-screening process to line up better candidates.

    That has been done for sure.

    _______________________________________________________________

    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 - Wednesday, June 27, 2018 9:40 AM

    Eric M Russell - Wednesday, June 27, 2018 8:45 AM

    If you're interviewing to fill an experienced T-SQL developer position, and only 1 candidate out of 15 can correctly answer a question related to GETDATE(), then that's not really a true reflection of the SQL community or job market. There is something wrong with your vetting process. Seriously, I would complain to the recruiter or HR to put more effort on the pre-screening process to line up better candidates.

    That has been done for sure.

    and they don't know what to do with that feedback half the time. We call our SQL Report writing positions "data analyst", which means we get people with no SQL but lots of financial analyst background. Then we get the PhD in Data Science, who we clearly can't afford, as much fun as that would be, and when we say we need SQL, we only get Oracle or MySQL folks who have never worked in SQL Server.

    Many times it's better to let them all come in and then try to weed them out ourselves. Not "better" for the candidates, necessarily, which sucks, but better than letting someone get cut by a recruiter that you really did want to see.

    -------------------------------------------------------------------------------------------------------------------------------------
    Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses

  • jonathan.crawford - Wednesday, June 27, 2018 12:31 PM

    Sean Lange - Wednesday, June 27, 2018 9:40 AM

    Eric M Russell - Wednesday, June 27, 2018 8:45 AM

    If you're interviewing to fill an experienced T-SQL developer position, and only 1 candidate out of 15 can correctly answer a question related to GETDATE(), then that's not really a true reflection of the SQL community or job market. There is something wrong with your vetting process. Seriously, I would complain to the recruiter or HR to put more effort on the pre-screening process to line up better candidates.

    That has been done for sure.

    and they don't know what to do with that feedback half the time. We call our SQL Report writing positions "data analyst", which means we get people with no SQL but lots of financial analyst background. Then we get the PhD in Data Science, who we clearly can't afford, as much fun as that would be, and when we say we need SQL, we only get Oracle or MySQL folks who have never worked in SQL Server.

    Many times it's better to let them all come in and then try to weed them out ourselves. Not "better" for the candidates, necessarily, which sucks, but better than letting someone get cut by a recruiter that you really did want to see.

    Sometimes it is just a matter of finding the right organization with the right people.  Hard, but can be done on both sides of the process.

  • Jeff Moden - Wednesday, June 27, 2018 9:33 AM

    Eric M Russell - Wednesday, June 27, 2018 8:45 AM

    If you're interviewing to fill an experienced T-SQL developer position, and only 1 candidate out of 15 can correctly answer a question related to GETDATE(), then that's not really a true reflection of the SQL community or job market. There is something wrong with your vetting process. Seriously, I would complain to the recruiter or HR to put more effort on the pre-screening process to line up better candidates.

    If you were to see the claims of knowledge on the resumes these people come up with, you'd understand why the vetting process is best not left to recruiters.  If we went by my vetting process, we'd have no candidates. 😉  From the sounds of what many people have gone through on this and other forums and the interviews that I've done for other companies that do have supposed good vetting processes (and they're actually not as I've found out the hard way... they miss "diamonds" and tolerate casual knowledge), the "average" for job related skills in this industry is in the toilet.  I've even found that to be true for people currently working for companies.  I'm not referring to casual positions, either.  I'm talking about lead developers, senior developers, and DBAs charged with the proverbial keys to the city.

    As for thinking that this isn't a reflection of what the actual SQL Server community at large is, one simply needs to browse these very forums to see how low the bar has become.

    Here's a perfect example of my last statement above...
    https://www.sqlservercentral.com/Forums/1971407/output-time-only

    If you examine the OP's profile, they became a member of SSC 14 years ago.  They were also going for a certification in querying SQL Server 5 years ago.  I can see the resume now... "14 years of experience writing T-SQL".

    Consider also the mistake in the accepted answer.

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

Viewing 5 posts - 61 through 64 (of 64 total)

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