InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 23 May 2013 15:46:56 GMT20http://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxYou WILL learn about the industry in which you're working, you don't have much of a choice. Having previous industry experience really depends, and always, if the employer says you need it, then you need it. You might be able to do some research and get through the interview like Jeff did, you never know.I have experience in the following industries: Medicare/Medicade management, education management, law enforcement, municipal government, medical/taxi transport. And a few others that I can't think of off-hand. But I didn't have experience in any of these before I started the job, just good IT skills and experience.I've always been an advocate that when you start out in IT that you should never stay more than 3-5 years in any given job, you should move between industries and job types to get a better feel for the industry and job that you want to do long-term. Settle down after 10-15 years and grind out that pension. Broader experience will certainly help, a previous boss was impressed that I was an amateur radio operator as it was a taxi/transport company and they use radio heavily.As a DBA, learning your company at a meta-level can have unexpected benefits. When I was working in law enforcement, I had a project with an investigative group that were going after staged traffic accidents that were defrauding insurance companies and causing lots of injuries, and occasionally, fatalities (the scam was started by the Russian Mafia, believe it or not). I worked with them on their surveillance database where they recorded license plates of cars outside of suspects offices. The investigators didn't know about our traffic accident database because traffic accidents are handled and written up by patrol officers. I linked the surveillance database against the traffic accident database and provided additional evidence for them to use when building cases. (I would have gotten a commendation out of it if the head investigator hadn't gotten in trouble over something unrelated)LEARN! You never know when something will click and you can produce something amazingly cool.Thu, 08 Jan 2009 10:29:25 GMTWayne Westhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxI agree. It is somewhat of a short sell of a DBA, which is why we are often written off as mere 'techies' and 'kept out of the way'.I wrote before that you don't need industry expertise to get the job, but once it's in the bag, you should learn what youneed to about the business, because then you can really add value and become a major player within the business, which IMHO DBAs should be. You can find out a lot about the business from the data and metadata in the database(s) and use it to help the business, for example in forecasting business growth. I did some work for a mobile phone operator. They experienced an explosion of growth in one specific area. The data illustrating the transaction growth rate was held in a couple of tables. I was able to plot the growth curve and use it to forecast growth over the following 12 months, which turned out to be more accurate than the marketing department's own forecasts. The direct result was they were able to plan major changes to their systems to cope with this growth, before it swamped them. This is just one example. The deeper you go into your customer's business and the data behind it, the more value you can add and the more interesting the job becomes.HowardMon, 05 Jan 2009 09:24:20 GMTHoward Perryhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxI don't think I'm selling things short. DBAs do a lot of tuning and moving data around. It depends on your job and things I've done heavily in one job, I've rarely done in others. And vice versa.There are mechanics that just change oil, and there are those that tune engines to reach new levels of performance. A DBA could fall into either category, with most of us in between.Mon, 05 Jan 2009 09:01:42 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote][b]Steve Jones - Editor (1/4/2009)[/b][hr]Tweaking code and working with tables is a lot of what we do. We develop new code at times, which may be more or less than other things, but a lot of times we want to mechanically make things work better. We don't case how they are used, and there are domain experts typically in an industry to help us along.[/quote][p]That's an awful way to short sell what it means to be a DBA in particular and the IT profession in general. Reminds me of a boss I had who used to say that a pharmacist is someone who moves tablets from big bottles to small ones all day long.[/p]Mon, 05 Jan 2009 08:42:12 GMTsjsubscribehttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxIf the client / employer has a problem and believes you have the expertise to solve it, whether or not your eyes glaze over at the mention of 'credit default swaps', is not normally an issue, provided you are able to absorb any industry knowledge, he/she thinks is relevant. If the job is just to make up the numbers for the headcount budget, I would almost expect a demand for relevant industry experience. In such a case. you may not be interested in it anyway.In 30 years of IT, working on 4 continents, including 20 years as a freelancer, I have not found lack of relevant industry experience to be a hurdle, except where they really didn't need me. HowardMon, 05 Jan 2009 05:54:45 GMTHoward Perryhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote][b]Jeff Moden (1/2/2009)[/b][hr][quote][b]Grant Fritchey (1/2/2009)[/b][hr]Absolutely. One of the biggest problems we have where I work, an ANCIENT insurance company, is the entrenched knowledge, "We've always done it this way," even though what we're trying to do is something new and different. So "knowledge" can work against you if you let it.[/quote]I agree... The two biggest impediments to progress can be encompassed by the following two statements...[i]"We've always done it this way.""We've never done it that way before".[/i]Like I said... [i]"Before you can think outside the box, you must first realize.... you're in a #$%&! box!!!"[/i][/quote]On the other hand, I don't object to "we've always done it this way because..." followed by a good explanation. It's the stick in the mud approach that makes me crazy.Mon, 05 Jan 2009 05:48:14 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxHello Jeff,I know what you mean by thinking outside the box. After graduating from University, the first thing I had to do on the DBA team of the company I worked with is read the technical manuals on my own. It was there I happened to discover that online backups were possible. The company used to take the database down for about 2 hours do offline backups. When I presented my findings to my boss I had to spend the next few weeks testing that I could recover data from online backups which involved the protection logs. In many cases you have to present your case & support it in whatever way you reasonably can. That was my first experience of doing something that was not the norm for the company. My next one was developing files using a top-down method like E-R modeling. My boss was adamant in using a bottom-up method!DragonLord :cool:PS: Happy new year everyone!Sun, 04 Jan 2009 22:54:18 GMTharryamowhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxsjsubscribe, good points, but I'm not sure that the lawyer analogy is the same. Lawyers bring experience in areas and they often rely on that experience to make decisions about how to proceed. They develop original thought on cases.Tweaking code and working with tables is a lot of what we do. We develop new code at times, which may be more or less than other things, but a lot of times we want to mechanically make things work better. We don't case how they are used, and there are domain experts typically in an industry to help us along.I think someone with industry experience can perhaps help build a better system, but someone without experience can do a great job as well.Sun, 04 Jan 2009 17:31:27 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxIndustry experience is not about data, tables, functions, and procedures in that industry. It's the set of practices, methods, standards, innovations, etc., that databases serve. Often the question is about the candidates' familiarity with such methods common to a given industry. Even if the candidate is hired for change and innovation, it would require an understanding of the existing conditions. When employers hire outside their industry, they recognize the candidate's ability to both learn existing conditions and to help them with changes, especially where employers see as inevitable. It's only when entrenched industries with entrenched methods try to hire outside that they get disappointed. If a DBA is someone who just tweaks data, tables, functions, and procedures, then a lawyer is someone who just tweaks in papers, memos, files, and filing cabinets. Familiarity with tools of the trade is not the same as the familiarity of the trade.Sun, 04 Jan 2009 14:15:40 GMTsjsubscribehttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxMy BS degree got me promoted and more responsibility at work. Well worth the time I put into getting it but still not a hardcore requirement to do the work I do.Now I'm working towards a masters in project management and it has greatly increased my skills at work. I used to fumble through things like budgeting, scheduling, cost/benefit analysis, etc. but then again, I have the kind of job where I'm the product manager, developer, project manager, server admin, DBA, etc. all rolled into one...Our company launched a program where they would only hire new college graduates and the guy we got in our group is frustrated, angry and in way over his head. He's constantly complaining that the work he does is not the work he thought he'd be doing. The last group I was in, we had two guys with doctorates in astrophysics and I had an AA degree in electronics but one of them got laid off and I kept my job because even with their degrees, I was the better choice for the work we were doing. (according to my manager at the time when I did my review)Sat, 03 Jan 2009 20:44:48 GMTRonald C Hagermanhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxI completely agree with the degree statement. Many a time I've not even been looked at for a position I was more than capable of doing because I had no art appreciation degree. Serioulsy, degree relevance makes not much sense unless you are brand new to the workforce. A degree does not a good employee make, nor a smart one. Degrees have become a critical item, not for the hiring manger, but the HR department who won't eveb let that manager see the resume to make that call.Sat, 03 Jan 2009 17:28:45 GMTNicholas Cainhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote][b]AndyG (1/2/2009)[/b][hr]My experience as I move across industries has been that the only "must-have" that is often non-negotiable is a degree, and that has been because at some point in the past someone in the organization's HR has said "everyone above pay grade 123 must have a degree" (of course usually they don't care about a "relevant" degree, and you have Vice Presidents and DBA's with basket-weaving degrees just to check the box off on the application).Another relevant side discussion is the fact that their is no degree directly aimed at turning you into a DBA - if you want to be a coder, get a CS degree; if you want to be a DBA (or a server admin), get some degree you like so you can check off the box. Business and MIS degrees are useful, but they still aren't "DBA degrees" like CS is for coders or engineering is for engineers.I find as I have moved from Education to Market Research to Banking/Finance to Healthcare that the industry specific piece of the job is very quickly picked up - as the original editorial says, the much larger (and more important) part is the technical specifics that any DBA worth their salt can dive into w/o knowing anything about the industry...along the lines of: "I don't care what this database does, but I can tell you're missing the key indexes on these three tables that would actually allow these poorly written stored procedures to work."[/quote]I find this to be an interesting aspect. I got a BS degree in computer sciences - General studies and did a quarter on relational databases and the fundementals of DBMS's. Again though, just one quarter on that. Although, for my final project, I killed two birds with one stone, created a database driven application and submitted it (with approval) for a grade in my SQL class as well as my programming class. I had no problem because I had done DBA and SQL development work before my degree program. Wrote a data warehouse in fact using SQL Server 2000.As far as industry experience, I think it is important to understand the business logic if you are going to code. Imagine writing code for a medical application when you don't understand HIPPA. If your job is anything like mine, experience is critical because we are a virtual environment. All the DBA's, developers, etc. work from home. Most always, I get a project where I am the developer, the DBA, and the project manager. So with my project manager hat on I have to gather the requirements as best as I can understand them. Data is data but have you ever tried to understand the needs of a customer when you have no clue about their business needs? I don't just manage data, I have production DBA's that do that. I am the originator of the data store so I need to understand the rules for the data.One example then I'll go back to sleep here. I had a project where a couple of Exchange administrators wanted to have a system in place where you could go to a web page and add external email addresses to Exchange. I needed a SQL backend to track and enforce all of the business requirements and rules. So, any manager can manage email addresses, any manager can delegate that authority to a non manager, blah, blah, blah. Without understanding Exchange from an Exchange admins perspective (I can use Outlook!) it makes writing something like this difficult at best because not even the Exchange admins knew exactly what they want or they do but do not know how to clearly explain it to someone that has never seen a real Exchange server. Just my two cents on it.Sat, 03 Jan 2009 17:12:07 GMTRonald C Hagermanhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxThanks for the advice Lynn! I'm beginning to see how invaluable Simple-talk is! I would look at the newsletter articles & videos just to lern as much as I could but interacing with the experts is more invaluable as you had said.DragonLord :cool:Sat, 03 Jan 2009 01:39:00 GMTharryamowhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxWell, for learning from more experienced SQL DBA's and such, this is the site for you. I joined in 2004, but didn't get "involved" with the site until mid 2005. I have learned much from the people here, more than I would have on my own.Read, play, answer questions. Your answers may not be the best at first, but you will learn quickly from the feedback you receive. There may be a few who may "flame" your responses, but for the most part, you will get contructive remarks most of the time.Sat, 03 Jan 2009 00:02:10 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxSounds like a great suggestion Lynn! I did think of working as a junior DBA just for the experience & to learn from a more experienced SQL Server 2005 DBA. I never thought of volunteering my time but that makes a lot of sense too! Thanks for the suggestion!DragonLord :cool:Fri, 02 Jan 2009 23:38:28 GMTharryamowhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxOne suggestion I have seen in other career related threads, find a small non-profit organization and do some volunteer work for them. The reason for suggesting a small non-profit is that they usually don't have a lot of money, and you can get some of the Microsoft products free (SQL Server Express, Visual Studio Express tools) and anything you develop for them using these tools is work experience.Just an idea.Fri, 02 Jan 2009 23:29:41 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxI was an ADABAS DBA for a company in Maryland but I got laid off in 2000 after I recovered from a head injury when a contractor almost killed me. When I returned to work I was transferred to a programming team where I was finishing all the work assigned to me by the programmers easily. However, the manageress told me that I was keeping back the programmers because I had them continuously trying to figure out what next to give me. And this was after I rewrote a junior programmer's code and made it run 90% faster. After that meeting with her I got laid off. there is no future for an Adabas DBA so I've been studying for my MCITP and working with SQL Server 2005 Express. However when I look for jobs one requirement is to have a certain number of years of experience working with SQL Server 2005. I feel like a University student with no job experience. How can I apply for a job as an SQL Server 2005 DBA using my experience as an Adabas DBA to help? I'd be happy just to work as a "junior" DBA helping the senior one. What should I do?DragonLord :cool:Fri, 02 Jan 2009 23:03:03 GMTharryamowhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote][b]Grant Fritchey (1/2/2009)[/b][hr]Absolutely. One of the biggest problems we have where I work, an ANCIENT insurance company, is the entrenched knowledge, "We've always done it this way," even though what we're trying to do is something new and different. So "knowledge" can work against you if you let it.[/quote]I agree... The two biggest impediments to progress can be encompassed by the following two statements...[i]"We've always done it this way.""We've never done it that way before".[/i]Like I said... [i]"Before you can think outside the box, you must first realize.... you're in a #$%&! box!!!"[/i]Fri, 02 Jan 2009 14:56:19 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote][b]Steve Jones - Editor (1/2/2009)[/b][hr]As with everything, it depends.I think it's as likely that it's thrown in there to limit the candidates as it is just an addition by HR that isn't really required. My advice, apply anyway if you want the job. It can't hurt, and worst case they turn you down.Is it required? I'd say no and Jeff's first comment said it best. Better to have skills as a DBA and learn the business specific stuff for the company.However I would add that I think part of being a good DBA, and perhaps developer, is being able to pick up the business stuff quickly. Making an effort to learn industry specific jargon, requirements and solutions.[/quote]Absoluely spot on! One of my first "developer" jobs was with a "small" nationwide telephone company. I didn't know an NPA from an NXX... but, I did before I walked into the interview, though. ;) When they looked at my resume and saw no previous experience with telephony, they asked about it. I said "A good developer doesn't need to know about telephony to get the job, but a good one will know shortly after that... I thought I'd get a headstart and study for the interview." Even with no previous experience, I was hired damned near on the spot. The really cool part was, they weren't trying to hire a developer (bit of miscommunication on their part)... they were trying to hire a Director... and I got the job. ;)Fri, 02 Jan 2009 14:50:01 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote][b]bnordberg (1/1/2009)[/b][hr]I agree it is a nice to have industry experience, but absolutly not necessary. Further I think single industry experience is a detrement. For example in healthcare (At least in the federal and state hospitals I work in), we are so far behind other industries, that if your scope is so narrow as to only include healthcare, you are missing out. And people with only healthcare experience tend to put blinders on and not think outside the healthcare box. I believe this is the main reason that MUMPS and Cache are still kicking in the healthcare industry (and retarding our data analysis and research efforts!). Now if only I can get the directors to understand this concept - unfortunatly they to have been trapped in 1 industry so they don't see any issues.I've worked in several industries and I see the same mistakes made over and over and solutions that could easily be adapted are dismissed as not relevant.Expand your horizons, look to other industries for solutions and start thinking outside the box![/quote]Oh, very well said, indeed. In fact, I have a framed picture of a cat sitting in a litter box just a smiling to beat the band... the caption I had put on it was [font="Arial Black"]"Before you can think outside the box, you must first realize... your in a $#%&! box!!!"[/font]Fri, 02 Jan 2009 14:38:54 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxI think another requirement is that a developer needs to have support time under their belt. Developers that write code and hand it off never get a good feel for how good or bad their choices are.I think that the most important interview question\direction is identifying if the person is capable of THOUGHT and has an Inquiring Mind. That will take them far further than experience.Fri, 02 Jan 2009 14:16:47 GMTRobert Hermsenhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxPut me in the data is data, coding is coding group. As has been noted by others, sometimes "Industry Experience" is more of a hindrance than a help.When I started in IT I had no IT experience or Pulp and Paper Industry experience, but because I wanted to learn and had co-workers who wanted to mentor I was able to learn both IT and the necessary parts of Pulp and Paper making.I've also spent time in the student loan industry with no experience and now in non-profit Missions with no prior experience. And to be honest in my current position the incumbent developers have been more hindrance than help because "we've always done it this way".Fri, 02 Jan 2009 13:30:56 GMT Jack Corbetthttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxI subscribe to the "data is data" argument. A database developer works closer to the business rules than a DBA, however even with a developer, previous industry experience is not the proper litmus test for hiring qualified candidates. Industry knowledge ultimately needs to reside with Business Analysts, Requirements Managers and Management. My opinion is that if your company's industry knowledge lies within your IT department, you have bigger problems than worrying about hiring candidates with industry experience. Rather than greatly narrowing your choice of qualified candidates by requiring industry experience, employers should focus on the far more important aspects of say, skill set, practical IT experience, motivation, previous references and desirable personality traits.Fri, 02 Jan 2009 12:35:11 GMTjhaddenhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxAs with everything, it depends.I think it's as likely that it's thrown in there to limit the candidates as it is just an addition by HR that isn't really required. My advice, apply anyway if you want the job. It can't hurt, and worst case they turn you down.Is it required? I'd say no and Jeff's first comment said it best. Better to have skills as a DBA and learn the business specific stuff for the company.However I would add that I think part of being a good DBA, and perhaps developer, is being able to pick up the business stuff quickly. Making an effort to learn industry specific jargon, requirements and solutions.Fri, 02 Jan 2009 12:33:36 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxI can think of a few occassions where my knowledge of a particular industry has helped me in a different position.You can be a good DBA with no industry specific knowledge but to become an excellent employee you have to do your job with empathy for the way in which your industry or company works.For example, I could write an application to upload a data file for a travel tour operator, but a good knowledge of the TOPAS file format would give me a good head start and enable me to spot bugs and issues.Knowing how address deduplication works would influence my design for a name and address solution.I know that downtime in my place of work costs the company £30K per minute. That knowledge affects my decisions as to what maintenance gets done and when.Fri, 02 Jan 2009 12:29:33 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxIn my experience, "industry experience required" means one of two things in a job posting. Either it's a weed out mechanism because that job already has a candidate destined to fill it, but some silly law or HR policy requires that it be posted -- or -- there are insufficient business analysts (or executives) around who know the business and they need somebody to hold their hands through data modeling exercises and such.;)Unless you know the business, you probably won't get/don't want the job anyway.Fri, 02 Jan 2009 10:26:23 GMTDavid Reed-223505http://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx"Industry Experience" - Here i'd call industry as IT industry and i'd prefer to have a real-life experience. I might have read entire BOL and other stuff, but chances are i'll fail at the time of real crisis. Experience in dealing with real-life situation is far more important than having gained bookish knowledge and test scenarios where i know exactly which direction i need to go to resolve the issue.Fri, 02 Jan 2009 08:20:54 GMTps.http://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxI'll have to go with "it depends". If what's being looked for is general SQL knowledge, with a focus on performance tuning, administration, data warehousing, etc., then industry experience isn't particularly important. If it's data architecture, system design, etc., then industry experience can make a critical difference.For example, judging how far to normalize contact data is going to depend on how it's going to be used, protected, etc. You can't know that without knowing the industry in general and the specific business as well. In some businesses, it's going to be just fine to have a table of contacts, with phone, address and e-mail in that table, in others, you need to separate all of those, and in still others, you might need to go as far as multiple names for the same contact. Do you need to store age? How about gender? What about if gender changes? Titles (Mr/Ms/Miss/Mrs/Dr/Rev/etc)? What about if titles change? Do you need a full history, or just the current one?A database architect who knows these things will do a better job, faster and more efficiently, than one who doesn't. Asking questions about it will only take you as far as you know to ask the right questions and as far as the people answering them understand the purpose of the question.If you don't know how far to normalize contact data for an industry, and you ask the experts you are working with, they probably won't know what "normalize" means. So you'll be forced to ask, "do you need to keep a history of a contact's titles?", and they might not know whether that's important or not.So, it depends.Fri, 02 Jan 2009 07:48:32 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxThe answer really depends on what the expectations are for the role of the DBA are within an organization. If the organization expects a DBA to do design as well as implementation, then industry experience is important. If the organization has Business Analysts that do the client facing work, then the organization wants a DBA that is very good at DBA work, and industry experience is not needed.So, if you are in a job search situation that states industry experience required and the job responsibilities do not list any client facing tasks, it is a question that begs asking in the interview.MarkFri, 02 Jan 2009 07:40:50 GMTMarkK-959639http://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote][b]Loner (1/2/2009)[/b][hr]DBA is different from SQL Developer and I think being a developer, industrial experience is very important.[/quote]Completely agreed here. Being in a development role, I have learned equal amounts about the specific area I am working in now as I have learned about SQL Server since I started my new position in July of 2008. The business users talk in their own language and if you don't learn it yourself, you won't be thriving, and certainly won't be able to ask that "right question" that allows whatever you're creating to add value rather than bandaid a problem.Thinking of times when I have had to troubleshoot or fix a system that is broken, I have relied on basically no industry knowledge and it's all just tech.Fri, 02 Jan 2009 07:39:33 GMTnycdotnethttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxOne of the toughest things is just trying to get your foot in the door at something like a pharma. You know you can go in, you know you can do a good job, but they won't even look at your resume because you don't have Pfizer on it or something. It makes me wonder how people even get started in those places, as you have to have worked there previously. Real catch 22 situations there.Oh, and Adrian, nice morph avatar. Haven't seen morph in so long it's ridiculous.Fri, 02 Jan 2009 07:28:39 GMTNicholas Cainhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxThe problem that is faced in requiring industry experience in both development dba's and non dev is that they often do not ask important questions because they 'understand' the industry. Sometimes it is more important to hire someone who can think, grasp and move quickly. They may not even be a stellar sql gee golly wizbang but because they can think on their feet, adapt and grow quickly you will get much better product from them. Industry experience at one company may be completely different than the industry experience at a competitor of that company. It really goes back to the fact that you cannot hire someone based on a multiple choice test or a short interview. You need to hire the person and their abilities not their knowledge. Their abilities to grow and adapt will take them much further than their outdated MCDBA... (oh did they forget to mention it was for SQL 7)Fri, 02 Jan 2009 06:55:42 GMTRobert Hermsenhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxAdrian - always good to hear from a new voice. I'll jump on board with the 'nice to have' group. There's nothing wrong with hoping that a new hire can hit the ground running with minimal mentoring. Of course, I hope the employer is willing to pay for higher levels of experience.On the other hand, if an employer is too sticky about this during the interview process, I think it's a red flag. It's often an excuse for poor managers who don't have the foggiest idea of what's going on in their department. They don't want to mentor someone because they don't know how!Many of you have seen the 'demotivational poster' series (if not, click on www.despair.com). Some of them are very funny. One of my favorites is "Tradition" - it's a picture of the Spanish 'running with the bulls' event with the caption, "Just because you've always done it that way doesn't mean it's not incredibly stupid." 'Industry experience' may mean someone has been doing it all wrong for a long, long time. In this case poor managers who hide behind the 'only experienced need to reply' banner deserve what they get.Fri, 02 Jan 2009 06:51:26 GMTSomeguyhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote][b]Loner (1/2/2009)[/b][hr]DBA is different from SQL Developer and I think being a developer, industrial experience is very important. I used to work with people coming out of college without any industrial experience vs people have years of industrial experiences, it is day and night. The trend of thought is totally different and it affects the way you design the system, how to work with the customers and how to implement the system. As for DBA it is nice to have industrial experiences too, it really makes a difference when you work with other departments and developers. You look at things at all different angles vs one angle.my 2 cents[/quote]Correct. I hope everyone knows the difference between the two positions.There are scenarios in high end DBA positions in which the architecture of applications utilizing a data mining methodology may require industry experience. Science, Finance, Government, Product Procurement are all generic sectors that would fall into this category. The Developers would then implement the actual bulk of the stored procedures while working with any application engineers and UI designers.Fri, 02 Jan 2009 06:47:29 GMTstevedlnhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote][b]AndyG (1/2/2009)[/b][hr]Exactly - at the companies I have worked at, we often have *more* problems with the people that do have industry experience because no two companies do anything the same way - just because you know how things worked at Bank X doesn't mean you will understand how things are at Bank Y - and often the preconceived notions you have from Bank X interfere with learning how Bank Y does things.[/quote]Absolutely. One of the biggest problems we have where I work, an ANCIENT insurance company, is the entrenched knowledge, "We've always done it this way," even though what we're trying to do is something new and different. So "knowledge" can work against you if you let it.Fri, 02 Jan 2009 06:46:33 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote]DBA is different from SQL Developer and I think being a developer, industrial experience is very important. I used to work with people coming out of college without any industrial experience vs people have years of industrial experiences, it is day and night. [/quote]There is a definite difference between a developer (or DBA) that is just out of school versus one with some work experience, but I disagree that it is relevant to be in the given industry - even for a developer. Just like data is data for a DBA, code is still code for a developer, and it doesn't matter if the web app you are developing is to display bank balances and process online charges or to allow new patient entries into a hospital and track medications, the code is still the same (or at least similar enough to quickly absorb the differences).Fri, 02 Jan 2009 06:38:53 GMTAndyG-538510http://www.sqlservercentral.com/Forums/Topic628375-263-1.aspx[quote]After all, just because you know insurance doesn't mean that you've got an instance understanding of some new set of business requirements that have occured because of a change in the law or moving into new territories in a new country... Any of these situations will require you to learn the new concepts and determine storage models, code, etc., to meet them.[/quote]Exactly - at the companies I have worked at, we often have *more* problems with the people that do have industry experience because no two companies do anything the same way - just because you know how things worked at Bank X doesn't mean you will understand how things are at Bank Y - and often the preconceived notions you have from Bank X interfere with learning how Bank Y does things.Fri, 02 Jan 2009 06:35:06 GMTAndyG-538510http://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxDBA is different from SQL Developer and I think being a developer, industrial experience is very important. I used to work with people coming out of college without any industrial experience vs people have years of industrial experiences, it is day and night. The trend of thought is totally different and it affects the way you design the system, how to work with the customers and how to implement the system. As for DBA it is nice to have industrial experiences too, it really makes a difference when you work with other departments and developers. You look at things at all different angles vs one angle.my 2 centsFri, 02 Jan 2009 06:33:23 GMTLonerhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxIt has to be a "nice to have." Most of the time, your statement of "data is data is data" is just too true. My experience has been reasonably wide across various industries (I think) and I haven't had too many issues ramping up on the new set of business requirements. After all, just because you know insurance doesn't mean that you've got an instance understanding of some new set of business requirements that have occured because of a change in the law or moving into new territories in a new country... Any of these situations will require you to learn the new concepts and determine storage models, code, etc., to meet them.Fri, 02 Jan 2009 06:28:59 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic628375-263-1.aspxI can see an argument both ways. While it is true that [quote]data is data[/quote], not all DBA and or SQL positions are specifically geared towards trawling through stored procedures and code. There are positions that require the domain knowledge of the sector in question due to data mining. There are tasks such as prediction models and applications that require one to be able to identify which data should be weighted higher or lower. In many scenarios it can certainly boil down to what the exact job role will be. If they need one to maintain a database architecture, the inherent objects, and optimize performance then yes the argument that data is data certainly makes sense. If job role is to begin working on neural networks and prediction modeling, from a database developer or dba perspective, then domain knowledge of the industry is a valid requirement.Fri, 02 Jan 2009 06:28:49 GMTstevedln