Job Interview for Automation QA Engineer

So I found a topic that I can share with the Habr community. I hope this article will turn out not only informative, but also interesting.

Input data:
Location: Dnipropetrovsk.
Position: Junior Automation QA Engineer.
Technologies: C #, Selenium, MSTest, TeamCity, Hibernate.
')
It so happened that a couple of months ago I ended up on the bench in a big company. The client decided to divide our team of auto-testers by 2 (well, that is not zero), and since I had a short period of work on this project, I was in reserve. Domestic projects were not expected, and in reserve it is usually boring and unprofitable to spend money in terms of money. So I started going to the interview.

Before you go for the first time, googling well, I did not find a single good article that would describe the interview questions for autotesting, so I had to learn from my mistakes. This is the main reason for writing this material.

Before you transfer the structure of the interviews, you need to understand the types of projects that are looking for automeyshenov. Basically this is a web using Java, Selenium, TestNG and Maven (this is exactly what I was looking for). By popularity, then goes C sharp, and then a python and cut (all with Selenium). On the desktop was a project on SilkTest and Ranorex.

I went to a few interviews. Somewhere I didn’t like, somewhere I didn’t like me - this is not very important.
It was in this order:

1. The first office I visited was not outsourced, which is quite rare in the Dnieper, especially if you count only those who are looking for Avtomeshenov. In terms of interviews, this is convenient, since everything is solved in one step. But the interview itself surprised me a little. One hundred percent of the questions were on manual testing. The company also asked how many percent of the time I am ready to do manual testing. It became clear to me that they are looking for a manual that will automate their test cases for the sake of time.

2. The second office probably asked the most appropriate questions for the position. Almost all questions were about Selenium, a couple of SQL queries and OOP. This is explained by the fact that the interview was conducted by two auto-testers.

3. It was all very structured. Autotester, who recently moved to development, came with a piece of paper, on which there was a list of questions and started asking in order. There are 15 questions for Java, 10 for manual testing and 10 for cars. With questions on Java, it seemed to me, they bent a little.

4. In this office, I had an interview for two different projects. On both projects they gave a task. The first was asked to test the site of their client, it was a home task. The tests themselves were not complicated, about 5 pieces. It was necessary to make a project in the eclipse, using maven, TestNG, Selenium, as well as Paige obdzhekt pattern. At the interview there was an analysis of the assignment and at the same time questions on the manual and autotesting.
The second project gave me a task at the interview itself. There were about 7 tasks purely for programming: a method that expands an array (the first element replaces the last one and so on), a method that checks if there are identical elements in two arrays, a method that knows how many digits in a number, and the like. The interview itself was basically just communication and you had to read their autotest code.

Here is a general list of the main questions that were sounded at these interviews:

By development:
1. Three principles of OOP.
2. Collection java.
3. The hierarchy of exceptions java.
4. Methods .hashcode () and .equals (), their implementation.
5. HashMap implementation.
6. The difference of the interface and the abstract class.
7. Methods of the Object class in java.
8. Patterns (usually list with what worked).
9. The word static.
10. Internal classes.

By manual testing:
1. The difference of priority and North.
2. The structure of the test plan.
3. The structure of the test case.
4. Design testing equipment.
5. Types of testing.
6. Levels of testing.
7. Bug report.

On autotesting:
1. Types of selectors.
2. Disadvantages, advantages of xpath and why.
3. Patterns for testing.
4. Implies and Explicit wait in the web driver.
5. Difference junit and testNG.
6. How does the maven.
7. TDD and BDD (JBehave).

Almost every place was given such small tasks:
1. There are two labels in the database. It is necessary to make a SQL query. The request had to join.
2. Showed html and asked to write several xpath or other selectors.
3. They gave the registration form or the like and asked to test (that is, to voice, all manual test cases).

Always asked about experience with:
1. Databases (MS SQL server, Oracle, MySQL ...).
2. CI (TeamCity, Jenkins ...).
3. Version control systems (Git, mercurial ...).
4. Bug tracking systems (jira, tfs ...).

As you probably noticed, there are no general rules for interviews, especially for auto testers. In this profession, it strongly depends on the specialization of the interviewers themselves. Therefore, I advise you to prepare for all items. I am a type of person who promises less and fulfills more. And this is a bad quality at the interview. Therefore, when people ask you questions on experience with something, firmly answer “yes” (even if the experience is the most minimal - from an article on Habré, for example), and then after the interview, go and learn this technology. The comments that you made at the interview, not necessarily justified, do not perceive them as 100% true, try to defend your opinion. Frequently asked questions, which is better - A or B? Do not choose one option, but tell the situation in which you would choose the first option, and in which the second. And remember: all the excess that you say may be (and most likely will be) used against you.

Throwing questions easier, more difficult to hit the target. Therefore, for interviewers, I advise you to load candidates, on the basic technologies with which he worked in the previous company. If he knows them well, then yours will be able to master quickly. But to be surprised and refuse a candidate because he does not know the simplest things that you use in your project is not reasonable, he will most likely deal with this in a few minutes. In addition, consider the fact with whom you want to work - with the one who has learned the information, but does not realize what he is doing and why; either with someone who stores less knowledge in the head, but is more intelligent and trained. After all, the one who teaches will be able to easily rearrange, but it will take the labwalker much more time to “memorize” new technologies and work on the principle of “monkey business”.

Output:
Location: Dnipropetrovsk.
Position: Middle Automation QA Engineer.
Technologies: Java, Selenium, Junit, DBunit, Jenkins.

I wish you successful interviews and new heights! Do not forget: “Light is done everything to which you put effort.”