How analytics find another good analyst
One day, nothing foreshadowed trouble.
Suddenly, my boss puzzled me: “But we need a new analyst for an adjacent project, let’s have you interview the candidates?”
I, of course, agreed.
And then I thought and understood that I have no idea how to interview analysts, and most importantly, how to understand whether they are good or not. But it was too late to retreat!
Immediately the resumes sent to me, in addition to inappropriate ones, were practically the same. The same qualities, the same skills, the same technologies. Search on the Internet did not encourage, found articles on the topic were as if written by the same copywriter and could not particularly help.
A whole horde of supposedly important parameters was formed, which often contradicted each other.
Thinking over my head and talking to wise people, I proceeded to the plan of the interview.
Instead of searching for abstract “golden” qualities and analytic skills that I should check at the interview, I began to cut off the useless ones.
')
As a result, everything related to technologies and applications turned out to be useless. The project for which I was looking for a person was about business applications for clients, so there was no reason to check knowledge, for example, SQL or JSON, and a monkey can be taught to draw pictures in Sparx in a week. Knowledge of all sorts of UML and BPMN was required only in the context of understanding the process of work, and not “how to draw circles and arrows correctly”.
It would seem, what to ask then? But in the end, an excellent plan was formed, through which 17 applicants passed.
The plan consisted of three parts.
Fully abstracting from technical skills, an excellent filter was obtained for applicants; all candidates who passed it were approved by the management and caused a positive assessment at subsequent rounds.
So if you haven’t looked at hiring analysts like that before, take a look!
UPD: I give examples of asked questions and expected answers.
From introductory questions:
From questions about the role of the analyst in a team:
Played situations.
Suddenly, my boss puzzled me: “But we need a new analyst for an adjacent project, let’s have you interview the candidates?”
I, of course, agreed.
And then I thought and understood that I have no idea how to interview analysts, and most importantly, how to understand whether they are good or not. But it was too late to retreat!
Immediately the resumes sent to me, in addition to inappropriate ones, were practically the same. The same qualities, the same skills, the same technologies. Search on the Internet did not encourage, found articles on the topic were as if written by the same copywriter and could not particularly help.
A whole horde of supposedly important parameters was formed, which often contradicted each other.
Thinking over my head and talking to wise people, I proceeded to the plan of the interview.
Instead of searching for abstract “golden” qualities and analytic skills that I should check at the interview, I began to cut off the useless ones.
')
As a result, everything related to technologies and applications turned out to be useless. The project for which I was looking for a person was about business applications for clients, so there was no reason to check knowledge, for example, SQL or JSON, and a monkey can be taught to draw pictures in Sparx in a week. Knowledge of all sorts of UML and BPMN was required only in the context of understanding the process of work, and not “how to draw circles and arrows correctly”.
It would seem, what to ask then? But in the end, an excellent plan was formed, through which 17 applicants passed.
The plan consisted of three parts.
- General introductory questions.
What requirements are and what properties have good requirements.
They are needed to understand, is the analyst in front of me?
As it turned out in the process, testers and developers, and even people not related to IT, were hiding behind beautiful presentations.
In addition, these simple questions gave another unexpected effect. Some applicants began to freak out when they, the owners of such chic resumes, were asked such simple questions. Well, with such a conversation is short, there is no place for analysts in a psycho. - Questions about the development process and the role of the analyst in the team.
What an analyst should do and what should not. What is his relationship with developers and QA, how he understands development methodologies in which he participated, etc. Practice has shown that not everyone can imagine the whole development cycle of an application, its role in the team and why a business orders software from developers at all. - Situational issues.
Here we simulated both real situations in the work of the analyst, and invented by me, in order to follow the train of thought of the applicant. They considered the usual problems of the analyst: a conflict of priorities or requirements between several customers, a conflict within a team, unclear submission, interviewing a customer, a conflict of business interests, etc.
The most useful block, because tested not only attentiveness and ingenuity, but also the ability to clarify unknown data. In some situations, I specifically kept silent about some of the introductory, but only three (!) Of the seventeen candidates at least clarified something from me. Which, in my opinion, is sad.
Fully abstracting from technical skills, an excellent filter was obtained for applicants; all candidates who passed it were approved by the management and caused a positive assessment at subsequent rounds.
So if you haven’t looked at hiring analysts like that before, take a look!
UPD: I give examples of asked questions and expected answers.
From introductory questions:
- What is your main analyst tool?
The very first question. I am holy sure that this is the head. But as it turned out, some applicants confuse the concepts of “tool”, “skill” and “competence” - What are the requirements?
Here is the answer that is functional and non-functional. What non-functional can be divided into business rules, restrictions and attributes of quality. That requirements for fault tolerance is an attribute of quality, and requirements for integration are limitations. - What properties have good requirements?
Here I expected to hear something from this list: complete, unambiguous, consistent, verifiable and understandable. You can still, of course, call, but it suits me that way.
From questions about the role of the analyst in a team:
- Who evaluates the complexity of the tasks?
Development team - Who writes the test plan and test cases?
QA. Despite the simplicity of the answer, some applicants surprised me here, saying that the analyst does all this. For these, I had a question: “So, according to your QA, is it such a thoughtless monkey that can only press buttons using ready-made scripts?” But despite the hint, a couple of people still proudly answered “Yes!” To this leading question. - Who shows the demo client (in the case of the scrum team)?
Anyone from the development team, but not an analyst.
Played situations.
- Developer and QA Conflict
Introductory: Developer and QA come to analytics and complain about each other. QA says that the developer did the wrong thing, and the developer says that this QA does not understand anything.
Expected actions : It is necessary to find out who, as he understood, what the problem is and in the case of the analyst’s cant to clarify the requirement if it is interpreted ambiguously. - Priority conflict
Introductory : The release is strictly planned by date, a month is left, everything seems to be fine, but here the customer comes running with a new wad of requirements and tells them to urgently add them to the release. At the same time, it is obvious that new and old requirements cannot be made in a month.
Expected actions: Find out what caused the emergence of new requirements, speak the client's needs, suddenly the old ones are no longer relevant, then they can be thrown out. In case everything is needed, get the client to re-prioritize himself with both new and old ones and those that don’t fit to postpone to the next release. - "Killing" requirement
Introductory : At the cost estimation stage, the developer says that this requirement will destroy the system and in order to implement it, it is necessary to kill only a couple of months for the architecture change. And the customer says: “Of course, I understand everything, but I need it, so do it, you are the developers!”
Expected actions : Often what the customer wants is only his personal vision of the situation and the decision. Behind any requirement is a certain business need, the task of identifying it and offering a more optimal solution, cheaper in terms of development. - Blind interview
Introductory : Analytics are sent to interview a new customer, but nothing is known about him, it’s not even clear what application he needs.
What are the main questions the analyst will ask the customer.
I consider the following questions and their variations to be correct in this situation:
What does the customer and his staff?
Why did they need software? What is the problem?
What does he expect from this software? What result?
How does the customer understand that the result is achieved?
What are the limitations of the customer? - Two directors
Introductory : The analytics team makes software for an international corporation with offices in London and New York. The software will be used by customers of this corporation. The directors of these offices are the final customers and for a successful release both of them must subscribe. However, on one of the screen forms, one director wants a blue button to do one thing, and another wants a green button to do something completely different. It is necessary to find arguments so that both directors agree to any one solution.
Expected actions : Through the chain of reasoning to come to the conclusion that once the directors manage the business, then the arguments should be related to the business of the companies, and not “let's make two different pages” or “we will define the client by geographical location”. The ideal option is the ratio of the benefits that the company will receive from various functionals to the costs of developing and maintaining these functionals.
Source: https://habr.com/ru/post/302320/
All Articles