Why candidates fail the job interview

At the moment, my work group is looking to hire a couple of new Oracle DBAs. My colleague, who is doing the interviewing, regaled us with stories about the people he interviewed. He extended at least one offer; whether or not the candidate accepts remains to be seen.

His stories reminded me of a SQL Saturday presentation by my friend, Thomas Grohser, entitled “Why candidates fail the job interview in the first minute.” The link sends you to a YouTube video of the session he did for the professional development virtual group. I haven’t yet looked at the video, but I have attended his session live and in-person at previous SQL Saturdays. If you are able to spare an hour, take a look at Thomas’ presentation. He gives a very good presentation, as he always does.

I have a few thoughts that, hopefully, will help you if you’re looking to go to a job interview. Again, I didn’t watch the video, so I’m not sure whether or not Thomas covered these points in his virtual presentation, but he did touch on them whenever I attended his live presentations, and I thought they were worth pointing out.

  • If you do NOT ask any questions, consider your interview blown. I overheard my colleague mention that he asked one of his candidates, “do you have any questions,” and he responded with, “Nope!”

    In the back of my mind, I said to myself, “he just disqualified himself. Please tell me you’re not extending him an offer.”

    Seriously. It is absolutely critical that you ask questions at an interview. If you do NOT ask any questions, then you just failed the interview.

    A candidate who asks questions indicates that (s)he is interested in the position and the organization. Keep in mind that you’re interviewing the company just as much as the company is interviewing you. Interviewing is a two-way street. You need to make sure that the position is the right fit for you.

    If you don’t ask questions, it’s an indication that you aren’t interested. Worse, it also signals that you aren’t taking the interview seriously. Why would a company want to hire you if you’re not serious about the interview?

    Bottom line: never, EVER, NOT ask questions at an interview!!!
  • It’s important to ask the right questions. Make sure that, when you do ask questions, ask the right ones. You should frame your questions in such a way that it shows you’re interested in the company.

    You shouldn’t ask questions about salary, benefits, etc. unless the interviewer brings it up. The company doesn’t want an employee who is self-centered. Instead, ask questions that show that you want to be a team player. A common one that I’ve asked when I’ve interviewed is, “what are the organization’s biggest challenges, and what can I do to help you out?”

    Whenever I’ve interviewed, I’ve always prepared at least two or three questions (sometimes more, depending on the interview) to ask in advance. I’ll ask questions about their system environment and their competition. I’ve even asked questions about their workplace dynamic — a question as simple as, “what do you guys like to do for lunch?” can sometimes be revealing about their workplace atmosphere.

    I highly recommend books titled Best Questions to Ask On Your Interview (I’ve seen these books in various titles — 200 Best Questions, 300, etc.). Get them from Amazon, check them out from your local library, or whatever works for you.
  • It’s okay not to know everything. I recently saw a Facebook post from a friend of mine who interviewed a candidate who didn’t know about what (s)he was being asked, and said so. My friend commented that it was refreshing that a candidate just admitted that (s)he didn’t know the answer, rather than try to BS his or her way through the interview.

    We’re human. We don’t have unlimited data storage that we can query on a whim. As such, you’re not going to know the answer to every interview question thrown at you.

    One of the worst things you can do is try to BS your way through every question thrown at you. More often than not, a good interviewer who knows what (s)he’s doing will see through it. That will not reflect well on you during an interview.

    Thomas admits that he will ask the candidate questions that either don’t have a correct answer or have ambiguous answers. (The question itself might even be ambiguous.) He isn’t looking to see if you know the facts; rather, he is looking to see how you answer the question. Answering “here’s how I would find the answer” or “I don’t know, but this is what I think” is often enough to satisfactorily answer the question.
  • Respect the interview. Make sure you’re showered, cleaned up, and properly dressed. Make sure you show up on time (even better, show up early — fifteen to thirty minutes early should suffice). Come prepared. If you’re late or unable to show up, contact them immediately and let them know. Say “please” and “thank you.” Use a firm handshake.

    In short, respect the interview. Not doing so conveys a message that you’re not taking it seriously, which causes the interviewer to question whether or not you really want the job. If you don’t take the interview seriously, chances are that the job offer will go to the candidate who does.

Hopefully, these tips will help you nail the interview. They might not guarantee that you’ll land the position, but they’ll definitely increase your chances of doing so.

Good luck at your interview.

Advertisements

Soft Skills: Controlling your career

I came across this article on SSC by David Poole titled “Soft Skills: Controlling your career.” It spoke to me in a big way, as it pretty much sums up my career in a nutshell. It’s a good read, and I encourage you to go click the link.

I’ve said before that I’ve made an entire career out of adapting to my environment. Soft skills are the key to being able to adapt.

All of my SQL Saturday presentations revolve around soft skills. I’ve been asked before about why I speak at SQL Saturday, when my talks don’t talk about data topics. The fact is, soft skills are important. You can know everything there is to know about data storage systems, recursive structures, or nuclear physics, but often, soft skills are ultimately what sets you apart.

Lots of user groups to choose from

Yesterday, I received a Meetup email (I get them regularly) regarding an AWS group (that I didn’t even know existed). I, personally, don’t deal directly with AWS, but my organization does use it extensively. There is an AWS user group meeting coming up this week. I sent the announcement to my coworkers; I figured that a number of them might be interested in it.

It made me think about the plethora of user groups that are out there. I write primarily about the SQL user group with which I’m involved, but I’m also involved with a UX user group and a .NET user group. I’m also involved with a number of extracurricular activities (that, for the purposes of this discussion, I count as user groups); I play with a large symphonic concert band, I have my CrossFit gym, and this Fall, I will be music-directing a show production that’s scheduled to be on stage in December!

I will confess that I have yet to attend a .NET user group event, and there are a number of other groups that interest me. What keeps me from attending them is lack of time. It seems like there is an endless number of user groups out there, but there’s only one of me, and there’s only 24 hours in a day and seven days in a week.

I’ve written about the benefits of user groups before. It’s a great source of learning, it often doesn’t cost anything to be involved, you support a cause that is special and specific to you, and it’s an opportunity to network and make new friends. (I should also mention that it’s a great excuse to get out of the house!)

And you never know where involvement with a user group might lead!

So if you’re looking to meet people and learn new things, go out and find yourself a user group. I have no doubt that there’s one one there that suits you!

First drafts are ugly

“The secret to life is editing. Write that down. Okay, now cross it out.”

William Safire, 1990 Syracuse University commencement speech

“No thinking – that comes later. You must write your first draft with your heart. You rewrite with your head. The first key to writing is… to write, not to think!”

William Forrester (Sean Connery), Finding Forrester

“Just do it.”

Nike

I will confess that this article is a reminder to myself as much as anything else.

Raise your hand if you’re a writer, and whatever it is you’re writing has to be perfect the first time around. Yeah, me too.

How many times have you tried writing something, but in doing so, you hit a wall (a.k.a. writer’s block) because you don’t quite know how to put something in writing? Or how often have you written a first draft, only to take a second look at it a second time and say, “what a piece of s**t!”

(And speaking as someone with application development experience, this happens with writing code, too. Don’t think that this is limited to just documentation. This is yet another example of how technical writing and application development are related.)

Someone (I don’t know whom) once said, “one of the stupidest phrases ever coined is, ‘get it right the first time.’ It’s almost never done right the first time!” In all likelihood, you need to go through several iterations — review, editing, rewriting, etc. — before a draft is ready for public consumption. It’s called a “draft” for a reason.

The fact is, nobody has to see what you write the first time around. If you’re trying to get started on a document, just write what’s on your mind, and worry about making it look nice later.

Don’t tell me how to build the clock! Just tell me what time it is!

This article’s title comes from something that a former manager used to tell me all the time — often enough that he seemed very fond of saying it. Nevertheless, it’s an important message. This is not the first time I’ve written about this issue, but it’s something that occurs all too frequently. It is a problem in technical and business communication, and the issue is something that bears repeating.

I was reminded of this during our daily status update meeting this morning. The gist of this regularly scheduled meeting is that everyone has a short time — usually no more than a minute, if that — to provide a brief update of what they have going on. The key word here is brief.

One person proceeded to go into detail about some of the projects he had going (he has a tendency to do so). He’s been pretty good about keeping his updates short and to the point, but he wasn’t always like that. It took several long meetings and complaints to the manager to get him to tone it down.

For whatever reason, this morning, he reverted back to form. He started getting into details about his projects that, while important for the projects themselves, were unnecessary for status updates. It got to the point that I stopped listening to what he was saying and pretty much just zoned him out. I don’t know how long he took, but I’ll guess that he took three times longer than anyone else. Or at least it seemed that way.

This is something that everyone does (yes, I admit to doing it, too — ironically, even this very article may be too long). And it is a big problem in communication.

A part of the issue stems from human nature. We all have a limited attention span. The length of that attention span varies, but for the purposes of this discussion, let’s assume that it’s short — say, no more than a minute (sometimes, that might even be too long). If we’re communicating something, we need to make sure that it’s short and simple — and it had damn well better be efficient.

This is why people in roles such as technical, business, UX/UI, media, and marketing communication have jobs. They are in the business of taking large amounts of information and boiling it down into a format that most people can understand.

Whenever I’m writing a user or step-by-step guide, I follow a general rule of thumb: if an instruction cannot be understood within a few seconds, it has failed. That’s when I go back and rewrite the instruction.

Most of the time, people don’t want — or don’t need — or don’t care about — details. Unfortunately, too many people trying to communicate ideas don’t understand this (and worse, they often don’t care). As a result, horrible documentation (or, in some cases, absence of) is pervasive.

Too many people don’t understand that reading is work. It takes effort to read and comprehend documentation. One of my big pet peeves is any time someone tells me, “it’s right there in the documentation,” yet when I look at it, the information I need is buried someplace where I have to fight through the noise of other irrelevant text to find it.

This issue is the basic tenet of my presentation about talking the language of technology. People don’t want detail. They just want the information they need. If they need more information, they’ll look for it.

Good communication makes it easy for a recipient to quickly get whatever information (s)he needs. Don’t make someone have to work to understand communication. Don’t tell someone how to build a clock. Just say what time it is.

What do you do for an encore?

“The reward for work well done is the opportunity to do more.”

Jonas Salk

As a Syracuse alumnus and sports fan, I’m looking forward to this upcoming football season. Orange fans are excited for this season after last season’s 10-3 breakthrough, the first time that Syracuse has won ten football games in a season since 2001. Season ticket sales are up this year (and I’m happy to say that I am one of those season ticket holders). I’m looking forward to attending games this season!

In a recent interview, Syracuse football coach Dino Babers said that getting the team to break through with a great season (after years of mediocre ones) was the “easy” part. The harder part, he said, is maintaining it. As he often puts it, he wants to be “consistently good, not occasionally great.” Breaking through is a great thing, but after you’ve done so, how do you maintain that success?

I thought about this recently in regard to SQL Saturday presentations. One of my friends and fellow speakers gives a great presentation, but I do have one concern about it: it’s only one presentation. I’m not sure how long he’ll be speaking at SQL Saturday if he keeps submitting the same presentation again and again. I’d like to see him do more presentations, and I hope to see him at more events. Yes, he has a good presentation, but what does he do for an encore?

It’s for that reason why I look for more presentation ideas. As of this article, I have a brand new presentation idea that, right now, only exists in the back of my head. I listed it so that I’d remember to work on it. If I come up with what might potentially be a good presentation idea, I’ll set the idea aside so I can work on it. I want to make sure that I have fresh ideas. I love speaking at SQL Saturday, and I’ve been doing it for four years. I want to keep doing so. To do that, I want to make sure I have new material. While I do occasionally recycle my presentations (it’s unavoidable), I try not to resubmit the same presentations over and over to events.

For those of you who are looking to get your career off the ground, the same holds true for career endeavors. A great job that you did on a single project will often be enough to get you in the door. But once you’re in the door, how do you stay there? Breaking through on a project is the easy part; the harder part is sustaining that success. Once you’ve achieved something, can you do it again? And again?

If you are able to sustain success, you develop a reputation as someone who can deliver. That’s how you build a career. Achievements are great, but once you attain them, what do you do for an encore?

For every action, you need a reaction

I came across yet another example of bad interface design this morning.

After I logged into my computer, a pop-up window appeared. It was my Docker application, telling me that an update was available and ready to install. Okay, I said to myself, and clicked the button to proceed.

Except… nothing happened.

I clicked it again. And again. And again. I mashed the mouse button. Nothing. I decided there was a problem with the interface, went on with my work, and forgot all about it. At one point, I saw a Docker window appear, saying updates were being applied. Okay. Again, I went back to what I was doing.

I didn’t think anything of it — until I looked at my taskbar several minutes later. All along the taskbar were several new — and identical — icons that I hadn’t seen before, roughly one for each time that I had hit the mouse button. When I clicked each icon, I was greeted with a window that said “installation failed.” Well, almost all. The second-to-last one I clicked said, “installation succeeded.”

Yet another example of horrible design rears its ugly head.

As an application end user, if I click something where it says “click here,” I expect — and demand — that it does something. It doesn’t matter what it is. Granted, I would prefer that it performs the action that I expect when I click it, but even if all it does is change the mouse pointer, display an “in progress” icon, or display an error message, I expect some kind of response that indicates that my action did something.

An action that results in nothing is a huge pet peeve of mine, and, in my opinion, is extremely horrible design. A click that does nothing tells me that the application is doing exactly that: nothing. Having an action with no response is not only annoying, it can be potentially dangerous. What if — hypothetically — clicking a button resulted in lost data, but there was no indication as such?

A reaction is a form of feedback. If I click a button, a reaction — even if all it is is an in-progress icon — tells me that the application is doing something. If I click a button, and it does nothing, then I expect the application is doing nothing. An action without any reaction results in frustration on the part of the end user, and potentially dangerous side effects if the application performs an action that the user doesn’t expect.

If this is how you design your UX, then you need to rethink your design. When it comes to interfaces, every action must have a reaction.