Good and bad hiring practices. Tips for employers and candidates

Good and bad hiring practices. Tips for employers and candidates

March 18, 2021

By Oleg Zarevych, DevOps/Test Automation Engineer at InterLogic

Hi, My name is Oleg, and I love job interviews. I have attended dozens of job interviews throughout my testing career. Their number has probably exceeded a hundred. I have been on both sides of the table, as an interviewer and as a candidate. I have tried myself in outsourcing, out-staffing, product and startup in Ukrainian, European, and Asian companies. I haven't had an interview with FAANG yet, but if I do, I'll write about it.

There was a time when I went for interviews very often. Not because I was looking for a job, but because the process itself was interesting. It helped me pump up my skills as I got feedback about my level and heard new “unfamiliar words” about new technologies, which I later learned. For example, this way I learned about Docker when no one had heard of it (it was in 2014).

Apart from that, I saw many shortcomings in conducting interviews. With time I started interviewing candidates myself.

In this article, I outlined bad and good practices.

Since I have spent most of my career working in testing, my interviews were in this area. But if you remove points that are specific for testing, the article will be helpful for all engineers. And also for recruiters.


What not to do

So, let’s roll. Imagine that you are a technical expert at an interview.

Never read a resume before an interview. It may seem trite, but there are very few interviewers who read the resume before the interview. In most cases, I have came across those who read it during the interview. I have been repeatedly asked about this or that certification or my education, although it was all mentioned in the resume. It is strange that the interviewer, who you expect to be a professional, could not even look at what was written in your CV. It affects your attitude towards the company immediately, because if employees are not taken seriously at the stage of an interview, then they can be treated in the same way when they are hired.

Ask about the difference between load and stress tests. Asking questions from the first list of Top-100 QA interview questions you come across is stupid. These questions are so overused that it is enough to learn the answers to the first 15 and you will be able to pass the interview in many companies. Often the same questions are asked at both the Junior and the Senior level. And they expect the same answers.

Ask questions to which the correct answer is only your answer. You can often hear questions like “How do you test such and such service?”. And after a few of your answers you will be told “the correct one”. Even if you said the right thing but in different words or mentioned something that the interviewer did not take into account, your answer would still be incorrect. Because the right answer is the one that should be said in his exact words. This behaviour of the interviewer looks like an attempt at self-assertion.

At one of the interviews, the candidate was asked, “Nothing happens on the web page after clicking the button. What could be the reason for this?” Of course, there are many options:

- frontend error;

- backend error;

- the button is closed by another element that is why the click does not work;

- other options which will be written in the comments.

The interviewer ignored these answers and said, “There's probably no event handler on the click.” And here's what happens – out of all the possible options, he expected only the answer about the event handler. And only that answer was thought of him to be right.

Smoke vape during an interview. Even if the interview is online, you should not smoke vape or other things. Something funny happened to me in an online interview at the beginning of the pandemic. During our conversation, as I was explaining my understanding of testing, the interviewer simply took out a vape and started smoking. Obviously, I didn't smell it, but it was unprofessional. Our interview ended 10 minutes later because the interviewer received a call from a courier and went down to get his pizza. And I didn't want to wait for him to start eating it. Someone will say that it is not a big deal and you shouldn’t be bothered. But in fact it is a sign of disrespect to the interviewee.


What to do

An interview is not an exam, it should not be conducted as does a soviet teacher at a local polytechnic university. I've often had interviews in the style of exchanging definitions, for example, “What is HTTP?” - “HTTP is a hypertext transfer protocol!” - “Oh, well done. You know it so well”.

Unless you are a translator, what matters to you is not what the term HTTP stands for but how a person has used the protocol and how he or she can apply this knowledge in your project. The same goes for finding pitfalls in someone's work. I was once told that my pseudo-code written on a piece of paper would not work because I missed a parenthesis or a semicolon. The interviewer was just probably trying to nitpick and assert himself through others.

Remember: an interviewer is the face of the company. The same applies to the recruiter. You will make the first impression. And no matter what the outcome of the interview is, the candidate will remember this company because of you.

I would like to point out what an interviewer and a recruiter should do.

 Prepare for each interview. Read the available information about the candidate: his resume, LinkedIn page, GitHub. Believe me, you can find a lot of information there in a short time (10-30 minutes will be enough). I know everyone is always busy, there are deadlines, meetings and urgent problems… But how can you want a candidate to work for you for several years if you can't spend even 15 minutes to get acquainted with him? It doesn’t make sense.

 However, it is important to understand that a resume is not yet a verdict. Many good engineers don’t care about their resume and do it poorly. I don't know if it's laziness or the Dunning-Krueger effect. Sometimes it happens the other way around – the specialist goes over the top and writes a 5-page resume. Draw conclusions based on the results of the interview and not by reviewing the resume.

 Experience in the amount of years is unimportant. Once I was looking for an automation tester with the knowledge of Python. There were two candidates with two years of experience for the same vacancy. The first one solved many problems on the project, and his knowledge of Python was sufficient for that position. The second one had had two years experience with Ctrl + C and Ctrl + V and did not know Python at all. But technicly the two candidates met these criteria. Also, it is easy for an experienced engineer to change the programming language, especially in test automation. So the conclusion from this is the following: it is better to write what features of the programming language you use, so you can better understand whether the candidate is suitable.

 Ask only what is needed for the vacancy. I have repeatedly seen people asking something at interviews that they are not using and will not use in the project. My favourite is about Performance Testing. Does it make sense to ask a person about something that he will not do? Some will say, “It might come in useful in the future”, but while you will be waiting for that future, the candidate will be able to gain new knowledge or, conversely, forget it. I don't see a point in discussing technologies and approaches that are not project-specific. An exception may be when a candidate is not interviewed for a specific project and he may end up in one of the several teams.

 If a candidate does not understand the question, try to explain what you expect to hear in response. For example, I've heard the following questions, “What happens after a user enters a site name in a browser?” The interviewer expects to hear about the TCP / IP model, what protocols are used, how they interact, and so on. The candidate does not always understand what exactly you want to hear. It is okay for people from different companies and backgrounds to sometimes interpret the same thing differently because everyone has their own experience and understanding of things.


If you are a candidate

And now let’s say you are a candidate in search of a job. Or you are not looking for a job but some recruiter wrote to you and threw the offer for you to consider. What should you know and do?

Before you say anything at the interview, you will be evaluated based on your resume.

Do not write about the school where you studied in your resume. Even if you finished it with honours. Especially if you finished it with honours. Because it will call your honours into question, as there is a lesson about the resume in the school curriculum of the Ukrainian language. And it says  that you shouldn’t write about your school.

I've never worked for SoftServe, but I know what their internal resumes look like. Because dozens of people send them. No, they do not change them and send, they send them without changes. And how can you believe in a person's serious intentions to change jobs after that if he is not ready to prepare his resume? Apart from that, the internal resume may be owned by the company, and sending it to someone else may violate your contract.

 Write about the technologies and approaches you have worked with firsthand. “Well, we had Jenkins on the project. I sometimes pressed the big green button there”, said one candidate who allegedly worked with Jenkins, although he has no idea how it works or how to set up a simple job. And this is a common example.

 Group tool names by appropriate categories. I would not add any utilities like WinSCP and TotalCommander to the resume at all.

 Be prepared to answer questions on any technology from your resume, so list only those you have actually worked with. I often meet people with Java mentioned in their resume when in fact they “have just audited a course on Java”. Remember when the teacher on the exam asked questions like, “Do you know the second law of thermodynamics?” And in order not to tell the truth that you do not know, you answered, “Well, I have read…” - I often hear such kind of answers from candidates. And also “Can I say it in my own words” and “I don't remember the exact definition”.

An interview is not an exam, and it is okay not to know something or not to have experience working with something. It seems absurd to me when a person tries to guess the answer. If you are not sure in your answer, just say so.

 Mention your goals and expectations from the project. To be satisfied with a new job, you need your personal goals to match with the goals of the project. Do you want to start doing automation? Ask if it is planned. Maybe this way you will save yourself from a project where you can quickly burn out.


What price to set for a test task

I once saw a discussion on the DOU forum about a paid test task. By this logic, you can demand to be paid for an interview. You could make money by going to interviews. If you don't like test tasks, just tell them right away that you won't do them.

A test task should not be large. It should not take more than one evening to write two small UI tests for a person who works as an automator. But big test tasks that require more than one day of work are too much.

I am very much in favour of test tasks. In them you can see how the candidate thinks and writes the code. The higher the level of expertise, the more you expect to see in the code (error handling, logging, code structuring, Git skills: whether there are binaries in the repo, whether he uses .gitignore, does he make one commit or has some history, or maybe a ZIP archive).

And also, you can see a person's motivation. An interested candidate will try to make his code high quality and working. Others will say that they will do it and will not even start. This is also an indicator: if a candidate claims for a few days that he is working on a test, and in the end says that he did not do it, I am not sure that I want to work with a person who is lying.

And now a short statistic, according to my observations. Out of the ten candidates:

- five will not do the test

- the code of two candidates will not build;

- the code of two candidates falls or does not do what is required;

- the code of one candidate works as expected.


A brief summary

I have experienced everything described here. Multiple times. I would like to see more professional interviewers and candidates, because it is difficult to find a good engineer even if you look very hard.

An interview should not be an exam, it should be a conversation during which the interviewer and the interviewee share experience and problems to be solved. To tell the truth, even small steps will improve hiring, and candidates will find it easier to find interesting projects for themselves.

Good luck with job search.