Industry Experience... Required?

  • Grant Fritchey (1/2/2009)


    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.

    I agree... The two biggest impediments to progress can be encompassed by the following two statements...

    "We've always done it this way."

    "We've never done it that way before".

    Like I said... "Before you can think outside the box, you must first realize.... you're in a #$%&! box!!!"

    --Jeff Moden


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

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


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

  • I 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 😎

  • One 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.

  • Sounds 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 😎

  • Well, 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.

  • Thanks 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 😎

  • AndyG (1/2/2009)


    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."

    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.

  • I 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.



    Shamless self promotion - read my blog http://sirsql.net

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

  • Industry 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.

  • sjsubscribe, 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.

  • Hello 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 😎

    PS: Happy new year everyone!

  • Jeff Moden (1/2/2009)


    Grant Fritchey (1/2/2009)


    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.

    I agree... The two biggest impediments to progress can be encompassed by the following two statements...

    "We've always done it this way."

    "We've never done it that way before".

    Like I said... "Before you can think outside the box, you must first realize.... you're in a #$%&! box!!!"

    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.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • If 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.

    Howard

  • Steve Jones - Editor (1/4/2009)


    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.

    [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]

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

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