Asking for Interview Questions

  • patrickmcginnis59 10839 (4/18/2013)


    Eric M Russell (4/18/2013)

    An IT guy who can't perform under pressure is next to useless, even if he's smart.

    I have to admit, I don't like to work under pressure. What sort of situations would you consider to be a "pressure" generating duty?

    I can't imagine working like that. Pressure is a daily occurrence where I work, and always has been. Sometimes it is excessive, usually due to senior management going too long without adapting to new realities. Some days I have multiple "critical" systems go down at the same time. Some days everything works. The first is becomming more common as I keep getting more responsibilities, I can't recall the second type lately.

    If I had no pressure I wouldn't know what to work on. The days would drag by. Ahhh, the horror!

    Dave

  • re: the PB&J question.

    I would *love* that question! I've been thinking about how much fun I would have with it and all of the things I could say. It would be the perfect way to demonstrate my development process and show my personality, including sense of humor.

    OK, now I'm seriously craving PB&J.

    (Thanks for sharing that question. I got a kick out of it.)

  • patrickmcginnis59 10839 (4/18/2013)


    Eric M Russell (4/18/2013)

    An IT guy who can't perform under pressure is next to useless, even if he's smart.

    I have to admit, I don't like to work under pressure. What sort of situations would you consider to be a "pressure" generating duty?

    I don't mind pressure situations, where something must be done quickly with lots of people asking/watching. However some people don't handle those well. I'm not sure I'd classify them as useless. They wouldn't be good in those situations, but if those aren't a daily occurrence, or they don't require everyone's help, there are plenty of uses for people that don't work well under pressure.

    I would agree that someone that lies about their schooling, projects, or something specific should be let go. However I think those situations are few and far between. Often someone exaggerates their contribution. Trying to pin that down specifically can be hard, since exaggeration is a subjective thing.

  • Interviews are just a second rate way of evaluating someone for a job, even well thought out interviews combined with tests arent that great. And there are so many sites where you can find sample interview questions and answers that it really is moot.

    The answer is formal professional standards, combined with formal mentored training/internships along the same lines as the medical profession. Then when you see that an applicant has reached the standard you know for sure that they have reached a certain level of competence. This will never happen in IT though because it would dramatically raise the price of IT employees. So I guess we will just have to make do

  • Steve Jones - SSC Editor (4/18/2013)


    patrickmcginnis59 10839 (4/18/2013)


    Eric M Russell (4/18/2013)

    An IT guy who can't perform under pressure is next to useless, even if he's smart.

    I have to admit, I don't like to work under pressure. What sort of situations would you consider to be a "pressure" generating duty?

    I don't mind pressure situations, where something must be done quickly with lots of people asking/watching.

    Lol I've never felt that to be a pressure situation. That could be a normal day teaching computer programming by definition!

  • djackson 22568 (4/18/2013)


    patrickmcginnis59 10839 (4/18/2013)


    Eric M Russell (4/18/2013)

    An IT guy who can't perform under pressure is next to useless, even if he's smart.

    I have to admit, I don't like to work under pressure. What sort of situations would you consider to be a "pressure" generating duty?

    I can't imagine working like that. Pressure is a daily occurrence where I work, and always has been. Sometimes it is excessive, usually due to senior management going too long without adapting to new realities. Some days I have multiple "critical" systems go down at the same time.

    Well is it a pressure situation? I've been in that situation, what the heck else can you do but work on the problem? If you've got a pretty good team going, everyone searches for solutions. I just had one situation where I helped fix a problem with a switch, we were ABSOLUTELY shut down, and I helped with syntax for some router filtering, and for that matter, I'm not even normally involved with networking since I normally function as the department DBA. If I had read the docs "faster" because I was "under pressure" then I'm certain that I would subsequently be less effective.

    Now I've made a few mistakes that put me "under pressure," but I DON'T ENJOY MAKING MISTAKES AND DO MY BEST TO AVOID THEM. But really, what can you do with flat out errors in the first place? Errors have consequences after all.

    It could be the case that these "pressure" situations are in reality disfunctional work environments, and I do have to admit as in my original post I don't like to work in those situations.

  • patrickmcginnis59 10839 (4/18/2013)


    I don't mind pressure situations, where something must be done quickly with lots of people asking/watching.

    Lol I've never felt that to be a pressure situation. That could be a normal day teaching computer programming by definition!

    My last job, the way it would work is that I had several junior DBA's/programmers always available. I would do the work, and had the junior looking over my shoulder. Their job was to convert my mutterings and typing to human understanding.

    They came up with that system after I used harsh and bad words to the CIO on the steady interruptions every 10 minutes but was able to get the DB backup after about an hour without major corruption or data loss.

    But I have been on the interviewer side, for a junior DBA, but have stumped even experienced DBA's with the simple questions:

    What does DML and DDL stand for?

    What are the four DDL commands?

    What are leading keywords in DDL commands?



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • Problem solving questions are good, but sometimes a couple of simple technical questions are enough to weed people out.

    I asked a candidate what versions of SQL Server they had worked with and they told me "SQL Server 2010 and before that SQL Server 2003". That was enough to let me know that their SQL Server experience had to have been very light.

    I like to ask some technical questions about things that I think anyone with good experience should know, before I get into more challenging things, like asking how they would troubleshoot a system slowdown. There have been plenty that didn't get past the simple technical questions.

    For example, if I ask someone how to add three hours to a datetime and I don't get something with DATEADD, I know they have limited TSQL programming experience.

  • Jim P. (4/18/2013)


    patrickmcginnis59 10839 (4/18/2013)


    I don't mind pressure situations, where something must be done quickly with lots of people asking/watching.

    Lol I've never felt that to be a pressure situation. That could be a normal day teaching computer programming by definition!

    My last job, the way it would work is that I had several junior DBA's/programmers always available. I would do the work, and had the junior looking over my shoulder. Their job was to convert my mutterings and typing to human understanding.

    I like to speak clearly and take screenshots and notes that I can produce a working doc from. Number your screenshots sequentially and also add descriptive text in the saved bitmap name. Learn to use a graphics editor that you can use to subsequently annotate your screenshots with, maybe make some flashy "point" icons etc. I personally LOVE the gimp, but paint isn't all that terrible for many things.

    In reality, you could probably do it completely in notepad unless you guys really are stuck with the GUI. Where I work, I like to be a "language wonk," and pretty much T-SQL can be passed around, especially since Microsoft themselves are clearly aware that scripting can ultimately be more efficient than driving a mouse for everything.

    It does help to have touch typing skills.

    I agree, new hires and whatever are going to demand training time. If this time isn't budgetted for then yes I'm going to agree that you're going to be "stressed" or under "pressure," but if this extra time needed isn't an actual entity that you can discuss with management then yes, its going to be a difficulty that I'd probably not enjoy.

  • I'm now getting the general idea about some of these "pressure" situations I'm hearing and based on what I'm understanding from you guys, I'd like to take the opportunity to recommend the book "Getting Things Done" by David Allen. He subtitles this "The Art of Stress-Free Productivity" and I think this book can really help some of you folks because it really does mean what the title and subtitle says!

    I know I have my share of bad habits, but this book has helped me quite a bit, and I highly recommend it.

  • I find that having a well defined process, insisting on some sort of written spec, and version control can take a lot of the stress away

  • patrickmcginnis59 10839 (4/18/2013)


    I'm now getting the general idea about some of these "pressure" situations I'm hearing and based on what I'm understanding from you guys, I'd like to take the opportunity to recommend the book "Getting Things Done" by David Allen. He subtitles this "The Art of Stress-Free Productivity" and I think this book can really help some of you folks because it really does mean what the title and subtitle says!

    There are, on an abstract level, two different types of DBA's and they have have two types of separate pressures. There is the development/QA types that have a timeline pressure to develop, build, alter and improve the code to integrate on the timeline of delivering an application to the end user. They essentially have a planned day, but are under pressure to produce code on a regular basis.

    Then there is the production DBA. They are charged with keeping the databases up and running, DB tuning, along with the servers and networks. They are also the ones that the are talking with end-users and support staff when thing go wrong. Their job can be 365 days of checking in that the backups are done, stats were updated, etc. But the production DBA needs to be able to respond immediately because the drive in the SAN unit fried at 12:45 PM EST on the first of the month, and would it be smarter to shutdown SQL while the drive rebuilds? What is your DR plan if Building 1 burns? Those have a pressure as well.

    My last company used pretty much nothing but delivered applications, so my production DBA role was pretty much DR and minor troubleshooting. My current company is/was a SW company. They hired me in to troubleshoot our SW errors and hosted DB problems. Within three weeks I was fixing issues in setup by former dev DBA's. 😎

    Declaring "The Art of Stress-Free Productivity" sounds a little presumptuous to me.



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • Jim P. (4/18/2013)


    patrickmcginnis59 10839 (4/18/2013)


    I'm now getting the general idea about some of these "pressure" situations I'm hearing and based on what I'm understanding from you guys, I'd like to take the opportunity to recommend the book "Getting Things Done" by David Allen. He subtitles this "The Art of Stress-Free Productivity" and I think this book can really help some of you folks because it really does mean what the title and subtitle says!

    There are, on an abstract level, two different types of DBA's and they have have two types of separate pressures. There is the development/QA types that have a timeline pressure to develop, build, alter and improve the code to integrate on the timeline of delivering an application to the end user. They essentially have a planned day, but are under pressure to produce code on a regular basis.

    More like they're "required" to produce code on a regular basis. If this is what we're talking about with "pressure" then sure, I guess I can deal with that.

    Then there is the production DBA. They are charged with keeping the databases up and running, DB tuning, along with the servers and networks. They are also the ones that the are talking with end-users and support staff when thing go wrong. Their job can be 365 days of checking in that the backups are done, stats were updated, etc. But the production DBA needs to be able to respond immediately because the drive in the SAN unit fried at 12:45 PM EST on the first of the month, and would it be smarter to shutdown SQL while the drive rebuilds? What is your DR plan if Building 1 burns? Those have a pressure as well.

    I'm at a pretty small shop and do "on call" stuff, and I also do some development. Maybe I just lucked up. All the times I've encountered development or IT work "under pressure", its been because of broken processes, and I guess if you like that sort of stuff then thats fine.

    Declaring "The Art of Stress-Free Productivity" sounds a little presumptuous to me.

    Really highly recommended, especially for you folks "under pressure" 😎

  • mtucker-732014 (4/18/2013)


    I find that having a well defined process, insisting on some sort of written spec, and version control can take a lot of the stress away

    +1 x 1000!

  • "works well under pressure – our management team considers everything urgent and is going to micro-manage you daily."

    Have fun with your jobs guys!

Viewing 15 posts - 46 through 60 (of 63 total)

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