Voice of the DBA

Tag: career

  • T-SQL Tuesday #54–Interviews and Hiring

    TSQL2sDay150x150It’s the May T-SQL Tuesday, and this time it’s a great one. This month the host is Boris Hristov (@BorisHristov) and his topic is one that’s near and dear to me. He’s asking about interviews and hiring, and I have a lot to say on this topic. I could talk about both sides of the table here, and I’ll have to choose one for today, but I’ll give a few more stories over at The Modern Resume.

    This is the monthly blog party in the SQL Server community. The second Tuesday of the month is when you need to publish a post, on GMT time, and then link to the invitation. I’d encourage you to participate.

    I Don’t Know

    I’ve interviewed lots of times in my career. I’m not sure why, because I’ve often gotten great performance reviews, and I think I’ve been well liked at my jobs. Perhaps it’s my own restlessness, but it seems that I’ve often found myself in some situations where I needed to move on for some reason. Quite a few of the times it wasn’t my fauly, but However I’m picky, and so I’ve usually interviewed with lots of companies before deciding to take a job.

    A few years back I was unhappy with my current employer (they’d been acquired) and set up 5 or 6 interviews across a couple months. I often get responses from resumes I submit, and usually secure an interview after a phone screen. A lot of my writing at The Modern Resume is based on my success in getting interviews and job offers.

    The interview I got was at Raytheon Polar Services, the company that manages the infrastructure for the South Pole research station at McMurdo. A developer friend I’d worked with at a previous job had spent a couple years there, including a summer at the South Pole and he helped me get the interview.

    oval-conference-table-wood-southwest-airlines-2

    I walked into a room like the one above. My friend and his boss shook hands with me and we sat down. About 9 or 10 others filed in and took seats around the table. They introduced people and said they would go around the table, allowing the various developers to ask questions.

    The first person to my left looked at me and asked me, “what is ACID?”

    I started to answer. “It’s Atomic, Consistent, …”

    I couldn’t remember. I was sitting there, this great opportunity being offered to me, a friend’s recommendation, and I was stuck on the first question of the afternoon. With a room full of developers watching me.

    “I don’t know what the rest of the acronym stands for, “ I said (if you don’t, look it up), and then I proceeded to explain that the idea of ACID in databases has to do with transactions and ensuring data integrity and consistency. I also explained that I could google the exact terms, and would after the interview.

    I didn’t know, and I admitted it. I try to be honest in interviews, hoping that I can get the company to be honest with me. It’s a joint interview, and I interview the company as much as they interview me.

    However I also know that I don’t know everything. I’ve had multiple questions over the years where I didn’t know the answer, and I just admit I don’t know, explain how I might solve the issue. Someone asked me about a complex networking issue one time and I didn’t know the answer. I admitted it, but also told them I had a friend that was a CCIE and he’d be who I’d ask about networking issues I didn’t understand.

    When you don’t know, admit it. However don’t stop there. Explain what you’d do. Show how you can learn, or solve the problem. Would you ask other developers on the team? You can do this, but not too often. Would you research? How long do you work on it before you ask for help? Do you admit when you’re out of your depth?

    Often I’ve found that showing you can admit faults, can learn, and have plans to drive yourself forward help. Of course, you can’t be woefully under qualified. If I interviewed as an MDX developer, I could talk for days on how I’d learn and the people I could ask for help, but outside of an entry level position, I wouldn’t be qualified to work in that area. Hopefully, however, I’d have made that clear in a phone interview.

    Admitting you don’t know is OK. Just don’t stop there.

  • Better Training

    I was talking with some data professionals recently about training and the value of college, work, or some other method of entering the technology business. I have a few thoughts about the different ways of teaching people about this business, and I’m curious what you think.

    What do you think of traditional computer science? Colleges have students study computer science theories, languages, and more. Build small software projects, write pieces of operating systems and more as part of their curriculum. Students also still have the requirements of other core classes like science, language arts, etc., but does this train them well? I almost think that students ought to be charged with working on real projects, perhaps open source projects, and tackling some small part of the system. Perhaps an older student needs to do project management work, or architectural specifications for less experienced students that are actually programming. Is that good preparation for the real world?

    What about a vocational school that teaches students with real projects? If the students are required to work in the same ways that companies do, given requirements, asking for milestones and deadlines, providing some training, but not all, would you consider that better preparation than anything else?

    Ultimately the best preparation I’ve seen for IT is to immerse people in actual work situations, having them solve real world problems. The best way to do that is actually set up environments where students are forced to build domains, set up clusters, write code that actually would be used to manage a server or produce an application. In essence, run students through an apprenticeship.

    Or maybe the best solution is to actually offer more students apprenticeships where they can learn in the real world.

    I know there’s no one way that works for everyone, but I think that we certainly can find ways to better equip the majority of potential employees than we do now.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio (2.2MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Calling Local Speakers

    There’s likely a call for speakers open somewhere near you. When I was early in my career, I’d see these calls at large conferences like Comdex, TechEd, even the PASS Summit, and I’d think I’d never get the chance to present, with the best of the best speakers being accepted and no chance that I would be chosen. Things have changed in the world with the growth of SQL Saturday, there are a dozen open calls right now, all around the world, with many opportunities for new people to give a presentation.

    When Andy Warren came up with the idea for SQL Saturday, the idea was that we would mostly find local speakers to help present at the event. We thought it might be expensive, and hard, to get the same speakers that present at larger conferences. This event would give many of the talented DBAs in local areas the chance to speak to larger audiences than they get at many user groups. SQL Saturday has been so successful, and the growth is amazing. We’ve started to see more and more well known speakers traveling substantial distances to attend events. That’s great, but I do worry about the lack of local speakers at some events I’ve attended.

    Most of you can speak at a SQL Saturday. If you are solving problems and getting new systems implemented at work, you can deliver a session explaining what you do. If you’ve built an SSIS package or developed a query for a report, then you can help other people working with SQL Server. If you’ve given a session at a user group, you certainly should submit to any of these events. All of these events could use more local speakers

    and of course, #300 (WOW!), in Kansas City. There are quite a few more, and if you head over to the SQL Saturday site, you’ll find all the events listed. I would recommend you think about submitting a session if you’ve done any speaking at all. A brown bag session at work, a user group talk, or even helping a group of kids with computers. You’re qualified, and we’d like to hear what you have to say.

    Steve Jones

     

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • No Handwaving Away the DBA

    There’s a great quote I read, at the end of this article. It says: “…if you think that switching to NoSQL will just let you hand-wave away all of the challenges of running a database, you are terribly misguided.” The context is that all too often people looking to move away from some of the hassles of working with RDBMS platforms, which includes working with the DBA, haven’t completely thought through the issues.

    I do think NoSQL has a place in the world. There are domains of problems that I’m sure Riak, MongoDB, and others, solve in a more efficient way than SQL Server, Oracle, MySQL, and other relational systems. I’m not sure what they are, and to some extent, I haven’t seen good guidance on where particular platforms excel. Most of the articles and pieces on choosing NoSQL seem to be trying to sell me “why a particular platform can replace my other one”, and telling me to add in things like transactions, but not explaining the drawbacks.

    However in all platforms, we often forget that there are really two frames of reference that matter. We need quick ways to work with data, insert it, update it, query it, etc. This is the development frame of reference, and it often dominates discussions of platforms. For good reasons, as developers are expensive, but that’s only part of the system. We also need to consider the operational portion of managing data and applications. When I have those needs to rebuild indexes in relational platforms, or the requirement to periodically merge/remove old versions of documents, or even manage clustered, horizontally scaled resources, we need operational maturity.

    In some sense the DevOps movement is built around merging these two frames of reference into the minds of all those involved. I hope that movement continues to grow and mature, and we learn that developers and operational staff are both necessary, and both need to function in a symbiotic, harmonious fashion.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.