how Android interviews are conducted and what we expect from candidates

how Android interviews are conducted and what we expect from candidates

Selection of candidates for the company is an important and delicate issue. You are looking for a dream team. We want to find a person with whom we can develop complex features side by side, fight bugs and casually chat over a cup of coffee. These aspirations, like the “streams of Aragvas and Kuras”, lead to one meeting place – the technical interview.

Other stages are also important: studying resumes, screening, communicating with a recruiter, getting to know the team. But without insults, colleagues, the culmination of this play is an interview with technical specialists.

My name is Oleksandr Girev, I am an Android developer at Alfa-Bank, I work in the payments and transfers team in the application for individuals. I participate in technical interviews and know what is happening on the other side of the “Zoom” during the interview 🙂

It seems that describing the selection process in general and the interview in particular is becoming a rule of thumb. Recently, our tech leader, mitap speaker and just a good guy Abakar Magomedov talked about some subtleties of preparing for an interview in an article 8 unusual tips for an Android developer before an interview.

Today we will continue the topic of interviews. I’ll tell you what we expect from candidates for the Android developer position. And what you need to pay attention to in order to get the dream offer from Alfa-Bank.

Let’s start with an obvious but important point.

An interview is not an interrogation

Rather, it is a business meeting of future partners where we want to get to know each other better.

We are developers just like you. We have such features, bugs and pull requests. And we definitely won’t bite you. If only because we are sitting on the other side of the screen from you:) Therefore, tune in to the conversation of equal people who have a joint project called “A job in the dream team for a good programmer”.

And another small insight: for many interviews, interviewers are the same stress. We too sometimes get nervous when we are interviewing.

The rule of a good tone at an interview is that you have prepared for our meeting

Each company has its own nuances of selection. But there is a rule relevant for any team with a good reputation — the company appreciates when the candidate prepared for the interview. This phrase has several facets.

First, you have taken care of the place and time for the interview, technology and communication. Everything happens in life. The neighbor started drilling, the power went out, or you couldn’t find a comfortable place, and you are forced to pass the interview on a park bench. But you did everything in your power and we will appreciate it. You have shown that you are interested in our meeting and that it goes smoothly and comfortably. The rest is decided.

The only prerequisite is a computer. In our interviews there are practical tasks, it will not be possible to solve them from the phone. A webcam is also desirable. A blind interview is an interesting way of recruiting, but we want to see our future colleague at least on the monitor screen.

Secondly, you tried to learn more about our company, project and team. This means that you go to the interview consciously and know which team you want to join. This also includes the presence of questions after the interview about the team, stack, processes.

Third, you prepared according to the stack specified in the job description. For example, one of the must-have requirements for us is Dagger2. It’s one thing if you don’t have a lot of experience working with this library. It’s a completely different matter when you haven’t even tried to compensate for the lack of practice with a good study of theory. Think: we have indicated in the description what is important to us (current vacancies can be found here and here), so we assumed that you are using this information as intended 🙂

Why do you need questions at the stage of getting to know each other?

The first part of our interview is an introduction. We usually ask to tell about the experience, the last project, the stack with which it was possible to work.

Interviews are stressful. The getting-to-know stage helps to create the right atmosphere for meeting and talking. And after 10 minutes we already know each other a little, see each other’s manner of communication.

During acquaintance, you can understand from which angle you look at certain things and how you are used to solving problems. This is also important: we have a large company and many different teams, each of which values ​​certain qualities more.

Another point is curiosity. We are interested in how work is organized on other projects and teams, what stack is used there, how the processes are built. Therefore, sometimes we use the opportunity to hear about the experience of guys from other companies.

Are soft skills important?

There is an opinion: the days when programmers sat in a corner and communicated only with irons have passed. You ask me, are soft skills important? My answer is definitely yes.

Soft skills are a stretch concept. Important qualities for our team:

  • communication. We communicate with business. We communicate with each other. Sometimes we need to teach each other, to be able to explain complex things in an accessible language. Or describe something in the documentation to make life easier for the whole team at once;

  • proactivity. Meetups, technical articles, communication with guys from other companies increase our experience, help us develop as professionals and develop our product;

  • learning. The ability to learn, and what is important, self-learning, will allow the developer to quickly understand complex business logic or an unfamiliar feature, to perform tasks using a stack that he did not have to work with before.

During the selection process, the candidate is assessed comprehensively. The presence of certain qualities can compensate for growth points in other areas. For example, if a candidate is an easy learner, not knowing the theory or not having experience with some framework doesn’t seem so critical anymore. At a general high technical level, of course.

Here we logically came to the next point.

In what format does our technical part take place?

This is not our screening, but who knows where the competition in IT will take us 🙂

At the time of writing, in most of our teams, the technical interview includes 1 stage lasting 1.5-2 hours. In the payments and transfers team, we split the interview into two stages without changing the format of the meetings. Therefore, we meet with the candidate twice: a 40-minute screening with 4-5 practical tasks and a main interview lasting 1-1.5 hours.

The format of the questions is practical tasks, code examples in which you need to correct an error or say what will be displayed on the screen. There are practical tasks to think about: we will offer to describe several options for solving this or that case. Solving tasks helps to see how the candidate thinks and connects theory and practice.

We try to use common time efficiently. Therefore, within the framework of one task, we can touch on several topics at once. For example, to solve the task you will need a good knowledge of Dagger2 and the Activity life cycle.

Separately, we do not have life coding in its pure form, an architectural section, and something like a sports code review. Many of our assignments contain elements of these interview formats.

Do you have to answer all the questions correctly?

Many programmers are demanding of themselves. A wrong or incomplete answer in an interview can put them out of the job.

It is important to say that we do not conduct an interview for a specific grade, for example, for the Middle level. The more correct answers the candidate gives, the higher his grade will be according to the results of the interview.

Our tasks are designed to first check your basic knowledge of a specific topic, which will be sufficient to work on our projects. If the candidate shows confident knowledge, we can ask an additional question at a deeper level. And the correct answer here will be a plus, which will affect the final grade.

Another issue is the minimum threshold level to get into the team. Here everything will be evaluated individually.

First, something can be forgotten, something critically not known, and something can be learned very easily.

Second, as we have already discussed, sometimes small gaps in technique can be compensated by other qualities or good knowledge in other topics. We can decide that you are able to understand a particular topic, or simply have not encountered it in practice, or have not repeated the theory for a long time.

Thirdly, there is knowledge without which you cannot get on the project. This is a must-have list of technologies from the job description: Dagger2, RxJava, coroutines, architecture patterns, features of working with multi-module programs. You can also not know something here. But in general, you should have certain knowledge.

And one more point. The job of the interviewer is to test the candidate’s knowledge and understanding of the essence of the question, not to test his memory and how well he learned the basic definitions. Therefore, it is better to build the answer in such a way as to show as much as possible that you understand what you are talking about.

Imagine you are talking to a beginner programmer and you need to explain how the flatMap() operator works with RxJava. It seems that without a detailed description and a practical example, it will be quite difficult to do this. The task is similar to an interview: you need to show the interviewer that you understand what you are talking about, so practical examples will be appropriate.

It happens that you are asked a question for which you do not have an answer. If the nature of the question allows, you can consider, try to logically find an answer to the question. For example, you don’t know what some statement does in RxJava. But its name suggests what it should do.

Plus, all libraries and frameworks are written by the same programmers as us. Therefore, no one prevents you from offering your solution to this or that task. Once we conducted an interview with Abakar. The candidate did not know the answer to the question, but began reasoning with the words: “I don’t remember how it actually works in Android, but if I implemented it, I would do it like this.” After that, she described the existing native implementation almost exactly. Conclusion: Even if you don’t know the answer, try to think.

Sometimes the question implies knowing the exact answer, or you have reached a dead end in your reasoning. In such cases, it is better to immediately say “I don’t know” and continue talking to the next question. There is nothing shameful here, we are all human. Interviewers also do not keep a deep link on Google in their head and often learn from candidates something that they did not know or met before. Plus recognizing a knowledge gap is the first step to starting to fill it 🙂

What happens after the technical part?

The stage after the technical part – answers to the candidate’s questions. Here we talk about our project, the processes within the team, how the interaction between developers is arranged, which stack we use. If the candidate has questions after the interview, no problem. They can be delivered through an HR specialist.

After the interview comes the most important moment — compiling feedback and deciding whether the candidate is suitable for working on the project. We assess comprehensively according to the following criteria: the relevance of the candidate’s previous experience, the level of technical knowledge, the ability to reason and think logically, how developed are the soft skills that are suitable for us.

We try to give feedback within 1-2 working days. If the result is positive, the candidate goes to the next stage — getting to know the team. This is usually a 20-30 minute meeting with the product team manager and tech lead.

There are times when we liked the candidate in general, but lacked a bit of experience or knowledge of our stack. We may decide we want to interview again in a little while. Usually the pause is 6 months. This time should be enough to catch up on missing knowledge.

Regardless of the results of the interview, it is a valuable experience. This is an opportunity to test your knowledge, learn about growth points and communicate with colleagues in the shop, exchange experience.

I wish you good luck in the interview and that, in addition to these pleasant moments, you will receive a cherished offer to the dream team 🙂

Related posts