How to really answer a job interview question

  • Home
  • /
  • Blog
  • /
  • How to really answer a job interview question

When those customer surveys of executives ask about how hard it is to find talented people for positions, you’re likely to hear that finding good people is pretty darn hard. Or is it?

I’ve been doing interviews for my day job and it has been (and continues to be) a revelation. The people we’re having interview have good resumes. But they don’t know how to do a face-to-face interview when they answer questions. It’s understandable. It’s a different skill set — and one that we don’t use very often.

Here’s what happens (and then, how to fix it).

Explain the project, but not how they contributed to the project

Most of the interviewees talked a great deal about the project they were on — what the project was about, what the customer wanted, what team members were involved, how long the project took, some of the problems on the project….and talked and talked and talked and talked and talked.

But not about what they did. Just the project in general.

At most — and at best — there would be a general statement like “…and then we gathered requirements for the work…” and went right off of that statement into more about the project.

So put yourself in the hiring manager’s shoes. What would you want to hear? You’d want to hear what the person you were interviewing actually did on the project and how they did it.

Why? Because the hiring manager is trying to make one decision: can this person produce business results? And, secondarily, if that person can produce business results, will that person fit into the team?

If the answer is yes to both those questions, it’s offer time. But people made it incredibly hard to get those two questions answered. And if you, as the hiring manager, have to drag the answer out of the person kicking and screaming, guess what? No offer.

So finding good talent is hard, right?

I I I I I I I I I I I I NOT we we we we we we we we we we we we

Perhaps we were taught to be humble. Maybe saying “I” is considered selfish. I don’t know. What I do know is that when you’re doing a job interview, “I” better be a big part of your vocabulary when you are describing the work you did.

In about half the interviews — after cutting the person off after a 2-minute speech on what the project was about and asking what they did on the project — I then had to interrupt yet again and had to ask, “What did YOU do on the project; I don’t care about what WE did on the project.” Almost bordering on being rude.

Think again of being the hiring manager listening to the answer and trying to determine if you can help that manager meet business goals. That person isn’t hiring “we,” that manager is hiring a singular person. You. You get zero benefit talking about we outside of this one case: There were multiple people doing this one function and you did part of that function.

The way you describe that is simple and straightforward: “There were three of us gathering requirements. My role was to gather the functional requirements while the others collected non-functional and application requirements. Here’s how I did it….”

Two sentences describing the context (so the hiring manager doesn’t get confused as to why you’re only talking functional requirements…) and then immediately what you did and how you did it. Your work. Your successes. Your way of solving issues. Not we.

Examples would be good. Oh, you don’t have any?

This one really baffled me. After finally getting to “I”, the answers were still generic. “I sat down with the customer and gathered requirements.” If you’re in IT, you know the function (and if you’re not in IT, don’t worry — that answer is just as mysterious to us who work in IT as it does for you).

After taking a few stabs at getting a more detailed answer with multiple people, I started asking example questions:

“Tell me a requirement that you wrote.”

“How did you decide who you should invite to the requirements gathering meeting?”

“How did you prepare for the requirements gathering meeting?”

Even if your brain disengaged from remembering what you did on the project, you can provide the theory answer to those questions (and make up a requirements example), These are not hard questions. But, apparently, they were.

Maybe it really is hard to find good talent.

How to answer an interview question

I’ve written about this before, but it is worth a good review. You answer interview questions using a CAR – Context, Action, Result

Context describes the scale around the work you are doing. It’s a global project. It’s a department initiative. There are 50-people on the team. It’s a $2 million budget.

Context helps the hiring manager relate the work you did with the work that needs to be done on this gig. Oh, what you did was bigger and broader. Oh, what you did is about the same as what we need. That kind of thing.

But here’s the deal: You need to distill the Context part of the answer to about 4-5 sentences. That’s it. Full stop. Not a five-minute monologue on everything that happened — except what you did to contribute to the work.

Then comes Action. That’s what YOU did for the work. Not what WE did, but what YOU did. You describe the function you performed (“I gathered functional requirements”). Then you describe how you did it (“I worked with the Sponsor to select which people should be involved with requirements gathering. Once selected, I set up a meeting for the initial session. I prepared an agenda that covered the purpose of the sessions, what the end objective was, and how the participants were critical to getting the right stuff into our upgrade.”).

Actions: no more than two minutes long. Maybe even one minute long. The reason is, if you answer with that level of detail, the interviewer will ask other questions. Like, “How else did the Sponsor contribute to your successful sessions?” And pretty soon it becomes a conversation about how things work and how you get things done.

Finally, Results. Results are accomplishments. 1-2 sentences here — that’s it. “The result was we gathered about 150 business requirements that were then turned over to create functional and non-functional requirements for the work.”

[thrive_text_block color=”note” headline=”Remember: Context, Action, and Result”] [/thrive_text_block]

Using this process gives you the Cubicle Warrior job interview advantage

Think again to that hiring manager. That hiring manager has slogged through almost a dozen interviews encountering answers that resemble the first part of this article.

And then the hiring manager interviews you and you follow the CAR method of answering interview questions. The Context is short. The Actions are all about what you did to contribute to that part of the story. And the results are straightforward.

When this happens, it’s magical. Seriously, magical. The hiring manager has a clear view as to how you can contribute to meeting that manager’s goals. And compared to the other candidates, you come across as a competent, smart, contributor to the work. And, trust me, it results in job offers. Because it did.

[thrive_follow_me facebook=’’ twitter=’CubeRules’ linkedin=’’ pinterest=’CubeRules’]

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}