Good interview questions for designers / customers

I am trying to come up with a quick question or exercise to evaluate interviewing skills and communication skills for a position writing requirements.

I thought about asking for a quick recipe (like a grilled cheese sandwich), but that's not entirely correct. (recipes describe how to do something, requirements describe the resulting object itself).

I am interested in both suggestions and examples of good (or bad) questions that you were asked.

+4
source share
6 answers

Make sure your writer knows basic English spelling, grammar, and punctuation. Say "They are looking for their bonus checks there," and make sure that they do not ruin the "they", "there" and "them."

Perhaps more important than requirements is the collection of requirements. If this person is involved in this aspect, you may want to submit a hypothetical project to the candidate and ask you to ask the questions that they would ask the interested parties in order to collect the requirements.

+2
source

Use the requirements from the current project and see how good they are.

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 mutual understanding in solving problems? Do they seem curious?

I did not want to ask them to do the real work for you, just appreciate their answer to a simplified version of the real problem.

Asking fake questions is unlikely to show you how they will respond to the task.

+1
source

I’m not sure about a specific issue, but I talk in detail with a person and listen to how they choose their words, build their sentences and interact with you, this is a good way to assess the basic communication skills that often translate into written messages.

For example, select a technical topic that the candidate knows well, and ask them to describe in detail some aspects of the topic. Listen to exactly how they choose their descriptions and how relevant the words they actually choose. The requirements of documents are often implemented literally by developers, so it is important that the terms and words used by the authors are correct. "Words have meanings" - use them correctly. :)

Something else to listen to 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 spent clearing up. Most companies have a common diction or "jargon." writers must learn, but if you lack the discipline to learn and use the descriptions correctly, then this will not make your writing good.

Finally, ask clarifying questions during the conversation and watch if their answer is simply a rephrased version of what they originally said, or if they change gears and refine using a new angle. Since we do not all see things the same way, the ability to rephrase the concept to be more understandable to a particular listener is very useful for clarification sessions. In an interview or discussion, you are a listener, and a good requirements writer should be able to help you understand what they are saying.

0
source

If you are looking for candidates for product management, the questions should be slightly different from those of the Business System analyst type.

I will definitely take into account how a person takes a simple statement of the problem and develops it into a set of requirements and, possibly, puts them in line with priorities.

You can take something as simple as a feather. The problem statement may consist in the fact that "I need to write something on paper, and I take notes at the meeting." You can find many requirements for this task, for example:

  • The tool used should be able to leave a permanent mark on paper
  • He should not tear the paper when I write fast
  • The user should be able to write with him for extended periods of time (this really means that the grip should be comfortable, it should be light, but heavy enough to support the sensation).
  • Etc...

For people with requirements, they should be able to select requirements from abstract use cases and ask a lot of questions. Hope it helps. Goof luck!

0
source

Possible questions

  • Two dogs, A and B, are racing, which dog do you think will win?
    Looking for:
    • dog characteristics (e.g. size, age, health, breed, experience, etc.).
    • race characteristics (temperature, wind, how the race is organized, track conditions, distance, etc.)

  • How many fast food restaurants in the US?
    Looking for:
    • fast food qualification
    • how the problem is solved (local → national guesstimates)

Regarding the problem with grilled cheese, some questions you might expect from a perspective:

  • Is any portion of the sandwich already prepared?
  • How does a customer buy a sandwich? (crispy, cream cheese).
  • What kitchen tools are available (stove, oven, countertop, pots, pans, etc.)?
    • Cooking conditions: kitchen size, etc.
  • The expected properties of the sandwich (size, weight, dimensions)?
    • Brands, flavors, oils, etc.
  • Is the client allergic to any of the ingredients?
  • Cooking specifications (how long, how hot)

    There are many, many questions, depending on how accurate your recipe is. But the answer lies in the questions asked, not necessarily in the recipe. Good answers to the recipe will direct someone where / when to put cheese, on which bread, etc. This question may seem simple, but it is really involved, and it all depends on what is “supposed” and what is not. Possible disclosure . Do not make any assumptions other than those given.

0
source

The good one that I heard from one employer was that they had a telephone (landline) on the table, and they asked you to go through the steps as you tested it.

0
source

All Articles