InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSat, 25 May 2013 16:53:54 GMT20http://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]Gary Varga (1/21/2013)[/b][hr][quote][b]Jeff Moden (1/18/2013)[/b][hr][quote][b]lewandot (1/17/2013)[/b][hr]You can teach them SQL.[/quote]I'm finding that to be less and less true. Some people will never actually get it.[/quote]Unfortunately, it appears to be true to programming in general. Or rather you can get "them" to produce the lines of code that may work but it is far from professional systems development. It is harder do get people who can do things "right" (or just well).SQL is just prevalent here because it is the contextual tip of the iceberg.[/quote]Sorry for the late reply but, yes, that's exactly the perception I have lately. The Dev group at work has been trying to hire a couple of front end Developers and that will also spend about 30% of their time writing stored procedures because we mostly don't allow embedded code (not to be confused with CRUD code usually generated by an ORM). The interviews always start with the front end Developer side and very few people are making it through what I think should be basic skills questioning. Most never even make it through to the SQL side of the questioning. The folks doing the GUI questioning aren't asking highly in-depth "trick" questions, either. They're just asking the basics and these people are all crashing and burning.Cramming or not, the skill level and quality of Developer that has been showing up for interviews has been deplorable lately.Sun, 03 Feb 2013 10:36:06 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]Steve Jones - SSC Editor (1/22/2013)[/b][hr][quote][b]Jeff Moden (1/18/2013)[/b][hr][quote][b]lewandot (1/17/2013)[/b][hr]You can teach them SQL.[/quote]I'm finding that to be less and less true. Some people will never actually get it.[/quote]I'm not sure that's true. I do think that there are limits to what you can teach people. Learning to do basic aggregates, joins, and queries I think is something most people get. Going beyond that to CTEs, partitions, APPLY, can be confusing.[/quote]I guess I'll have to agree to disagree. To me, learning just the basics isn't a form of "getting it". It's like saying that someone knows how to sew because they can thread a needle and manage to jab it through 2 pieces of cloth without drawing blood. ;-)Sun, 03 Feb 2013 10:21:20 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxIt is virtually impossible to pass a white boarding technical/dev interview if you dont have experience with the required skill set.In my experience with interviewing for technical analyst positions it is vastly more important to be able to clearly communicate your prior experiences. The coding required is often basic and (select from where less then, etc) ... But it can be challenging to remember what lessons you learned on a 6 month gig 5 years ago and have it be part of a continuous story. This is what much of my night before cramming and rehearsals consist of.Sun, 03 Feb 2013 02:51:13 GMTnopeqwertyhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]majorbloodnock (1/21/2013)[/bIf your company is happy with your hiring decisions, then keep doing it the way you do. However, unless you experience a far higher staff turnover than your competitors, I suspect your choices take attitude into account far more than either you're letting on or you realise.[/quote]No turn over rate to speak of..:-DTue, 22 Jan 2013 12:03:09 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]Jeff Moden (1/18/2013)[/b][hr][quote][b]lewandot (1/17/2013)[/b][hr]You can teach them SQL.[/quote]I'm finding that to be less and less true. Some people will never actually get it.[/quote]I'm not sure that's true. I do think that there are limits to what you can teach people. Learning to do basic aggregates, joins, and queries I think is something most people get. Going beyond that to CTEs, partitions, APPLY, can be confusing.Tue, 22 Jan 2013 09:54:52 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]Jeff Moden (1/18/2013)[/b][hr][quote][b]lewandot (1/17/2013)[/b][hr]You can teach them SQL.[/quote]I'm finding that to be less and less true. Some people will never actually get it.[/quote]Unfortunately, it appears to be true to programming in general. Or rather you can get "them" to produce the lines of code that may work but it is far from professional systems development. It is harder do get people who can do things "right" (or just well).SQL is just prevalent here because it is the contextual tip of the iceberg.Mon, 21 Jan 2013 02:48:06 GMTGary Vargahttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]TravisDBA (1/18/2013)[/b][hr][quote][b]majorbloodnock (1/18/2013)[/b][hr]Skills can be taught, but only if the person has basic ability. Obviously, taking someone on who has potential and then teaching them costs money and takes time. Fundamentally, though, the potential has to be there to think like a DBA or the investment will be a waste.On the flip side, high pressure out of hours emergency situations occur relatively infrequently (at least, one would hope so, or there's a bigger problem at work here). The bread and butter work of backing up, maintaining, tuning and improving databases is a daily team effort. If you hire someone with glittering skills who doesn't fit in with the team, you'll impact the team's performance adversely. The CIO may well only care about results, but not just results in an emergency.[/quote]Yes, skills can be taught but many DBA's simply don't have the time for that, that is why they are hiring an extra person in the first place. I need a guy/gal that can hit the ground running and get our objectives and servers covered immediately, not sometime next year. I do not need to pay someone that it going to possibly take me months to get up to speed. There is not enough time for that in a fast paced shop.[/quote]It's not the DBA who needs to make time, it's the company. If a company takes someone on knowing training is necessary, they have to make both the training and the time available. If they can't, they shouldn't take the person on.[quote]Also, on the flip side of that, low pressure 9-5 situations ONLY occur infrequently based on the shop you are in. Most IT shops of today are very high paced, high-pressure, and need 24/7 coverage.[/quote]Who's talking about low pressure? I was talking about emergency situations, and they should occur infrequently whether the IT department is 9 to 5 or 24/7. If that's not the case, there's a bigger issue going on than just one DBA. [quote]If I am on an airplane it does not matter to me that the pilot is the nicest guy on the plane.If I am laying on an operating table it does not matter to me if the surgeon is the most jovial guy in there.[/quote]If I'm on an aeroplane, I want the pilot and copilot to work together well as a team. There are plenty of documented instances of crashes that could have been avoided if this had happened. What I [b][i]don't[/i][/b] want is a brilliant solo pilot trying to go it alone.If I'm having an operation, I want the surgeons, theatre matron, nurses, anaesthetist and so on to work together as a team. I want them concentrating on their jobs and on me, not on their latest spat with a brilliant medic who can't fit in.[quote]What matters to me is their expertise and their experience to perform under pressure when it really counts. I approach looking for an experienced DBA the same way. I am not going to turn a company multi-million dollar revenue database over to a "nice guy" that I have to teach SQL to.[/quote]When in doubt, extrapolate to extremes.....No-one suggested giving a senior position to someone with no prior experience, nice or otherwise. However, if you only hire people with all the necessary experience, they won't be challenged in the role and will leave pretty soon after. Almost all the time you need to hire someone who's up to the job, but where the job represents a bit of a step up for them. And that means expecting to have to extend their skills. As I said before, as long as the basic ability is there, skills can be taught, but attitude cannot.[quote]Sorry, but as long as I'm ultimately responsible for the production databases, my priorities are different in who I decide to hire. I would rather one of my DBA's piss off a developer because he won't let her get what she wants when she wants it, than to have him cave in and end up screwing up a database trying to be a nice guy to everyone.:-D[/quote]I'd expect a DBA to know how to say no nicely. If they have to get more direct, so be it, but there's no need for them to do so rudely. If they do so reasonably and the other party still gets annoyed, it's not the DBA who's being disruptive. Oh, and if the DBA is inclined to cave in to appease, that's a different attitude problem. As I said before, if the ability is there, you can teach skills, but you can't teach the right attitude.If your company is happy with your hiring decisions, then keep doing it the way you do. However, unless you experience a far higher staff turnover than your competitors, I suspect your choices take attitude into account far more than either you're letting on or you realise.Mon, 21 Jan 2013 02:08:58 GMTmajorbloodnockhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]lewandot (1/17/2013)[/b][hr]You can teach them SQL.[/quote]I'm finding that to be less and less true. Some people will never actually get it.Fri, 18 Jan 2013 14:35:29 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxI'd agree with that, which is why I put in the caveat of managing expectations. There are definitely times you have to lay down the law and to hell with who gets upset. I'd start off trying to do it 'nicely' but if someone won't accept it, well................Fri, 18 Jan 2013 10:29:39 GMTgeorge sibbaldhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]george sibbald (1/18/2013)[/b][hr] I don't think they have to be nice either and DBAs should certainly never be pushovers, but they have to be team players, approachable and helpful whilst still managing expectations.[/quote]I absolutely agree George, and DBA's should be team players, but they are also the caretakers for the million dollar production databases as well and many times the production databases access, integrity, and safekeeping takes precedence. That's just the way it is. It's not the teams neck or job that's on the line when a production database has been screwed up because the DBA was trying to accomodate everyone. It's the DBA's ultimate responsibility. The buck stops with him/her many times. They have incredible responsibility on their shoulders and people need to be aware of that. A mentor once told me, "Travis you can be a great DBA and you can be a cooperative team player too, but you will find many times you can't always be both at the same time." Man, was he ever right..:-DFri, 18 Jan 2013 10:18:49 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxmight be getting bogged down in the term 'nice' here. I don't think they have to be nice either and DBAs should certainly never be pushovers, but they have to be team players, approachable and helpful whilst still managing expectations.Save being unpleasant for those deserving of it.Back on topic, as for cramming, it will only get you so far if you don't have the experience to back it up, but the interview would have to be more in depth than checking knowledge of syntax to find people out.Fri, 18 Jan 2013 10:04:30 GMTgeorge sibbaldhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]majorbloodnock (1/18/2013)[/b][hr][quote][b]. Skills can be taught, but only if the person has basic ability. Obviously, taking someone on who has potential and then teaching them costs money and takes time. Fundamentally, though, the potential has to be there to think like a DBA or the investment will be a waste.On the flip side, high pressure out of hours emergency situations occur relatively infrequently (at least, one would hope so, or there's a bigger problem at work here). The bread and butter work of backing up, maintaining, tuning and improving databases is a daily team effort. If you hire someone with glittering skills who doesn't fit in with the team, you'll impact the team's performance adversely. The CIO may well only care about results, but not just results in an emergency.[/quote]Yes, skills can be taught but many DBA's simply don't have the time for that, that is why they are hiring an extra person in the first place. I need a guy/gal that can hit the ground running and get our objectives and servers covered immediately, not sometime next year. I do not need to pay someone that it going to possibly take me months to get up to speed. There is not enough time for that in a fast paced shop.Also, on the flip side of that, low pressure 9-5 situations ONLY occur infrequently based on the shop you are in. Most IT shops of today are very high paced, high-pressure, and need 24/7 coverage. If I am on an airplane it does not matter to me that the pilot is the nicest guy on the plane.If I am laying on an operating table it does not matter to me if the surgeon is the most jovial guy in there.What matters to me is their expertise and their experience to perform under pressure when it really counts. I approach looking for an experienced DBA the same way. I am not going to turn a company multi-million dollar revenue database over to a "nice guy" that I have to teach SQL to. Sorry, but as long as I'm ultimately responsible for the production databases, my priorities are different in who I decide to hire. I would rather one of my DBA's piss off a developer because he won't let her get what she wants when she wants it, than to have him cave in and end up screwing up a database trying to be a nice guy to everyone.:-DFri, 18 Jan 2013 09:48:48 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]TravisDBA (1/17/2013)[/b][hr][quote][b]lewandot (1/17/2013)[/b][hr]I don't care if they hire someone who crammed for the interview, came up through the ranks or have been a DBA for 20 years. I wish managers would hire people who know how to get along with other people. You can teach them SQL. Their parents had to teach them how to be nice, and for some it's too late.[/quote]The nicest person in the world doesn't mean anything if they don't have the necessary skills needed to get your production databases operational in an off hours emergency situation, period. Very skilled DBA's are not paid to win a personality contest, bottom line. They are paid to [b]keep their company's very valuable muilt-million dollar databases online and accessible 24/7 to the user community[/b], bottom line. Everything else is secondary, as my past CIO used to say. Playing nice is a good thing to want, but it is not at the top of most CIO's list. Skill-set and working under pressure is. As far as teaching people SQL. Most DBA's I know don't have time for that, that is why they are hiring extra help to begin with. If being nice is at the top of your list maybe working in a flower shop might suit you better. In the fast paced IT world of today, companies are looking for particular skillsets and people that can produce under pressure and hit the ground running.. Most industrial IT shops today that I know of are not looking to pay to teach people SQL . :-D[/quote]Yes and no, on both sides.The nicest person in the world doesn't mean anything if they don't have the [strike]necessary skills needed to get your production databases operational in an off hours emergency situation, period[/strike] ability to learn the necessary skills. Skills can be taught, but only if the person has basic ability. Obviously, taking someone on who has potential and then teaching them costs money and takes time. Fundamentally, though, the potential has to be there to think like a DBA or the investment will be a waste.On the flip side, high pressure out of hours emergency situations occur relatively infrequently (at least, one would hope so, or there's a bigger problem at work here). The bread and butter work of backing up, maintaining, tuning and improving databases is a daily team effort. If you hire someone with glittering skills who doesn't fit in with the team, you'll impact the team's performance adversely. The CIO may well only care about results, but not just results in an emergency.Fri, 18 Jan 2013 02:09:47 GMTmajorbloodnockhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]george sibbald (1/17/2013)[/b] Unless you are a one man shop its a lot easier to get things done if you haven't p*ssed everyone else off. :-)[/quote]There is a flip side to that coin you are not considering here. If you can't get things done in a pressure situation your jovial personaiity doesn't matter to most managers I know of. They are not paying you to be nice, they are paying you to produce and keep their production databases online and operational 24/7, bottom line. Not everyone out there can do that. There are a lot of nice people in the world, I know many of them, but I wouldn't let them touch my own personal laptop at home, let alone my production databases at work!!! Nice is a good thing to want, but like I said it is usually not at the top of the list of most managers I know of today.:-DThu, 17 Jan 2013 10:34:22 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]TravisDBA (1/17/2013)[/b][hr][quote][b]lewandot (1/17/2013)[/b][hr]I don't care if they hire someone who crammed for the interview, came up through the ranks or have been a DBA for 20 years. I wish managers would hire people who know how to get along with other people. You can teach them SQL. Their parents had to teach them how to be nice, and for some it's too late.[/quote]The nicest person in the world doesn't mean anything if they don't have the necessary skills needed to get your production databases operational in an off hours emergency situation, period. Very skilled DBA's are not paid to win a personality contest, bottom line. They are paid to [b]keep their company's very valuable muilt-million dollar databases online and accessible 24/7 to the user community[/b], bottom line. Everything else is secondary, as my past CIO used to say. Playing nice is a good thing to want, but it is not at the top of most CIO's list. Skill-set and working under pressure is. As far as teaching people SQL. Most DBA's I know don't have time for that, that is why they are hiring extra help to begin with. If being nice is at the top of your list maybe working in a flower shop might suit you better. In the fast paced IT world of today, companies are looking for particular skillsets and people that can produce under pressure and hit the ground running.. Most industrial IT shops today that I know of are not looking to pay to teach people SQL . :-D[/quote].....having said that most companies are looking for soft skills as well and won't hire (permanent) people they don't think will fit in with the current team. Unless you are a one man shop its a lot easier to get things done if you haven't p*ssed everyone else off. :-)Thu, 17 Jan 2013 10:27:41 GMTgeorge sibbaldhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]lewandot (1/17/2013)[/b][hr]I don't care if they hire someone who crammed for the interview, came up through the ranks or have been a DBA for 20 years. I wish managers would hire people who know how to get along with other people. You can teach them SQL. Their parents had to teach them how to be nice, and for some it's too late.[/quote]The nicest person in the world doesn't mean anything if they don't have the necessary skills needed to get your production databases operational in an off hours emergency situation, period. Very skilled DBA's are not paid to win a personality contest, bottom line. They are paid to [b]keep their company's very valuable muilt-million dollar databases online and accessible 24/7 to the user community[/b], bottom line. Everything else is secondary, as my past CIO used to say. Playing nice is a good thing to want, but it is not at the top of most CIO's list. Skill-set and working under pressure is. As far as teaching people SQL. Most DBA's I know don't have time for that, that is why they are hiring extra help to begin with. If being nice is at the top of your list maybe working in a flower shop might suit you better. In the fast paced IT world of today, companies are looking for particular skillsets and people that can produce under pressure and hit the ground running.. Most industrial IT shops today that I know of are not looking to pay to teach people SQL . :-DThu, 17 Jan 2013 10:10:27 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxI read through this topic, and it's becoming very personal for me...Later today I have a short phone screen, tomorrow an over-the-phone tech screen for a new position.I'm actually trying hard to NOT cram for this. After all, I'd rather be hired for what I know now, than what I managed to cram in and likely will forget 5 minutes after I hang up the phone...JasonThu, 17 Jan 2013 10:09:51 GMTjasona.workhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxThe interview I had for my current job was 3 part, technical phone then face to face technical / personal along with on line testing and lastly panel. At each stage there was a hidden agenda so that the full nature of the interview was never revealed before hand. Therefore you would have to cram at least twice and it may not be needed.Might sound a bit cloak and dagger but my company has tested it over many years and it doesn't often fail them.Thu, 17 Jan 2013 08:58:14 GMTStuart Davieshttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxI don't care if they hire someone who crammed for the interview, came up through the ranks or have been a DBA for 20 years. I wish managers would hire people who know how to get along with other people. You can teach them SQL. Their parents had to teach them how to be nice, and for some it's too late.Thu, 17 Jan 2013 07:36:11 GMTlewandothttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]Eoin_BI (1/15/2013)[/b][hr]To your main theme, check this link for the best way (scientifically tested) to learn. (Flash Cards)http://ideas.time.com/2013/01/09/highlighting-is-a-waste-of-time-the-best-and-worst-learning-techniques/[/quote]Thanks for the link. Interesting article. I have also found that taking notes is a big help even if I don't look back at them. Somehow writing out something helps put it into my brain.Wed, 16 Jan 2013 14:14:48 GMTmarcia.j.wilsonhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]hakim.ali (1/16/2013)[/b][hr]On the topic of cramming for interviews, I have an experience I'd like to share. At my office, we do semi-technical phone screens before we bring the person in for a face-to-face interview, to save everybody's time if the candidate isn't up to snuff. One guy we screened had an 8-page resume that made him look like a SQL Server guru. Did amazingly well on the phone screen. When he showed up in person, he didn't know the first thing about SQL Server. The interview was over in about 3 minutes, because he could not answer the most basic questions (for example, didn't know what a stored procedure was, didn't know what normalization was). Apparently, he got somebody else to take the phone screen for him!Side note: why does anybody need an 8-page resume? I find anything more than 2 pages tedious to read. Anything more than 4 pages, I'm inclined to send it to the recycle bin, because most of the times it's repetition and difficult to read and badly formatted and just not worth the time.[/quote]Definitely an interesting one! Makes me curious what he thought would happen when he showed up and suddenly didn't know the things that "he" knew on the phone. Did he not expect to have more questions? Interesting.And totally agree on the resume bit. At the very least, summarize in about half a page right at the beginning of the thing. There are people with extensive work histories, especially if they've done a lot of short-term contracts (nothing wrong with that, of course), but it needs a brief summary up front.Wed, 16 Jan 2013 10:24:19 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxOn the topic of cramming for interviews, I have an experience I'd like to share. At my office, we do semi-technical phone screens before we bring the person in for a face-to-face interview, to save everybody's time if the candidate isn't up to snuff. One guy we screened had an 8-page resume that made him look like a SQL Server guru. Did amazingly well on the phone screen. When he showed up in person, he didn't know the first thing about SQL Server. The interview was over in about 3 minutes, because he could not answer the most basic questions (for example, didn't know what a stored procedure was, didn't know what normalization was). Apparently, he got somebody else to take the phone screen for him!Side note: why does anybody need an 8-page resume? I find anything more than 2 pages tedious to read. Anything more than 4 pages, I'm inclined to send it to the recycle bin, because most of the times it's repetition and difficult to read and badly formatted and just not worth the time.Wed, 16 Jan 2013 10:05:10 GMThakim.alihttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxPatric, normally I'd treat private as private. You're the only person I've ever moved it public for. And it's only because I find your particular behavior so reprehensible that I feel that helping you hide that kind of hatefulness would be a mistake. I feel that others need the warning about your behavior, so that they can at least be informed before you attack them. Kind of like the "do not play on or around" signs on trash compactors.I know you think you're the innocent party here. That's normal for your personality type. You belittle, insult, ridicule, and then claim that you were the one wronged by a person who confronts you on any of that. It's normal for you. I understand that. But there's just no way I'm going to stand aside and let you attack people with impunity. I don't stand for attempted bullying. Not of me, not of anyone.Others will need to judge whether they think I'm the aggressor here. That's why I present the data I do. People will come to their own conclusions. Some may decide that I'm the problem. I hope not, but it's their judgement to make, and my job in that is simply to provide them with the most accurate data I can on our interactions and on all of my thousands of interactions with others (besides you) on these forums. As needed, I can provide full and complete context, including timeline, etc. If Steve or anyone else wants that, I'll provide it without the slightest qualm.I don't expect you to change your behavior because of anything I do or post. But I do hope that anyone reading this is warned what kind of person you are, and thus doesn't get hurt by your bullying. These posts aren't for you, they're for anyone else who reads them.Wed, 16 Jan 2013 09:55:20 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]majorbloodnock (1/16/2013)[/b][hr][quote][b]patrickmcginnis59 (1/15/2013)[/b][hr]Let me try working through a few variables on this one!If the interviewee is going to fool a completely competent and prepared interviewer, he's going to fool the SQL forums and get his answers. (I'm obviously mistakenly ommitting the geniuses here who will see through every scheme no matter how sophisticated by the sheer power of their perception, but in that case I'm an ordinary joe that can subsequently answer questions the faker posts because well I'm an ordinary joe and Steves advice does not apply to me in this case.)If the interviewee is not going to fool a completely competent and prepared interviewer, will he fool the SQL forums and get his answers? If I find him out, I'm going to answer him but tell him it sounds like he wants to cheet and will probably fail because if I'm an ordinary joe unskilled in HR and spotted his dastardly scheme, the competent HR department will surely find him out! If the interviewee is going to have an incompetent and unprepared interviewer, do we reward incompetence and lack of preparation by refusing to answer questions in order to protect the incompetent and unprepared interviewer? Or might this somehow dilute free market forces that would otherwise penalize incompetence and lack of preparation? How about the many different degrees of competence on either of the interview participants part? How does that pan out?Additionally, if an applicant is truly dishonest (and especially good at being dishonest), are we saying he's going to fool the interviewer but not the forum participants? Heck, he's got an easier job fooling forum participants because by definition in his participation here he's not providing answers, he's formulating questions![/quote]The posts from GSquared and Jeff Moden have covered pretty well the detail of what you've outlined, but I can't help thinking this is missing the point a bit. It may, of course, be a simple difference of interpretation, but I didn't read the editorial as an attempt to make all SSC members into interview police. All I saw was a blatant message to cheats that they're doing no-one any favours, and a secondary message to SSC members encouraging them to temper their natural helpfulness with a modicum of worldliness.Yes, there is, and always will be, quite a bit of game play going on. DBAs are well paid generally, so there will always be some who want to muscle in on the lucrative side before their experience warrants it. Same with most good careers. None of us will be able to stop it, but we don't have to make it unnecessarily easy for fraudsters.[/quote]Thanks for the well considered response!The subject was pretty easy to reach a conclusion on, it wasn't a hard subject to play out in my mind. I'm not going to spot the really skilled cheaters, I'm not going to sweat the comically bad cheaters and I'm going to insist that the focus needs to be on the hiring process from the point of view of the hirer. I think Jeff actually has the best take on this, and I wish more folks would focus on that side of the process rather than letting the interviewers off the hook unconditionally.I know that in modern times management is considered a skill in itself, but can we really be effective managers without the ability to at least research the tasks that our employees will be engaged in? Or is this just somehow out of style nowadays? Sounds like maybe thats what I need to consider from Steve's post, and maybe he's just in a roundabout manner giving me some bad news in this department. I can certainly now accept that for my own consideration!Wed, 16 Jan 2013 08:56:25 GMTpatrickmcginnis59http://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]Lynn Pettis (1/15/2013)[/b][hr]Okay, just curious. I had a phone interview a while back (about a year) and I am pretty sure I didn't get a call back because I couldn't list off the DBCC Commands, even though I told them I would look them up in Books Online if I needed them.[/quote]I've been doing SQL for 10+ years and I don't know many of the DBCC commands offhand and their syntax. That they expect you to know them well means that someone is doing way too much DR work. :w00t:The position a production DBA should be able assume on a regular basis is feet up on the desk, cup of coffee at hand and listening to the latest podcast from Steve Jones. :-DWed, 16 Jan 2013 08:22:42 GMTJim P.http://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]patrickmcginnis59 (1/15/2013)[/b][hr]Let me try working through a few variables on this one!If the interviewee is going to fool a completely competent and prepared interviewer, he's going to fool the SQL forums and get his answers. (I'm obviously mistakenly ommitting the geniuses here who will see through every scheme no matter how sophisticated by the sheer power of their perception, but in that case I'm an ordinary joe that can subsequently answer questions the faker posts because well I'm an ordinary joe and Steves advice does not apply to me in this case.)If the interviewee is not going to fool a completely competent and prepared interviewer, will he fool the SQL forums and get his answers? If I find him out, I'm going to answer him but tell him it sounds like he wants to cheet and will probably fail because if I'm an ordinary joe unskilled in HR and spotted his dastardly scheme, the competent HR department will surely find him out! If the interviewee is going to have an incompetent and unprepared interviewer, do we reward incompetence and lack of preparation by refusing to answer questions in order to protect the incompetent and unprepared interviewer? Or might this somehow dilute free market forces that would otherwise penalize incompetence and lack of preparation? How about the many different degrees of competence on either of the interview participants part? How does that pan out?Additionally, if an applicant is truly dishonest (and especially good at being dishonest), are we saying he's going to fool the interviewer but not the forum participants? Heck, he's got an easier job fooling forum participants because by definition in his participation here he's not providing answers, he's formulating questions![/quote]The posts from GSquared and Jeff Moden have covered pretty well the detail of what you've outlined, but I can't help thinking this is missing the point a bit. It may, of course, be a simple difference of interpretation, but I didn't read the editorial as an attempt to make all SSC members into interview police. All I saw was a blatant message to cheats that they're doing no-one any favours, and a secondary message to SSC members encouraging them to temper their natural helpfulness with a modicum of worldliness.Yes, there is, and always will be, quite a bit of game play going on. DBAs are well paid generally, so there will always be some who want to muscle in on the lucrative side before their experience warrants it. Same with most good careers. None of us will be able to stop it, but we don't have to make it unnecessarily easy for fraudsters.Wed, 16 Jan 2013 03:07:04 GMTmajorbloodnockhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]Jim P. (1/15/2013)[/b][hr][quote][b]Lynn Pettis (1/15/2013)[/b][hr]Just curious, do you expect DBAs to have the syntax of the various DML statements memorized?[/quote]No. I just expect them to know the DML verbs at least. The general syntax doesn't hurt. I just want the verbs. And TRUNCATE I consider more of a DDL than a DML, and is not really a DML statement..The syntax is sort of DB specific. But the same four DML verbs are pretty consistent among the SQL-92 standard languages.[/quote]Okay, just curious. I had a phone interview a while back (about a year) and I am pretty sure I didn't get a call back because I couldn't list off the DBCC Commands, even though I told them I would look them up in Books Online if I needed them.Tue, 15 Jan 2013 23:18:43 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]Lynn Pettis (1/15/2013)[/b][hr]Just curious, do you expect DBAs to have the syntax of the various DML statements memorized?[/quote]No. I just expect them to know the DML verbs at least. The general syntax doesn't hurt. I just want the verbs. And TRUNCATE I consider more of a DDL than a DML, and is not really a DML statement..The syntax is sort of DB specific. But the same four DML verbs are pretty consistent among the SQL-92 standard languages.Tue, 15 Jan 2013 23:13:26 GMTJim P.http://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]Jim P. (1/15/2013)[/b][hr]I'm mostly a production DBA. Keep 'em up, running and tuned. I'm also responsible for front line troubleshooting of our software, and database issues. I've done about 15 different DB systems from dBase III to Oracle and MS SQL. I also can program fairly well in VBA, T-SQL, and SQLPlus. I've also done batch files, VBScript and touched other languages as needed.I've been in interviews where the DBA's interviewing me were Oracle, but I can answer in their language as well.Now I am occasionally on the tech interviewer side. The first question I generally hit a DBA interviewee with is "What do 'DDL' and 'DML' stand for?" Then I start to delve into the DML command side. I have as yet to get to the DDL with a junior DBA. I'll also hit them with recovery models and such.If they have no clue, but show intelligence and honesty in their answers -- I can deal with that. I can train them. If they can't even retain the DML commands after I give them the answer -- they are a waste of time. It's a question of how to end the interview gently.[/quote]Just curious, do you expect DBAs to have the syntax of the various DML statements memorized?Tue, 15 Jan 2013 21:07:09 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxI'm mostly a production DBA. Keep 'em up, running and tuned. I'm also responsible for front line troubleshooting of our software, and database issues. I've done about 15 different DB systems from dBase III to Oracle and MS SQL. I also can program fairly well in VBA, T-SQL, and SQLPlus. I've also done batch files, VBScript and touched other languages as needed.I've been in interviews where the DBA's interviewing me were Oracle, but I can answer in their language as well.Now I am occasionally on the tech interviewer side. The first question I generally hit a DBA interviewee with is "What do 'DDL' and 'DML' stand for?" Then I start to delve into the DML command side. I have as yet to get to the DDL with a junior DBA. I'll also hit them with recovery models and such.If they have no clue, but show intelligence and honesty in their answers -- I can deal with that. I can train them. If they can't even retain the DML commands after I give them the answer -- they are a waste of time. It's a question of how to end the interview gently.Tue, 15 Jan 2013 21:03:45 GMTJim P.http://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxAs those that have come to know me over the years will tell you, this is a REALLY sore spot with me especially for people that have alphabet soup after their name.I can absolutely guarantee that there is no way to "cram" for a "Jeff Moden" interview. Although I don't ask difficult questions, I can guarantee that only a couple of the questions I ask are actually on one of those God forsaken interview question blogs. Those are used as "warmup" guestions to get the inteviewer to relax because everybody knows the answers. After that, you're required to actually think or show what you've [i]actually [/i]done in the past in the form of thoughful dialog.I used to be incensed by people that published those damned interview questions and even more incensed by moroffs that used them for anything other than, perhaps, a study guide of what they need to try, practice, and verify. Then, it dawned on me that a good number of those bloody sites had some really stupid and incorrect answers and so decided that I'd not correct the answers nor even acknowledge that some of the answers were wrong. In fact, I've taken to using those incorrectly answered questions as the warmup questions. Lord help the gamers that come to an interview with me and give me one of those incorrect answers. We will find out if they like high velocity pork chops or not.Tue, 15 Jan 2013 16:03:50 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]patrickmcginnis59 (1/15/2013)[/b][hr]Let me try working through a few variables on this one!If the interviewee is going to fool a completely competent and prepared interviewer, he's going to fool the SQL forums and get his answers. (I'm obviously mistakenly ommitting the geniuses here who will see through every scheme no matter how sophisticated by the sheer power of their perception, but in that case I'm an ordinary joe that can subsequently answer questions the faker posts because well I'm an ordinary joe and Steves advice does not apply to me in this case.)[/quote]It's usually pretty easy to spot most interview questions on the forums. Not always, but it doesn't take any particular perception skills to know that, "What are the differences between temp tables and table variables?" is frequently an interview question. Can be a valid forum question, in which case, answering it the next day works for a valid question, and defeats the interview-hack (the interview is probably long-since over). Foolproof? Nope. But it's probably as good as we'll get on this situation.[quote]If the interviewee is not going to fool a completely competent and prepared interviewer, will he fool the SQL forums and get his answers? If I find him out, I'm going to answer him but tell him it sounds like he wants to cheet and will probably fail because if I'm an ordinary joe unskilled in HR and spotted his dastardly scheme, the competent HR department will surely find him out![/quote] That works. If you think it's a test/homework/interview question, ask. I do that pretty frequently. Again, delaying the answer by a bit is usually enough to make it still valuable to someone who's on the forums to learn, and to defeat the purpose of a cheat.[quote]If the interviewee is going to have an incompetent and unprepared interviewer, do we reward incompetence and lack of preparation by refusing to answer questions in order to protect the incompetent and unprepared interviewer? Or might this somehow dilute free market forces that would otherwise penalize incompetence and lack of preparation?[/quote] The interviewer isn't usually trying to defraud anyone. They're doing their best effort to fix a business-problem by paying for expertise. Not always the case, but it is most of the time. It would be dishonest of a business to hire someone and then not pay them, but it's not dishonest of them to hire someone to fill a gap in their knowledge assets. It's difficult, and has risks, but it's honest. Trying to interview for a job you can't actually do is inherently dishonest. It's trying to take money from someone without providing any value to them. Definition of fraud/theft/scam.[quote]How about the many different degrees of competence on either of the interview participants part? How does that pan out?Additionally, if an applicant is truly dishonest (and especially good at being dishonest), are we saying he's going to fool the interviewer but not the forum participants? Heck, he's got an easier job fooling forum participants because by definition in his participation here he's not providing answers, he's formulating questions![/quote]We can't catch every attempt. Some will be more clever than we can deal with in this medium. No way around that. Something like 80% of all murders in the US go unsolved every year, and a lot more effort and expertise goes into those than will ever go into trying to catch out interview/exam cheats, and for darn good reason (not even vaguely the same order of magnitude). So I'm sure we miss quite a few. But that's not a valid reason to ignore the ones we could prevent, or at least call-out.Generally, I start out by trusting everyone. Assume that even seemingly dishonest/unscrupulous looking activities are probably not because of actual intent. Life is more pleasant when you assume you can trust people till proven otherwise. But I will ask, "This looks like an interview question. Is it?", if it does look that way. And quite a few people will admit that it is, and then I'll work with them so they can learn for future interviews. I'll refer them to source material (usually MSDN or TechNet) that they can study for their next go. Most often, even the people who are trying to "cheat", will straighten out when confronted on it. Only about 2.5-3% of humanity is willfully criminal, but some of the rest need some guidance on matters of ethics, etc.Tue, 15 Jan 2013 14:36:39 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxLet me try working through a few variables on this one!If the interviewee is going to fool a completely competent and prepared interviewer, he's going to fool the SQL forums and get his answers. (I'm obviously mistakenly ommitting the geniuses here who will see through every scheme no matter how sophisticated by the sheer power of their perception, but in that case I'm an ordinary joe that can subsequently answer questions the faker posts because well I'm an ordinary joe and Steves advice does not apply to me in this case.)If the interviewee is not going to fool a completely competent and prepared interviewer, will he fool the SQL forums and get his answers? If I find him out, I'm going to answer him but tell him it sounds like he wants to cheet and will probably fail because if I'm an ordinary joe unskilled in HR and spotted his dastardly scheme, the competent HR department will surely find him out! If the interviewee is going to have an incompetent and unprepared interviewer, do we reward incompetence and lack of preparation by refusing to answer questions in order to protect the incompetent and unprepared interviewer? Or might this somehow dilute free market forces that would otherwise penalize incompetence and lack of preparation? How about the many different degrees of competence on either of the interview participants part? How does that pan out?Additionally, if an applicant is truly dishonest (and especially good at being dishonest), are we saying he's going to fool the interviewer but not the forum participants? Heck, he's got an easier job fooling forum participants because by definition in his participation here he's not providing answers, he's formulating questions!Tue, 15 Jan 2013 13:21:28 GMTpatrickmcginnis59http://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]GSquared (1/15/2013)[/b][hr][quote][b]majorbloodnock (1/15/2013)[/b][hr][quote][b]GSquared (1/15/2013)[/b][hr][quote][b]majorbloodnock (1/15/2013)[/b][hr][quote][b]Gary Varga (1/15/2013)[/b][hr]....[/quote]....[/quote]....[/quote]....[/quote]Pretty much matches the interview process I prefer when I'm managing.I pay minimal attention to skillsets I can't verify, but aim for honest, intelligent, and energetic. I can turn that kind of person into any sort of technical expert I need, regardless of their resume experience or lack thereof. Can't turn educated but dishonest into anything useful.[/quote]Agree totally. Skills can be taught, but attitude cannot.Tue, 15 Jan 2013 10:11:17 GMTmajorbloodnockhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]majorbloodnock (1/15/2013)[/b][hr][quote][b]GSquared (1/15/2013)[/b][hr][quote][b]majorbloodnock (1/15/2013)[/b][hr][quote][b]Gary Varga (1/15/2013)[/b][hr]A reasonable interview will test deeper understanding, however, the biggest problem is that some interviews are conducted so poorly these people that "learn by cramming" sometimes succeed. If they didn't then it wouldn't be worthwhile trying it on and therefore wouldn't be an issue.[/quote]To an extent, I agree. Cramming only helps with facts, and detailed facts at that. It doesn't do anything for understanding concepts. The value of a decent DBA is their ability to understand concepts and theory, and put that understanding into practice, so that's what an interview should be attempting to tease out.That said, this world is full enough of charlatans as it is, so whilst I'm tempted to say any blagger and any [b]company lax enough to hire them [/b]deserve each other, I certainly wouldn't want to do anything to help introduce them. After all, despite my best efforts, it may be my details they end up working on.[/quote]The problem with the part I added emphasis to, is that quite often a company needs to hire a DBA because they don't have anyone who knows anything significant about the subject. So they really can't effectively screen against fraudulent interviewees.The usual answer I see on that one is, "pay someone to do the tech screening for you". But how can a company know whether or not the person/company doing the tech screening knows their business or not?I've had technical interviews by people, frequently at recruiting companies, who quite obviously didn't know SQL well enough to detect whether I did or not. Questions like, "why are table variables faster than temp tables", and when I reply that they aren't, and provide details on why, and explain that it's a "DBA urban legend", they start to look like deer in the headlights. I swear, when those people ask their second question (usually, "what recovery models do SQL databases have"), I could tell them that "SQL Server doesn't actually use recovery models. It uses azimuths generated by flux capacitors to power the warp coils for wormhole navigation", and they'd be so intimidated by the reply to the first question that they'd believe me.So how can a normal small business tell? That's why so many small businesses end up with people who can baffle with BS instead of actually competent technical personnel. See it all the time.[/quote]Hmmm. Yes and no.You're quite right, of course, that I was being overly flippant, and I hold my hands up; guilty as charged.However, there still exists the problem of how a company needing skills about which they've no prior experience can successfully interview. I was certainly being unfair to label them as lax by lumping them straight in with those that only go through the motions. However, I'll argue that if you don't have the technical expertise to spot a blagger, you shouldn't attempt to perform a technical interview per se; if you do, you effectively become another blagger and it's just a contest of who blags the best. I'd argue instead that the company should concentrate rather harder on understanding the candidate's attitude and outlook, and scrutinising closely their past professional experience. In short, interview harder in the areas you really are qualified to judge. If you can enlist outside help to judge technical excellence, great. Ditto if you can find any other way to give you an interviewing edge.Personally, I see a lot of small companies balk at the cost of a DBA, so try to enter into the world of databases on the cheap by trying to take on someone who's only starting out in that area. It's arguably better value to look for someone with quantifiable prior experience which, whilst not eliminating the risk, swings the odds more in your favour that you'll get someone at least half competent.IMHO, of course.....[/quote]Pretty much matches the interview process I prefer when I'm managing.I pay minimal attention to skillsets I can't verify, but aim for honest, intelligent, and energetic. I can turn that kind of person into any sort of technical expert I need, regardless of their resume experience or lack thereof. Can't turn educated but dishonest into anything useful.Tue, 15 Jan 2013 10:07:21 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]Miles Neale (1/15/2013)[/b][hr]Steve, I have to admit that today's editorial is one of the most hard-nosed, direct, hard hearted, and excellent ones you put together and I could not agree with you more. To help a charlatan build a facade to bilk a potential employer is akin to fraud. Not something I would want a part of. Excellent!M.[/quote]ThanksTue, 15 Jan 2013 09:47:06 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspx[quote][b]majorbloodnock (1/15/2013)[/b][hr][quote][b]GSquared (1/15/2013)[/b][hr][quote]The problem with the part I added emphasis to, is that quite often a company needs to hire a DBA because they don't have anyone who knows anything significant about the subject. So they really can't effectively screen against fraudulent interviewees....[/quote]Hmmm. Yes and no.You're quite right, of course, that I was being overly flippant, and I hold my hands up; guilty as charged.Personally, I see a lot of small companies balk at the cost of a DBA, so try to enter into the world of databases on the cheap by trying to take on someone who's only starting out in that area. It's arguably better value to look for someone with quantifiable prior experience which, whilst not eliminating the risk, swings the odds more in your favour that you'll get someone at least half competent.IMHO, of course.....[/quote]I see both sides here. It's hard to hire when you don't know how to evaluate skills. The trick of seeing through BS when you aren't technically skilled isn't one I think most people have. I find that hiring a consultant of some sort to interview for you is common, but it's problematic and expensive. Ultimately finding candidates is hard, and paying 20-30% for a placement firm is bad enough. Adding in what could be another 10-15% for interview time for a consultant is hard.A good reason to retain people when you can and hire good people on recommendations, even if you don't have a slot.Tue, 15 Jan 2013 09:36:42 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxSteve, I have to admit that today's editorial is one of the most hard-nosed, direct, hard hearted, and excellent ones you put together and I could not agree with you more. To help a charlatan build a facade to bilk a potential employer is akin to fraud. Not something I would want a part of. Excellent!M.Tue, 15 Jan 2013 09:26:59 GMTMiles Nealehttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxCramming knowledge for an interview to impress a prospective employer is kind of like stuffing toilet paper into your pants to impress a girl. You are advertising what you don't really have. Bottom line, you either have it or you don't.:-DTue, 15 Jan 2013 07:17:21 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic1407022-263-1.aspxDigression: agreed that cramming to exhibit skills you don't have is misrepresentation. Ironic that Microsoft themselves, in a way, encourage this misrepresentation by way of their poorly written certification exams (SQL Server certifications), which seem to reward rote memorization far more than real knowledge.Tue, 15 Jan 2013 07:05:23 GMThakim.ali