views:

110

answers:

6

I'm trying to come up with a quick question or exercise to evaluate interviewees' design and communication skills for a requirements-writing position.

I've considered asking for a quick recipe (like for a grilled cheese sandwich), but that doesn't quite feel right. (recipes describe how to make something; requirements describe the resulting object itself).

I'm interested both in suggestions, and examples of good (or bad) questions you've been asked.

Thanks!

Don't write merely to be understood. Write so that you cannot possibly be misunderstood.

A: 

I'm not sure about a specific question, but having a detailed conversation with the individual and listening to how they choose their words, construct their sentences, and interact with you would be a good way to gauge basic communication skill - which will often translate to written communications as well.

For example, select a technical topic the candidate knows well and ask them to describe, in detail, some aspect of the topic. Listen to how precisely they choose their descriptions and how appropriate the words they are choosing actually are. Requirements documents are often implemented literally by developers so it's critical that the terms and words the writers are using be the correct terms. "Words have meanings" - use them correctly. :)

Something else to listen for is the frequent use of generic, vague, or broad terms. Translated into a requirements document, this will lead to confusion, conflicts in requirements, and time wasted to clarify. Most companies have a common diction or 'lingo' that req. writers are expected to learn, but if you lack the discipline to learn and use descriptions correctly, then it will do your writing no good.

Finally, during the conversation, ask clarifying questions and observe if their response is just a rephrased version of what they originally said, or if they change gears and clarify using a new angle. Because we don't all see things the same way, the ability to rephrase a concept to be more understandable to a specific listener is very helpful for clarification sessions. In an interview or discussion, you are the listener and a good requirements writer should be able to help you understand what they are saying.

dls
+1  A: 

Use requirements from a current project and see how well they do.

Take a small, simplified part of your existing requirements and see how they respond. Do they ask relevant questions? Do they develop an understanding of the problem? Can they establish rapport towards problem-solving? Do they seem curious?

I didn't mean to ask them to do real work for you, just evaluate their response to a simplified version of a real problem.

Asking fake questions is unlikely to show you how they'd respond on the job.

Beth
so basically, get them to work before you hire them? :)
vol7ron
Whenever a company asks me to do work before hiring I say no straight away. It's a horrible thing for any company to do and needs to die. -1.
Coronatus
Our current products may require too much background knowledge, which is why I'm looking for something more generic - I'm interested in general (and more broadly applicable) logic and communication skills...
MsLis
no, that wasn't what I meant. Obviously they can't do real work. I'll edit with more details.
Beth
+2  A: 

Make sure your writer knows basic English spelling, grammar, and punctuation. Recite "They're looking over there for their bonus checks," and make sure they don't mess up "they're," "there," and "their."

Perhaps more important than the requirements writing is the requirements gathering. If this person will be involved in this aspect, you might want to pose a hypothetical project to the candidate and have them ask you the sorts of questions they'd ask stakeholders in order to gather requirements.

Jay
I agree with this as well - syntax is critical and the ability of the writer to understand what they are writing is necessary.
dls
A: 

If you are looking at Product Management candidates, the questions should be somewhat different from Business System Analyst-type positions.

I would definitely take into consideration how the person takes a simple problem statement and develops it into a set of requirements and perhaps prioritizes them.

You can take something as simple as a pen. The problem statement could be that "I need something to write with on paper, while I take notes in a meeting". For this problem statement you could come up with a variety of requirements, such as:

  • The tool used must be able to leave a persistent mark on paper
  • It must not tear through paper when I write fast
  • The user must be able to write with it for extended periods of time (this really means that the grip must be comfortable, it must be light-weight, but heavy enough to maintain the feel)
  • And so on...

For a requirements person, they must be able to distill requirements out of abstract use cases, and ask lots of questions too. Hope it helps. Goof luck!

Sologoub
A: 

Possible Questions

  1. Two dogs, A and B, are running in a race, which dog do you think would win?
    Looking for:
    • dog characteristics (eg size, age, health, breed, experience, etc)
    • race characteristics (temperature, winds, how the race is organized, track conditions, distance, etc)

  2. How many fast food restaurants are there in the US?
    Looking for:
    • fast food qualification
    • how the problem is solved (local -> national guesstimates)

Regarding the grilled cheese problem, some questions you might expect the prospect to ask:

  1. Is any part of the sandwich already cooked?
  2. How does the customer like the sandwich cooked? (crispy, melted cheese)
  3. What kind of kitchen tools are available (stove, oven, countertop, pots, pans, etc)?
    • Cooking environment: dimension of kitchen, etc.
  4. Expected sandwich properties (size, weight, dimensions)?
    • Brands, flavors, oils, etc
  5. Is the customer allergic to any of the ingredients?
  6. Cooking specifications (how long, how hot)

    There are lots and lots of questions depending on how accurate you'd want the recipe to be. But the answer is in the questions asked, not necessarily the recipe. Good recipe answers would direct someone where/when to put the cheese on which bread, etc. This question may seem simple, but it is really involved and it all depends on what is "assumed" and what is not. Possible disclosure: Make no assumptions other than given.

vol7ron
Good point. We often get burned by assumptions...
MsLis
A: 

A good one I heard from one employer was they had a telephone (landline) on the table and they asked you to go through the steps of how you would test it.

Tom Gullen