How to find your ideal QA and weed out victims of infogypsy courses

II. Graduates of infogypsy courses often make a better impression on HR than line professionals who have just started looking for a new job

Yes, the reality is that people, after studying in schools of the “get into IT in 3 months” class, answer questions better than middle students who just quit and started looking for work. Why? Because while the middles were “working” on real projects, the trainee/junior QA were cramming how to answer typical questions, how to correctly pass the HR selection sieve and produce a “wow effect” on the employer.

A very real case when I interviewed one graduate of such courses: he answered theory questions perfectly (he was straight from the textbook), but when he was “sent into the field” with a basic question about DevTools (here is the website, find me the URL where our video is from the request is also played) – that’s it, stupor. “It’s stuffed inside, but it doesn’t come out” (sarcasm).

And the social worker with the middle: “I don’t even remember how BDD differs from TDD, we tried to implement this crap on our project 5-7 years ago (it was fashionable then) and very quickly regretted it because we started wasting a huge amount of time to keep test documentation up to date, the development process slowed down and instead of designing an architecture, everyone focused on writing tests before coding. In the end, we abandoned this crap and returned to the good old waterfall, cut into sprints.”

III. Live coding and various atypical tasks in real time

I personally know quite a few good specialists (with whom I have worked for a long time, comfortably and fruitfully) for whom an interview is already stressful. And from the need to urgently perform on the result by sharing the screen, when two leads (Team Lead + QA Lead) critically evaluate them with a sour expression on their faces, they will simply become confused and begin to be stupid or make mistakes (I’m like that myself).

The bottom line is that people can be conditionally divided into two types – owners reactive And proactive type of thinking. Cholerics with a reactive type of thinking, focused on quickly reacting to external circumstances and working with problems “here and now” are perfect for crisis situationswhen “everything is bad” and you urgently need to sort it out, drag it in and overcome it. But over the long term, they become downright bored (they quit work when everything gets better or start working “half-heartedly”) and lack depth of thinking.

The trouble is that neither HR nor social leads usually do this. don't understand. And choleric people, having brilliantly clicked on time problems like “how many times per day are the clock hands, minute and hour, in the same position at the same time”, pass to the position, where people are actually needed to predict risks, rather than deal with the consequences.

(If anyone is interested, I was stuck on this question for a couple of minutes, and then I simply took the mechanical watch off my hand and started turning the hands. But the hr girl said that since I can’t calculate such a basic problem in my head, then it’s too early for me to apply They have a Senior QA position in their company. Thank you! Fuck you!!)

IV. Test our service “here and now”!

A person doesn’t know what’s “under the hood”. RabbitMQ or Apache Kafka? Does the newsletter fly out immediately or by crown? One server or routing configured? And so on and so forth… This is the same as asking “how do I get from Paris to Dakar?” – Are we talking about a rally or an air flight (or is it also possible by train with transfers, hitchhiking, on a cruise ship, etc.)?

And yet, this is a typical question that I have encountered in half of the interviews. After which the butting began: give more input data / here everything is clear. It doesn't work that way. You know that the conditional Vasya does not like to attach new database libs to the project, and Ruslan is too lazy to check the adaptive design.

A tester may come from another field (from EdTech, for example, to the development of an exchange/trading platform) and for him (based on his previous experience) a different sequence of checks will be relevant. Moreover, I don’t want to make unnecessary movements. First, I want to understand the architecture of the project, find out its state (are the servers collapsing under load? Are there any bugs in the product?), understand the priorities of users and business. And only after that start thinking about HOW and WHAT I would check.

So when it was my turn to interview and hire people, I wanted to do two things:

1. reformat standard (everyone is already tired of) interview questions based on my vision of an ideal QA for my project;

2. try to ensure that from these 60-90 minutes (regardless of the future result – offer or refusal) there is benefit both for me and for the candidate.

It was easier with values. For me, when hiring remotely, a person’s autonomy/self-propulsion, initiative, and ability to independently search for answers to questions were much more important than dry knowledge of theory + the ability to solve test problems.

The questions turned out to be a little more difficult, but I want to believe that it turned out well (no one has complained so far) and that other novice Leads and line testers will be able to take away something valuable and useful for themselves from my list of questions and QA selection methods.

My top 10 QA interview questions:

1) You are (un)lucky – you were hired as the first technical specialist at a start-up. Your task, together with HR, is to find a future QA Lead. How will you do this and what should you pay attention to? What questions to ask?

(There is no correct answer here – both authoritarian and democratic leadership styles are quite ok. It is important for me to understand what picture of an ideal QA department a person has in his/her head and what is (not) acceptable for him/her. And sometimes, instead of templates, it is useful for people to think and understandwhat they really want And who they want to work with)

2) HR immediately after telling me that you were registered went on maternity leave, and I went on vacation without leaving any instructions. You have Jira with a product backlog, production + test bench, an on-duty developer and small front-line tasks for approximately 4 hours a day. What will you do? How will you start getting acquainted with the project? How will you self-board? How to put things in order?

(In fact, there is already a checklist for onboarding a company broken down by day and described in detail. The point is that we often have small projects in outstaff that are completed in 1-3 months, where the entire team consists of one or two developers and one tester. In turn, several such teams are supervised by one PM and one MQA Team Lead – that is, I. Sometimes projects arrive in the spirit of – we have a crooked website, made 5 years ago by another team – bring it to fruition. . Without complex architecture and interdependencies (for example, a simple LMS), but where you need to turn your head and sit and poke around, figure it out on your own in a short time. Therefore, “self-onboarding” is a must have).

3) You just started work on Monday and you immediately received a ticket from support: the client complains that the payment did not go through. Unfortunately, we couldn’t find out anything more – the client swore for a long time, and then hung up. At the same time, you know that a feature was released on Friday evening, but it has no labels/tags {billing} and kinda like could not touch this functionality.

You have access to logs in Sentry (only on production – I was too lazy to connect them for testing), access to the database (only on a test bench – they don’t give it to production), access to RabbitMQ with the help of a developer on duty (everywhere), access to admin panels (during your test, in production they didn’t have time to issue rights – only support) and test users left over from the previous QA (product + test). Don’t forget about the ability to roll back and roll back branches in the test.

Find me the least sequence of checks and efforts to localize the bug and determine its cause. (during the course of this or that action, I will say what you discovered). You can search through the front, you can look through the back (as best you can), you can use external resources – it doesn’t matter.

(it’s important for me to understand HOW a person thinks, how many extra body movements he (won’t) make and what real experience he has – because typical bugs are very easy to foresee when you have 2-3 years of real experience, and not “wound up” in courses)

4) Name your strengths (skills, tools) and growth areas. And if you can, describe what kind of specialist (possessing what competencies) you see yourself in 1-3 years. If you don’t want to develop at all, that’s also ok (we also need stable, predictable middles without a problem in the ass). Just explain the reason.

(If instead of “weaknesses” I say “growth areas”, it is more likely that a person will honestly answer What he can’t/does poorly and will honestly answer Where he wants to grow)

Here the juniors are starting to say that they want to learn automation in Python in six months, and then in Java, and then become pentesters – in general, whoever has heard of something out of the corner of their ear is the one who talks about it. For middle players, the situation is a little better, but there is also fog in the head.

At this stage I can understand whether we can provide the person with growth opportunities (or he will leave us in AQA in six months) and a person can roughly imagine why he can learn from us and how much it will be for him Interesting. Well, at the same time think about your future.

5) Do you have sites with complex architecture that you constantly use? Let's choose any such site (except PornHub), feel around the screen, go there and try to find 10 bugs in 10 minutes or come up with 10 improvements so that you can improve it.

(It’s important for me to understand how much a person’s “sense of beauty” coincides with me and how much he is a perfectionist or a don’t care, for whom everything “will do anyway.” An aesthetic misanthrope who will bore everyone by riveting 100,500 improvements out of the blue is also not a very option – you need to know when to stop and be able to look at the project from both the QA and Business side)

6) Great. Now tell me how you would design a test coverage for it. What blocks with suites of test cases would you make, on what principle would you divide the test cases into groups and how would you prioritize them? What types and types of checks would you use? How long do you think it will take to write and run such tests?

(I’m very glad that all the juniors have already learned test design techniques and know the difference between ad-hoc testing and exploratory testing, but I want to understand how a person will do this put into practice without the need to hire him for a trial period and without bothering test tasks. And it’s important for me to know how much his estimates of the amount of work and labor costs coincide with mine)

7) What tool, software, software, database have you never worked with before (but which you have only heard about)? …Yeah, okay. Now wait a couple of minutes – I’ll come up with a problem for you on this. Use Google, ChatGPT, any other available tips (even the help of a mentor in the cart). The point is to understand how you adapt to new and previously unknown things, because in your work you will constantly encounter this.

(Today we have a project with MongoDB, tomorrow we need to check the adaptive layout in BrowserStack, the day after tomorrow we need to attach plugins to a WordPress site. It’s not necessary to know everything – what’s important is the ability and willingness to deal with something new all the time)

8) You are the only tester on the project. You have incoming tasks from support (few and rare), turnover (small tasks for the front every day); technical debt from bugs (that need to be dealt with) from the previous QA; a “so-so” working test bench and periodically “incoming” PM & QA Lead (one needs you to give a demo to the customer, and the other calls you in the morning to find out the status of tasks). What do you see as your area of ​​responsibility? How will you prioritize tasks? How will you work with the board?

(In fact, the board is set up and the interaction protocol, including inter-team tasks, is also described in detail for all occasions. I want to know if the person understands how Scrum and the Kanban board work [не по определению с ютубчика, а реально] and where he will need to be “prompted”, and where he can take the initiative himself. Some need not to be disturbed or interfered with in doing their work – they will figure it out on their own, while others, on the contrary, need a clear plan and feedback every day)

9) Imagine that everything is bad. It really couldn't be worse. The customer is inadequate and rushes in with “brilliant ideas” in the middle of the sprint (give up your tasks, I need this functionality from the backlog on another site for tomorrow), Leads have gone on a binge from such a life, the PM has lashed out at you early in the morning after a dialogue with the customer, and the developer is already cutting the “code-containing product” on autopilot. And you are generally a line specialist – nothing depends on you. What will you do with tasks and conflict?

(I want to understand how a person will act in an aggressive situation and whether he is able to separate problems/mistakes and people)

10) You mentioned that you are learning to code (took courses on test automation, wrote something yourself in your free time or studied, etc). Let's go together now CodinGame and let's do pair programming. Let's solve puzzles together as a team. Our task will be to defeat other bourgeois opponents and write working code faster than others.

(The idea is that I wanted to make the live coding process comfortable for the applicant, relieving him of stress)

In the end I got win-win conversations:

1. June can get from me sketches of your career pathand I upgrade your mentoring skills;

2. Middle will feel comfortable and will be able to “play on his own field”, where we will be on equal terms, applying the theory of testing on any of his sites in practice without unnecessary nerves;

3. Signor (who decided to come to us until he found his AQA/SDET job – yes, there were two such comrades) – will be able to fix, code just for fun with me over a beer and pizza, at the same time correcting my crutch code or discussing IT for life))

In general, this is what my first interviews were like. I believe that I managed to make them interesting, comfortable, useful And educational for me and for the candidate and get rid of the “cancer” of test tasks.

That's all I have. I hope my material was useful to you useful And educational. You get a like, subscribe, comment, and I get new articles 😉