iOS interview at Vivid

Perhaps you know about Vivid, heard somewhere or see it for the first time. We make one of the fastest growing and most promising financial services in Europe. Not to be unfounded, here are some of our metrics:

Downloads and active users in Germany from 03.21 to 06.21
Downloads and active users in Germany from 03.21 to 06.21
Number of features in apps in Q4 2020
Number of features in apps in Q4 2020

One of the reasons for achieving such results is our team. In this article I will tell you how we formed the team, how our technical interview has changed and what is most important for us in the candidate.

Disclaimer

In no way do I want to condemn or discredit the interview processes in other companies. Everything that you consider as such is just our view and nothing more.

Few introductory

There were 2 of us at the start. We were faced with a difficult task – to find leading developers for each of the products included in our application. Looking for seniors is already a difficult mission, and when you are looking for them in a company without a name and without the opportunity to tell at least something about the product due to a strict NDA, the mission becomes impossible. But, as we know, the road will be mastered by the one walking, so we had to be patient and do everything possible for the candidate to choose us.

What depends on the interviewers? – they just ask questions. In fact, almost everyone, since good specialists take technical interviews more seriously and pay attention to various little things. It is unlikely that the senior will be delighted with interviewers who do not understand the topic, behave insecurely or ask strange questions. In addition, in order not to have such obvious shortcomings, it is necessary that there are some advantages.

Our features

In addition to the main responsibilities of interviewers, we tried to do the following:

  • Have a candidate and create a friendly atmosphere

  • Asking questions about the situation, not a prepared script

For the first point, we used silent talk before the interview (these are not questions about experience or a resume, but what helps to get to know the candidate better), sometimes joking to defuse, adjusting to the characteristics of the candidate.

Interview case

Once we ran out of time for an interview, the time in the meeting room ran out, and there were no free ones. I had to finish an interview in a cafe. It seems that the candidate liked it – now he works with us.

For the interview, we did not prepare a list of questions – we prepared topics that we want to talk about. Such topics were: Swift (where without knowledge of the language), UI (since we have a lot of it, it is 95% custom and sometimes non-trivial) and architecture (this is very important for the lead developer). For each topic, we tried to ask only what is mainly used in day-to-day development and what is related to our application. Of course, sometimes we delved into a question to understand how well the candidate knows the topic, but there is a subtlety – if suddenly a person does not answer or answers incorrectly, we do not put a strong emphasis on this, since these are optional questions and answers to them not everyone has to know.
Practice was also very important for us, since this is what reveals the developer’s abilities better than any questions. We had prepared various tasks that we chose depending on the situation. Among them there were no questions on algorithms, because we do not consider them indicative – they show the ability to find solutions (or remember them), and not the ability to write code. Our tasks showed how the candidate usually writes his code, what constructs he uses, how optimal his solutions are and how he thinks.

The most difficult task

Once the task was born right during the interview. While I was chatting about my topic, my colleague sketched out the code and requirements. Who cares follow the link… I will say right away that we went a little too far with the complexity, but the candidate was so eager to solve the problem that he took it to his house and sent the solution the next day.

Interview format

Experimenting and changing is our company. Interviews are no exception. We tried different formats: one interview for 1.5 hours with questions “according to the situation”, a theoretical interview for 1 hour and a practical interview for 1.5 hours, a theoretical interview for 1 hour and a test task. In the end, we came to the following:

  • 6-question pre-interview screening.

  • One interview for 1.5-2 hours. Of these, 10-20 minutes for communication with the candidate on non-technical topics, 30-40 minutes for coding and the rest of the time for theory.

  • The interview is always conducted by 2 people – this gives a more objective assessment of the candidate after the interview.

  • Each interviewer has a different topic. This allows you to build communication more logically, since the other interviewee will not ask his questions, leading the conversation in the other direction or interrupting the current thought.

Screening

Our screening consists of 3 easy questions and 3 medium difficulty. There are answer options for every question, but they are not voiced for every question. It is easy for HR to carry out such screening, since it practically does not require special knowledge and training.

The screening contains such questions, the answer to which does not take a long time to find. At the same time, these are not hackneyed questions, which candidates like (judging by the polls).

Digits:

  • Average screening time – 4 minutes

  • Percentage of candidates screened – 75%

Technical part

The main problem in our previous interviews was the lack of a clear plan. As I said, we tried to choose the most appropriate path right during the interview. Sometimes this led to the fact that at some point we did not know what was better to ask next and the candidate felt a certain unpreparedness on our part. In addition, this method of interviewing is difficult to teach new interviewers.

Having understood our problems, we reworked the technical part. The interview now has a “script” which is a tree diagram in Miro.

An example of one of the interview threads
An example of one of the interview threads

We begin communication on a specific topic with an open-ended question, which suggests an extensive answer. Further, depending on the answer, there are ramifications affecting different areas of the topic. The further we move along one branch, the more difficult the questions become.

There is one special branch – Swift. To move along it, we carry out live coding, in which the candidate solves the task at which the requirements are added or changed (just like in real life). The task consumes almost the entire syntax of the language with its small volume. In the course of the solution, we ask questions. For example: “Why did I use a class and not a struct?”, “Can the problem be solved differently?” etc.

Thus, we have a “framework” for the interview. He allowed us to:

  • quickly understand what to ask during the interview

  • conduct interviews in a more structured manner

  • quickly train new interviewers

How we evaluate candidates

One cannot but touch upon such a subjective topic as the assessment of the candidate’s level. We share developer levels like many others: Junior, Middle, Senior. We can also add + or – to each level to make the assessment a little more accurate.

To determine the level, we use the following markers:

  • Previous experience. The more complex and varied tasks there are, the higher the level.

  • The solution of the problem. The faster and more correctly the problem is solved, the cleaner the code and the better the decisions are justified, the higher the level.

  • Answers to theoretical questions. Here it is important for us to understand whether knowledge of the theory is supported by practice. If the candidate answers the question – this is good, but if he also gives examples from experience or explains in his own words, then even better. In short, understanding is more important to us than knowledge.

  • Moderate perfectionism. This is when the candidate thinks through the decision well enough, but does not spend a lot of time on minor trifles.

After going to work

Each new developer goes through onboarding and also gets a mentor. Mentoring exists not only in our team, but throughout the entire project. This is a customized process in which the mentor helps to quickly join the project, get to know colleagues, and also helps to solve problems at first.

Finally

I hope you enjoyed the article and found something useful in it. We will be happy to answer your comments – do not hesitate to write. You can also read our other article on hiring. If you are interested in getting an interview, keep an eye on vacancies here

That’s all. Good luck with your interviews everyone!

Similar Posts

Leave a Reply