Industry Experience... Required?

  • Comments posted to this topic are about the item Industry Experience... Required?



    Ade

    A Freudian Slip is when you say one thing and mean your mother.
    For detail-enriched answers, ask detail-enriched questions...[/url]

  • While I believe that industry experience can, indeed, be a huge help, I believe it should be "nice to have" rather than a requirement when it comes to DBA's and "Ninja" SQL Developers. Both of those types will quickly ramp up on just about any industry. It takes a much longer time for someone with industry experience to become an excellent DBA or "Ninja" SQL Developer.

    The real fact of the matter is, I usually ignore the "must haves" on those types of job requests... it's usually just wishful thinking on the part of the client or something that HR said they have to include. For example, tell me why you think a DBA needs to have a Master's degree in rocket science to handle an accounting database for a health insurance company.

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

  • I think the only way to answer this question is if you can identify what kind of DBA you are and what kind of environment it is.

    I've consulted for many years and gone into retail businesses , banks, government , industrial, commercial etc without any requirement for business knowledge

    but as you approach the more senior positions within your IT career then indisutry knowledge will help you make that jump up a notch. - Employers will be more excited (and comfortable) about employing you if you have worked for a major rival and you can bring something to the business that a rival does well but you don't....(especially if they are paying over the going rate for a DBA)

    This doesn't really apply to production DBA's so much as developement DBA's where understanding business logic without being told and understanding the terminology of the business and being able to translate that into tables and procs is crucial for effective and fast working if you want to hit the floor running ....

    even so - production dba's might want to gain experience in large and small organisations, where the challenges are different - for example hiring a DBA who had 10 years experience in a small business, while skilled and experienced may not be used to working with a team of DBA's and 400 servers...

    MVDBA

  • I agree that industry or sector experience is far less important than technical ability unless you are facing off directly against the user community, which is rarely the case in DBA and developer roles. A technically able person will pick up the industry stuff as they need it.

    Far more important these days, with the decline in in-house bespoke development, is experience of package and system integration.

    Of course, it has always been tough establishing your technical credibility in an IBM mainframe shop without some years served under your belt.

  • I believe industry experience to be the interview deciding factor but there has to be more opportunities for new CS graduates. Everywhere I go there are one-to-many offshore H1B visa holders taking jobs that could be given to inexperienced graduates coached by mentors. Colleges are increasingly looking for 'real world' professsors who can share 'real world' experiences and creating courses that culminate with 'real world' projects. I am very concerned about the dwindeling CS major rate and the hopelessness that pervades through the newbie software development community about finding any job, even internships.

  • I've seen job postings that state "industry experience" required, especially related to financial industry jobs. I agree that data is data, and industry experience shouldn't be required. If the job description sounds really interesting, then I would apply for the job anyway.

    Amy

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

    AndyG

  • I can see an argument both ways. While it is true that

    data is data

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

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

    "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

  • 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

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

    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.

    AndyG

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

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

    AndyG

  • AndyG (1/2/2009)


    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.

    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.

    "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

  • Loner (1/2/2009)


    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

    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.

Viewing 15 posts - 1 through 15 (of 47 total)

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