Voice of the DBA

Tag: career

  • Republish: It’s Not Yours

    I’m still at Techorama.

    Check out It’s Not Yours from the past. For some reason I didn’t get it on this blog, so here it is:

    It’s Not Yours

    For most of my career, I’ve felt a tie to the systems I’ve managed or the code I’ve written. I’ve often said that a part of the code was mine, because it was something I’d written. Having some ownership of your work has often meant more pride in ensuring things are well implemented. The same thing goes for administering databases. When an employee feels personally responsible and accountable for  the database and its contents, usually they do a better job.

    Most of us know that the systems we manage and the data they contain aren’t really “ours”, no matter how we might refer to them in conversation. We know that ultimately the data, applications, and hardware belong to our employers. Or, we should know that.

    Apparently not everyone does. A contractor just pleaded guilty to stealing classified information from the US National Security Agency, about 50GB worth of data. This isn’t a case of spying or malicious intent. Instead, the report is that the employee was a hoarder, just keeping copies of data for some unknown reason. Hopefully that’s true.

    Many of us will have copies of data that we use for different purposes. We might be building software, or testing queries, or some other task that requires data. We might want to conduct more in depth analysis in our spare time. Those are all positive goals, but none of them mean that we should have copies of data without authorization. We don’t own the data, and we should always be sure if we are moving data to other systems, that those systems are secure and someone else has approved the action.

    This becomes more important all the time. We have enough issues with data security and keeping our information away from hackers. We make plenty of mistakes with configuration in authorized development and test systems. There’s no reason to add to the issues by treating data as our own personal asset, no matter how good your intentions.

    Steve Jones

  • The Future of Certifications

    Hacker News is a forum for experienced developers. While I think plenty of beginners lurk there, the discussions seem to be dominated by those who have worked in the technology or software industries for years. I saw an interesting article that noted Hacker News doesn’t seem to discuss certifications and backed up the claim with some search results that show few results for various terms.

    I think that many experienced people working in technology are wary of certifications. With a little practical experience, one quickly realizes how little certifications actually do to prove you know how to work with a platform, or with code. Most companies that hire someone with a certification will need to allocate some time to training them how to work on their systems. To be fair, this is the case with a college degree as well.

    The article goes on to talk a little on how colleges ought to be separating out a “degree” from more concentrated or focused evaluations of skills. I agree, though arguably this reduces the brand (and revenue) of many institutions. My view would be that many people don’t need the two year degree. Those that do will come back and get it, or take additional classes to learn more.

    I do believe that studying for and passing a certification forces someone to learn a bit about the technology area. It also helps the student decide if it’s a subject in which they have an interest. It doesn’t prove they have knowledge, but it does show some work in a particular area. I think certifications can be good for many people as my studies this year have definitely helped me learn a bit more about different areas of Azure that I knew little about. I’m not an expert by any stretch, but I have some idea of concepts and how to go about learning more.

    My view is that beginners are very different from experienced people. We ought to understand that all of us are beginners in some technology area and certifications are a good way to focus effort and study in those areas. I would prefer that vendors not only have a path to more difficult and practical certifications but also that they lower the cost. I’d even like to see a second chance at exams given at 1/2 or 1/4 price. That would encourage more people to take a chance on an exam and not worry about the cost so much. This also might reduce some of the brain dumps and other cheats if someone isn’t overly stressed about the cost of exams.

    I’d actually like to see exams focused on very tight areas, like only T-SQL DML or T-SQL DDL, with actual code being written and tested, not multiple-choice questions. This is the type of program that might even encourage employers to regularly test their candidates before hiring, or even encourage more employees to cross-train into new technologies.

    There is a shortage of talent, often in new areas that vendors are selling products and services. Demand that vendors also provide training and focused exams that are based on the current versions at low costs. We can make this cheaper and easier to do. We’ve done that with most parts of technology services, why not exams and certifications?

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • My First Technical Job: T-SQL Tuesday #150

    It’s that time of the month again for a T-SQL Tuesday blog party. This month is hosted by Kenneth Fisher, who has hosted a few times in the past. I like this topic, and it’s a good one for me to think back to my earlier career.

    I am very curious to see what others might write.

    It’s Who You Know

    Perhaps one of the things that I learned early and didn’t believe is that networking, connections, and who you know matter more than what you know. The what is certainly important and can help you succeed in day to day work, but for landing jobs, networking is king.

    I actually had my first technical job as a computer person in high school. I had gotten interested in computers and owned a Commodore Vic-20 and 512, and later an Apple II compatible. My Mom wasn’t sure about spending all the money, but she did and I spent hours digging into how things worked.

    My neighbor owned a construction business, laying water and sewer pipe. Later I worked in that side of the business, but the spring of my junior year he was struggling to implement a new estimation and inventory program on his first PC. His secretary was a nice lady, but in her 50s and in the early 80s, computers were completely foreign. He chatted to my Mom about things and she said I might be able to help.

    This was the first time I was thrown into a situation where I didn’t know a lot, but it wasn’t the last. In fact, these same skills were useful as a consultant:

    • reading manuals
    • grasping the relation between quickly written words after the fact and software
    • experimenting without causing breakage
    • making backups and learning to restore
    • explaining how software worked or needed configuration in layman’s terms
    • perseverance when you are struggling
    • projecting confidence when you don’t feel you have much

    These were the things I had to do over a few weeks as I learned how the software worked, installed it (a few times), set things up, and worked with the secretary and a few foreman to help configure things the way they wanted them. I also had to train them to use the software to enter data.

    Outside of school, this was my first technical job. I think I got paid $10 or $12 an hour at the time when most jobs were $3.35/hr at minimum wage. No big earnings, but I probably made enough to buy a few $50 video games or software games.

    The rest, as they say, is history.

    BTW, laying water pipe a couple summers later taught me a lot as well.

  • Crazy Interview Questions

    Redgate had a discussion recently among our developers about our interview process and questions. There has been a standard question asking candidates about 2D arrays, but as one developer pointed out, we don’t use these in our code base. So, why do we ask candidates about this topic?

    The developers came up with a different question, actually a series of questions that ask about a class and then how to test parts of this class. We mostly work in C# in a DevOps culture, so this seemed like a good idea. They proposed a scenario with a few questions and then asked current developers to solve the questions and give feedback on the language, structure, and difficulty of the problem.

    I followed the technical discussion lightly, as I am not concerned about how effective this particular question might be. I was more interested in why people felt this series of questions would give them insight into how a candidate thinks and devises solutions. This isn’t a test so much as a chance to decide if a person can fit into a team and accomplish work. We tend to work in teams, so while the ability to write code is important, it is more important to collaborate, share, and learn from others.

    In the end, I hope that the interviewers don’t view this as a pass-fail, but rather as a spectrum that represents the opportunities a candidate would provide to build better products. Does the candidate ask questions, do they see the upsides and downsides of potential solutions. and do they view the challenge as a way to learn and get better? If they misread the problem or make a mistake, do they admit it? Do they realize that they went too fast or were too nervous here? I have seen plenty of candidates make syntactical errors in coding because they are nervous in an interview.

    In school, mistakes often result in poor marks. An incorrect answer and lower grade are the results of simple mistakes. In the real world, we are not as often evaluated in black and white terms. We use peer review, unit tests, and code analysis to catch simple mistakes. We grow and learn from these errors and improve over time. At least, that’s what I would hope most developers, as well as Operations staff, should do. A logic error in a WHERE clause or an incorrect partition for an OVER() aggregate might cause some issues, but we don’t fire employees for making these mistakes. Why would we disqualify a candidate for doing so in a pressure-packed, short interview?

    I used to give questions as a test, but over time I started to use them as a way to gain insight into how an individual fits in a team. I’ve added poorly phrased and incorrect questions to see if someone catches my error. I’ve asked about impossible situations or problems my team hasn’t been able to solve, just to see how people react. I’ve learned to appreciate the Kobayashi Maru-type scenarios that test someone’s ability to cope with difficulties.

    I saw a question from Amazon’s interview process (allegedly) recently that asked about solving a hanging cable problem. I’ve seen some of the “How do you move Mt Fuji” questions that Microsoft used to ask. I can appreciate the challenge of asking highly technical people to think algorithmic-ally about how to accomplish a task. I just don’t know if those types of questions help us build better teams.

    What types of questions do you think help decide if a developer, or a DBA, would be competent in your environment? Are there any crazy ones that you felt stressed you, were extremely difficult, or maybe didn’t help you pick a good candidate? Or maybe you have thoughts on what might better help you decide to choose one candidate over another. Let us know what you think today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.