The ideal (probably) interview of a mobile developer-middle
Recently, there have been so many stories about bad interviews in Habré that sometimes doubt creeps in, and are there good interviews in nature? So for the sake of diversity in this, we will look at an example of a good * approach. The story will go from the point of view of the employer’s developer who is directly involved in the hiring process.
* probably
A small grocery team (30-40 people) within a large company (several thousand people). The team includes all those involved in the project: fullstek developers and front-runners, designers and interfaceologists, testers, PR specialists, analysts, authors of texts, etc. In general, we are trying to outsource smaller work to other projects, and mobile development is no exception.
Our mobile application is cross-platform, written in Xamarin Native for iOS and Android. At the same time, we are fully prepared to take moderately an experienced developer who has written only for one platform, provided that he is ready to study development for the second OS.
Either the developer stumbles upon a vacancy and sends a resume, after which HR sends him some clarifying questions, or HR stumbles upon a developer's resume, after which he sends him about the same series of questions.
These questions are the minimum filter for adequacy; there will be no technical questions. Further resumes and responses are transmitted to the developer already by the employer, and he decides whether to go further or not. Over the past month, I looked at a couple of dozen resumes, and I have no idea what the candidate should write and answer, so that I had to say “no” at this stage. Write on Android developer’s job post “write only for iOS, because Android - it sucks”?
The test task is given without time limits, although in practice it should take no more than one evening. As part of the test application will be:
However, not all developers are ready to write a test, so we immediately offer an alternative - send the code of some ready-made application, which will be the same set (network, database, navigation on the screens, user input). Well, then there are options:
According to the results of the test, we either call the developer for an interview, or give a refusal, but in the second case a detailed review will be given - what is done well, what is debatable, what questions arise, what to read and so on. As a result, everyone wins:
At the interview, there will definitely be not only conversations for life and about the previous job, but also questions about the test task. At this stage it is quite simple to understand whether the person wrote the test himself, whether he understands what is written there, whether he can justify this or that decision, what is his horizon and so on. Questions are asked not in the air, but with the ability to take the keyboard and poke this very code. Sometimes we ask you to rewrite something a bit on the go or correct it, ask questions like "and if there was such a requirement ..."
Next will be 1-2 small practical tasks, they depend on the test task. Again, we give the keyboard (connected to a computer, a computer with a monitor!) And ask you to write or edit something. One of my favorite things is to give a working, but poorly written, function of lines for 10-20 and suggest that it be refactored. It immediately becomes clear whether the candidate has a chuik for a “bad code”, what he knows about the language constructs, whether he can read someone else’s code and further down the list.
And that's all. After a maximum of a couple of days, we will give the candidate an answer. However, most often the answer is given on the same day). And in case of refusal, there will again be an adequate justification. Well, if it is not enough, the candidate can always ask the developers for contacts with interviews to clarify some points, and he will be given them with a high probability.
Truly. Could even send a twin . Well, he could not deceive, we just made a mistake in the interview. In such a case there is a wonderful thing called "probation." Plus, work in a large company (at least in our case) - failure to complete a probationary period does not mean 100% separation from the company. In the end, the developer could be not bad, but did not take root in a specific team - in this case there are always alternative projects.
Yes, I confess, then I sinned in small polls and interviews without a test. Spent a lot of time, and his, and someone else. So when it came to a new search for a developer, I decided to try a different approach. Developers write code? Fine! Show me your code, and I’ll tell you if we should talk.
And here is the situation with cunning. A decent stream of back-tenders / full-stack of developers goes to our company, and there are several hundred such developers in the company. Therefore, the process of their recruitment is already quite settled and standardized. There are still few mobile developers in the company, so it is easier for us to experiment with approaches to the interview.
I am waiting for you in the comments. Let's debate ;-)
* probably
Disposition
A small grocery team (30-40 people) within a large company (several thousand people). The team includes all those involved in the project: fullstek developers and front-runners, designers and interfaceologists, testers, PR specialists, analysts, authors of texts, etc. In general, we are trying to outsource smaller work to other projects, and mobile development is no exception.
Our mobile application is cross-platform, written in Xamarin Native for iOS and Android. At the same time, we are fully prepared to take moderately an experienced developer who has written only for one platform, provided that he is ready to study development for the second OS.
Stage 0 - met two loneliness
Either the developer stumbles upon a vacancy and sends a resume, after which HR sends him some clarifying questions, or HR stumbles upon a developer's resume, after which he sends him about the same series of questions.
These questions are the minimum filter for adequacy; there will be no technical questions. Further resumes and responses are transmitted to the developer already by the employer, and he decides whether to go further or not. Over the past month, I looked at a couple of dozen resumes, and I have no idea what the candidate should write and answer, so that I had to say “no” at this stage. Write on Android developer’s job post “write only for iOS, because Android - it sucks”?
Stage 1 - test task or sample code
The test task is given without time limits, although in practice it should take no more than one evening. As part of the test application will be:
- three screens: two linked lists + data entry form, which, if desired, can be replaced with a modal window
- work with the network
- work with the data warehouse (the task implies the database, if the developer can substantiate another conclusion - you are welcome)
However, not all developers are ready to write a test, so we immediately offer an alternative - send the code of some ready-made application, which will be the same set (network, database, navigation on the screens, user input). Well, then there are options:
- the application is too small, the code is not indicative or causes too many questions, please do our test
- the application is suitable, but there are nuances - please make minor improvements (less than in the evening)
According to the results of the test, we either call the developer for an interview, or give a refusal, but in the second case a detailed review will be given - what is done well, what is debatable, what questions arise, what to read and so on. As a result, everyone wins:
- The candidate receives the code, which can then be reused at another interview with similar principles, as well as feedback to work on yourself. Does it work? Well, at least we received tests from us, originally written for other companies, so it looks like it works;
- the employer saves time on questionnaires and other garbage. And how happy is an introvert interviewer, who doesn’t need to do 1-2 interviews per week, if you only knew!
Stage 2 - Interview
At the interview, there will definitely be not only conversations for life and about the previous job, but also questions about the test task. At this stage it is quite simple to understand whether the person wrote the test himself, whether he understands what is written there, whether he can justify this or that decision, what is his horizon and so on. Questions are asked not in the air, but with the ability to take the keyboard and poke this very code. Sometimes we ask you to rewrite something a bit on the go or correct it, ask questions like "and if there was such a requirement ..."
Next will be 1-2 small practical tasks, they depend on the test task. Again, we give the keyboard (connected to a computer, a computer with a monitor!) And ask you to write or edit something. One of my favorite things is to give a working, but poorly written, function of lines for 10-20 and suggest that it be refactored. It immediately becomes clear whether the candidate has a chuik for a “bad code”, what he knows about the language constructs, whether he can read someone else’s code and further down the list.
And that's all. After a maximum of a couple of days, we will give the candidate an answer. However, most often the answer is given on the same day). And in case of refusal, there will again be an adequate justification. Well, if it is not enough, the candidate can always ask the developers for contacts with interviews to clarify some points, and he will be given them with a high probability.
But the candidate could cheat
Truly. Could even send a twin . Well, he could not deceive, we just made a mistake in the interview. In such a case there is a wonderful thing called "probation." Plus, work in a large company (at least in our case) - failure to complete a probationary period does not mean 100% separation from the company. In the end, the developer could be not bad, but did not take root in a specific team - in this case there are always alternative projects.
So, stop! I recognized the team in question, interviewed it a couple of years ago, and the scheme was very different there.
Yes, I confess, then I sinned in small polls and interviews without a test. Spent a lot of time, and his, and someone else. So when it came to a new search for a developer, I decided to try a different approach. Developers write code? Fine! Show me your code, and I’ll tell you if we should talk.
But I learned the company! I got involved in another project, and there, too, everything is not so!
And here is the situation with cunning. A decent stream of back-tenders / full-stack of developers goes to our company, and there are several hundred such developers in the company. Therefore, the process of their recruitment is already quite settled and standardized. There are still few mobile developers in the company, so it is easier for us to experiment with approaches to the interview.
There are other disadvantages to this approach!
I am waiting for you in the comments. Let's debate ;-)