June 22, 2018 at 3:12 pm
Andy Warren - Thursday, June 21, 2018 3:10 PMJeff, you're right that a lot of us are average. That's not bad, it's the nature of things. My premise is just a little different and that's whether you let them frame the salary negotiation based on average salary (not skill). The average they are using may or may not be a good number, and that number may or may not be one that you can live with. There's no perfect way to evaluate either your skill level or what you're worth, but it's helpful to try to assess both before the interview and if they disagree, at least explore why (even if its on your own after the interview). The technique I propose isn't one size fits all, just designed to get you thinking about that conversation. Are you negotiating or just taking what is offered?Some companies don't want superstars...or more honestly, they usually don't want to pay for superstars. Or they don't know what they cost!
Rod, feeling that way is normal. Sometimes we miss the question, miss the cue to respond a certain way, seem to care about the wrong things (salary, benefits). Not all first dates lead to second dates! Is it you or is it them is hard to figure out.
By definition very few of us are average. The skill set of humans is not a bell curve. 🙂 Unless we are using a distribution range as average.
_______________________________________________________________
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/
June 22, 2018 at 3:25 pm
Jeff Moden - Thursday, June 21, 2018 9:20 AMThe bad part about this advice is that I've heard it from a whole lot of people and they're correct... they definitely not "average" . They're actually quite a bit below average, which is pitiful to begin with according to the interviews I've conducted or have witnessed over the last decade.The first step in negotiating a salary is all that happens during the interview. If you have to tell someone that you're not average, it's because you actually are "average" or worse and did nothing to prove otherwise during the interview.
While I generally do agree with that - I am not sure that there truly is uniformity across organizations as to what the daily responsibilities entail, so I do think there could be part of the conversation to see exactly how well you fit within what is actually required. My jaded view is that there is no such thing as standard job descriptions, or perhaps stated a little differently, just because the industry might have some standard titles and skills doesn't mean a whole lot for most organizations.
I have had occasion to argue how "not average" I might be for a given position, but it was always in the context of that particular position and that organization. As the saying goes: in the land of the blind, a one-eyed person can be king. Coming in with skills matching or greatly exceeding every requirement on a position would in fact make you "not average" for that spot, so don't be afraid to show that (and if need be - explicitly state it).
Still - Jeff's right: you'd better be able to back that up with more than hot air. Be prepared for a rude awakening if you don't turn out to be quite as hot as you thought 😀:crazy:
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 22, 2018 at 5:35 pm
Jeff, maybe? Interviewing is an art on both side. You can interview well and still have the interviewer refer to average pay in the area. They might do that because they think there isn't a lot of variation or that to be above average is really really rare, or maybe just to try to anchor the negotiation that is to follow. If someone says 'the average for this area is $90k it may signal that $95 ks possible, or $100k, but not $110k. Nor would it be common for them to tell a potential hire that they consider them an above average hire, that just inflates what they have to pay!
I'll calling out one small bit of negotiating strategy because it be can occasionally be useful, but also to encourage you to think about how they set the ranges and what you can do going into an interview to change that . What if you slyly and calmly made a remark during the interview along the lines of "I've been doing this a long time and consistently rank as above average in both review and compensation". Direct? Yeah!
June 22, 2018 at 5:44 pm
Dodge. I dont assume ill intentions when they say average, but maybe sometimes it is. I think offers in general are in tension with ranges for that title and others within the company and in the local market, what they sell to HR and/or their boss, or their own notions (what, you can't make more than me!). As they say, just work the problem. If the number is good, who cares where they got it? If the number is not, is it you, is it them, how do you tackle that? I will generalize to say that most people don't have that discussion well enough and the hard part is the best time to get a better number is when you're hired or have a counter offer in hand.
June 22, 2018 at 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.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 22, 2018 at 5:52 pm
How about this, imagine it the other way. Let's say you do an interview for a position where the published range (by you/the company) is $80-$100k and the local average is $90k - just to set the scenario. A candidate interviews strongly, what you feel is above average for what you hoped to hire. What would you offer and why? When they ask the basis for your offer, what would you say? (And I know this is where so many try to make the candidate give a number first!)
June 22, 2018 at 6:11 pm
Jeff now I get your point!
June 22, 2018 at 7:31 pm
Andy Warren - Friday, June 22, 2018 6:11 PMJeff now I get your point!
It's a tough point to "get". Thanks for the feedback.
Shifting gears back to the previous post where you asked me what I'd do if I interviewed someone above "average" (which is pitifully low especially after the 12 people I interviewed prior, in this instance)... I've done it twice because, in the last decade, I've only interviewed two people that actually knew what I thought a DBA should know and that's actually nothing extraordinary.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 22, 2018 at 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.
June 23, 2018 at 4:37 am
xsevensinzx - Friday, June 22, 2018 10:24 PMJeff 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.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 23, 2018 at 5:50 am
Jeff Moden - Saturday, June 23, 2018 4:37 AMxsevensinzx - Friday, June 22, 2018 10:24 PMJeff 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.
June 23, 2018 at 6:07 pm
xsevensinzx - Saturday, June 23, 2018 5:50 AMJeff Moden - Saturday, June 23, 2018 4:37 AMxsevensinzx - Friday, June 22, 2018 10:24 PMJeff 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.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 23, 2018 at 7:50 pm
Andy Warren - Friday, June 22, 2018 5:44 PMDodge. I dont assume ill intentions when they say average, but maybe sometimes it is. I think offers in general are in tension with ranges for that title and others within the company and in the local market, what they sell to HR and/or their boss, or their own notions (what, you can't make more than me!). As they say, just work the problem. If the number is good, who cares where they got it? If the number is not, is it you, is it them, how do you tackle that? I will generalize to say that most people don't have that discussion well enough and the hard part is the best time to get a better number is when you're hired or have a counter offer in hand.
Andy,
First of all, I have added my name to my profile. Nice to meet you. I really do not drop by enough and had forgotten to provide it. As far as assuming intentions, I get it. Nor do I, but I do try to understand them as best as possible, as I presume anyone else would.
I must confess that I despise the process of hiring. And, to be fair, I think that those on the 'other side' most likely do as well. I am also starting to think that, in many cases, that recruiting houses have arrived at the point in their collective consciousness where they 'get' FUD. For those not familiar with the acronym, it stands for 'Fear, Uncertainty & Doubt". This is a gross generalization but it sure seems that by marketing themselves as the arbiters of "above average' or 'best match' and so forth to the companies while simultaneously using abrupt and impersonal vetting tactics and isolating the developer from the client by imposing in many cases overbearing contracts, they continue to insinuate themselves into the stream of capital. Now, I do not begrudge an outfit that earns their commission but it sure seems to be getting ridiculous. On my last gig, I received about 47% of the gross charge. What bugs me is that the client is the one who suffers. Where do they go? With whom do they go to fo good advice?
Years back, most of us got work through personal contacts. We developed the skills, as needed. The client understood this was hard work. They got larger, we grew, schools saw an opportunity for more revenue and started pumping out developers and all was good. Then things changed and now, while the quality of student is pretty good, their skillset is fairly narrow. What happens when the next great shift comes along? Then others will find that 'excellent' is not only 'average' but maybe 'below average' or 'failing.' Why? Their skills have not diminished nor their ability to learn and absorb. Rather the rules have changed and in that process, we are losing the most important component; trust. This is what the recruiting house take advantage of.
And, that's why I believe everyone, especially in a place like this, is far above average.
Regards,
Doug
June 23, 2018 at 8:52 pm
Jeff Moden - Saturday, June 23, 2018 6:07 PMxsevensinzx - Saturday, June 23, 2018 5:50 AMJeff Moden - Saturday, June 23, 2018 4:37 AMxsevensinzx - Friday, June 22, 2018 10:24 PMJeff 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:
June 23, 2018 at 10:26 pm
xsevensinzx - Saturday, June 23, 2018 8:52 PMJeff Moden - Saturday, June 23, 2018 6:07 PMxsevensinzx - Saturday, June 23, 2018 5:50 AMJeff Moden - Saturday, June 23, 2018 4:37 AMxsevensinzx - Friday, June 22, 2018 10:24 PMJeff 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.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 16 through 30 (of 64 total)
You must be logged in to reply to this topic. Login to reply