Voice of the DBA

Category: Editorial

  • A Little Interviewing Advice

    Make your next interview a two way interview.

    I know there was a great uproar over the interview piece at the beginning of this week and I received lots of opinions on various parts of the article, good and bad to go over. But one comment came yesterday that was very interesting to me. Paraphrasing because I cannot seem to find the email in the deluge that is my desktop, it was questions the line “And you want them to think you’re one of them”

    I read that a few times before I received the comment, not thinking much of it. After all, when you are interviewing, you want to get along with people and have them like you and hopefully hire you. When I got this comment, however, it struck me what the advice was and what I read were two different things.

    You see I think teamwork is very important, much more important than the technical skills. Not that skills aren’t important, they’re just behind you fitting into a team environment. So where’s the problem with that line? You see it?

    “think”

    When I interview you, or when I interview a company, I am searching and trying to find out if I AM one of them. I want to fit in, but it has to be something that happens naturally. I try to present an honest face and I try to relax candidates to get an honest sense of how they really are. I want to know if they really fit in, or if I do. Not if I can act the part and fool someone into thinking that I’m some other candidate.

    I know it’s hard. You apply for a job, maybe need one, and you want desperately to get hired. And you want to make the impression needed to get hired. And if you are really desperate, then perhaps there’s some justification. But most of the time that’s not the case. I see many DBAs and developers wanting a new job, more money, etc. and they are interviewing while they already have a job somewhere else. There’s nothing wrong with that, but if you are looking to move, do it the right way.

    Be honest and give an honest impression of yourself. And at the same time interview the company and try to ensure they are giving you an honest impression of what it will be like working there.

    After all, companies lie in interviews almost as much as candidates.

  • The Test of Time

    I'd like to build a "smarter business" that will last for 100 years.

    IBM turns 100, and in this article, they brag about bench pressing more other companies half its age. That’s a great headline, and I still remember when IBM was not only the premier hardware vendor of the computer world, but also the largest software maker as well. The “Smarter Planet” ads that IBM puts out there are great, and they are a diverse company, covering so many different industries and locations that it’s hard to comprehend everything they are working on.

    The culture and mission of IBM has changed in 100 years, but it’s still amazing that the company has survived. I think back to the tech companies of my youth, and many of them are gone. Who remembers 3COM? Anyone set up a Wellfleet router? DEC becoming Compaq, and now HP. Apple is still around, but Sun Microsystems is disappearing into Oracle. Microsoft is only 30 years old.

    I once worked for a hundred year old company, one that embraced and remembered it’s history, even as it evolved in the modern world. The President of the company had worked there for his whole career, taking over for his father that had worked there almost his whole life and still came into the office a few days a week at age 80. There was a sense of history, tradition, and pride that kept people working there, with the vast majority of the company having worked there over a decade when I was hired.

    The modern world is fast paced, rapidly changing, and evolving quickly, but there is something to be said for adapting to fit in, while maintaining your mission and ideals. I hope that more companies would look beyond their next quarter or year and make the attempt to build a business that they are proud of, and can survive a hundred years into the future.

    Steve Jones

    The Voice of the DBA Podcasts

  • Cost of the Cloud

    Will we get real time costing of our cloud computing?

    One of the benefits of moving to a cloud infrastructure for IT services should be a reduced cost. The economies of scale for having specialized staff, licensing, etc. are more evident when you have more of everything. The larger you are, the more efficient you ought to be. For some companies, this can be achieved internally because they have such a large number of computers, but for many companies, I think they seriously struggle with the cost of staff and infrastructure for technology.

    A company that looks to build a technology infrastructure has to make an investment and across a short period of time, they are locked into the hardware that has been purchased. Often we find individual departments are unsure they are receiving a fair share of the IT services, which has resulted in large chargeback systems being implemented that usually have a lot of overhead.

    Microsoft appears to be trying to deal with this in an interesting way. It has collected, and published, very detailed data on how the services in its data centers are being used. These are essentially a private cloud for many business units at Microsoft, and the ability to see how costs are being spent in applications, services, even help desk tickets, which can drive behavior.

    Developers now have an incentive to build better applications, since the cost of a poorly performing application is more easily determined. I would even assume that accounting for metrics in development environments should help people test different solutions, and perhaps even start to determine when one should spend more time optimizing code and when someone should allocate more hardware.

    I don’t know if other cloud computing vendors will start to offer detailed use analysis and charges for the use of their services, but I expect that if they did, it would be something that many CFOs, and CTOs might want to see in analyzing the value they get from their public, or private cloud infrastructures. I know that I’ve found value in all the detailed metrics that we get in costing SQL Server queries through DMVs, wait states, and other metrics, which can certainly help one write code much more efficiently.

    Steve Jones

    The Voice of the DBA Podcasts

  • Regular Audit Analysis

    Do you regularly review audit data?

    I was reading over a digital supplement that I received from Dark Reading recently, which details some of the issues in the Epsilon, Gawker Media, and a few other data breaches. It was light on details, but there were some nuggets of knowledge in there about how these attack occurred. Some were sophisticated, and some were insider attacks, but the advice given to help protect your data was all similar: limit access, watch for injection, audit, and monitor.

    I know that over the last decade as I’ve run SQLServerCentral, the topic of security and auditing has grown in importance. More and more people are implementing auditing functions in their applications and slowly tightening security where they can. There is a lot of work to do, and a lot more education that needs to be spread to a wider audience, but the trend is positive.

    However one thing in the article caught me eye, and it had me wondering how many people are going beyond the basics. For those of you that have auditing built into your application or database, I have a question this week:

    Do you regularly analyze the audit data to look for abnormal trends or access?

    All the data in the world doesn’t have any value if it’s not used. In a security context audit data isn’t all that useful if it’s only examined when an incident is discovered. The real value in auditing data is the ability to uncover problems before they occur. Looking for inappropriate access, unusual access for a particular individual or application, or even repeated attempts to gain access can help prevent a data breach.

    After all, catching the criminal later doesn’t necessarily mean you’ve “recovered” the data. Unlike physical objects, data can easily be copied and spread in way that prevents it’s complete recovery.

    Steve Jones

    The Voice of the DBA Podcasts