Voice of the DBA

Author: way0utwest

  • Better Technical Interviews

    Is the tech interview dead? An interesting case made in the article, and some links ideas on how to better interview and hire technical developers. I think some of the ideas are specific to developers, and while they can work, they don’t necessarily translate to other professions, like database people. Developers are tinkerers and while there are lots of projects they can tackle outside of work for fun, I don’t see a lot of database project type work for database administration.

    However I think the main problem with trying to recast technical interviews and ensure you have better success in hiring is that interviews aren’t good models of the real world. In trying to evaluate a person’s skills, and ensure the process is efficient enough to talk to 2, 3, or 10 people for each position, you have to sacrifice something. Usually you end up sacrificing the fidelity of the insight into how the person will perform.

    The idea of hiring someone for a side project is a good one, though not that scalable. However in many of the non-tech companies I’ve worked in, this would have easily have been possible. We didn’t hire new people that often, and having them spend a week on a project, maybe 20 hours of side time, would have worked well and been affordable. The constraints would actually have been finding time to assemble the side projects. We’re usually hiring because we can’t get our work done, and we would have struggled to find time to assemble a project.

    Ultimately I think that prep time is perhaps the best way to hire better. Spend time teaching a few of your managers or other employees how to evaluate someone, perhaps even by interviewing and evaluating existing team members. Learn what things have helped people fit in better, and what haven’t. What traits make sense in your environment. Maybe then you’d have a better chance of finding employees who would both fit in and be productive.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Ultimate Desk?

    I was wondering what this was when I saw it at the Microsoft Technology Center in Philadelphia at SQL Saturday #200. I sat in it, and thought it was pretty cool.

    20130601_085006

    Turns out it is an Emperor 1510. You can actually buy it, for between $5000 and $20000, depending on the options. I think this was the cheaper version, and it was pretty neat.

    It’s not perfect, but it is neat to sit down, have the monitors then lower to meet your preferred height. There’s a flip over desk piece that has space for a keyboard. I guess you’d need to mount a keyboard on it, but it’s a neat idea. With a cup holder, it’s pretty neat. It also reclines up and down, so you can work at your preferred angle.

    The downside might be that getting in and out is a little slow. The monitors take a little time to move up and down, and you might easily bang your head.

    Not sure I’ve love this, or if it would be good for you. I like my standing desk, and use it a lot. Even at a sitting desk, I like getting up regularly and moving, not sitting for long periods of time.

    However this is cool.

  • Great Engineering Culture

    engineer

    There are some nice quotes in this piece, and it’s an interesting talk to watch as well. The talk is aimed at people starting companies that are based on technology and how to build the culture from the beginning. However I’d argue these same techniques can change culture in an existing company as well. It takes time, and patience, but you can slowly transform your technology department one that people want to work in. More importantly, you can make it much more effective and efficient.

    Way too many managers don’t communicate effectively. They want to use the military techniques of command and control, broadcasting a message and assuming everyone will follow along. Instead it would be better if managers listened more to the opinions and ideas of their technologists, especially when it comes to technology issues. The management part of your job comes in when you help your staff mitigate problems, and help them understand the issues and constraints of the business. Giving someone real, logical, valid reasons for adhering to deadlines or requirements often works well. Most technology people are smart and respond much better to discussions and debates based on reason rather than edicts backed by fear or power.

    I love the section titled “Firing A**holes”. This quote is especially important: “Even if you have an engineer who is exceptional, but an asshole, you should fire them immediately. Your team will thank you for it afterwards. It only takes one asshole to destroy an entire team“. I completely agree. It doesn’t matter if someone is an average or even poor worker. If their attitude is corrosive, disruptive, and upsets people, move them on.

    I especially like the part about promotion. Most of us want ownership, responsibility, or as I’ve thought about it, autonomy. Most of us want to make decisions and have control over what we do. Give more responsibility as people do better and drive forward. When they don’t, remove some. That alone will probably help motivate and drive your people forward.

    Building great culture is hard. It isn’t something you set up and it will maintain itself, but rather something that you constantly work on, and tweak to make better. There will be regular arguments and minor disruptions, but if you have people actively managing and working to make the environment better for other technologists, you’ll get great things done.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • More Data Security Issues

    Employee issues are a big problem for IT security.
    Employee issues are a big problem for IT security.

    Insiders and human frailty are still a big problem in data security, according to a new study from Symmatec. Along with system issues these account for two thirds of data breaches. I suspect system issues means misconfiguration and poorly written code (from a security standpoint), though I can’t be sure there aren’t other factors that contribute. What’s disconcerting is that employee behavior problems seem to be rising.

    I think this is partly the result of attitudes and a lack of loyalty and respect from many companies towards their employees. It seems that job dissatisfaction is on the rise, and coupled with a lack of employment security, this makes it easy for some people to ignore regulations, not bother securing their systems, or even copy internal data themselves.

    I don’t know how we change the insider problems without fundamental employer/employee cultural changes. I’m not confident those will change in the short term, and I suspect next year’s report might look similar to this one. I do know, however, that we can each to a better job by learning more about secure coding, secure installation, and encryption. Many of these topics aren’t that hard to understand or even implement, but they do require some practice to build habits and become comfortable with the technologies and processes.

    Security is looking like a constant challenge for those of us working with technology for the foreseeable future. Learning more about how it works, and building the habits to implement it smoothly, in all our systems, or the challenge we should take on for ourselves.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.