Posts Tagged with interview

Last January my role was redefined, and since then I have been managing two teams covering diverse aspects of two software programs. The first team is responsible for requirements, functional design, quality assurance, and the second team is responsible for support.

In this role, I have been focused on analysis and have been interviewing more business analyst type resources than I have before. I don’t call them business analysts, although my company has a job description for “senior analyst, business process”. The reason is because their job is not to analyze business process, their job is to elicit, understand, organize and document requirements for software products. I prefer to use the term “Requirements engineers”, and I like to talk about requirements engineering because requirements are not simply a description of the current or desired business practice, or a wish list. Requirements are a high cohesion document, describing capabilities that are required to deliver specific business value through software automation.

In a recent interview of a candidate for a contract “requirements engineer”, I asked a question that I usually ask candidates of any skillset – “What the top three critical success factors for practitioners of ?”

My friend Johanna Rothman would say that this is not a very good behavior description question, because it does not give the interviewee an opportunity to tell how he has done this. I believe that it is a very good question, because it asks two things at once? Does this candidate see him or herself as a practitioner of a discipline, or as someone doing a job. It also forces them to describe how they practice this skill set. If this answer rolls off of their tongue, then they have spent some time thinking about how to do a better job. If they struggle with it, it is likely that they don’t think about it much, they just do it.

Then there is the answer it self – this tells me what they think is important. I usually ask this question towards the end of the interview, after I have already asked the behavior description questions. I look for answers that are cohesive with the earlier responses, to see if they are spitting out what they think I want to hear, or they practice what they preach.

This candidate did pretty well – after he answered, he asked me what I thought the three critical success factors were.

My answer:

Semantic Clarity or Disambiguation – terms, and concepts, especially metaphors must be precisely defined.

Cohesion – the document must add up with mathematical precision.

Organization, especially abstraction or generalization – the basis of software is abstraction, and this must begin with requirements, classes of problems, value propositions must be clearly identified and categorized.

His answer:

He had cohesion and disambiguation or something close to it, but substituted scope management for organization.

I don’t think he is wrong, but in my organization, scope is fixed after requirements, not before. This is because premature scope management inhibits value delivery, IMO.

I think I’ll hire him…

— Correction —

My candidate did not have cohesion, he said communication, and he talked about making sure that each person walks away from a conversation with the same understanding of the topics discussed. I agree that this is a success factor for gathering requirements. Certainly anyone who goes into a business to understand what is required, in order to add some specific value to the business must have ample communication skills, and most importantly, establish appropriate feedback mechanisms to ensure that the understandings are shared. This for me is a component of semantic clarity and disambiguation, call it a sub-factor.