From ship to ball

According to statistics, we hire one of 10-20 applicants for the position of web developer. With such a stream, it is necessary to quickly identify suitable candidates. I don’t like all sorts of synthetic tests when selecting employees - a waste of time. The best way to check is to immediately throw into battle.

- Hi, I'm a cool web developer, here is my reuse!
- Hello, thank you. No resume is necessary, give me an account on github, take the ticket No.123 and go! Too cool for you? Well, choose what you like more from what is. There is no other work.
')
Minimum personal time, maximum objectivity.

To do this, you must quickly connect the recruit to the project code. At the same time, excluding the possibility of a negative impact on the entire project and minimizing the risk of information leakage.

We do it like this.

1. The recruit is given access to the version control system (git) . He creates his own project branch and works only in it. git (unlike svn) allows you to quickly and efficiently work with various branches (branches) and merge only necessary changes. Here, github.com comes to our meeting and $ 25 for an organizational account is not a pity. At the end of the task, the recruit does the usual pull-request , then the code scans the project master, if he is satisfied, it merges these changes with the project's master branch. Naturally, there are no passwords, codes and keys in the repository, only the program code. There is no access to the server either, the deployment of the project (it spreads to the test (stage) and production server) a couple of times a week a master project.
2. Developer base. On the production server there is a daily database backup. On the basis of a buck, a small script creates a developer copy of the database. It is identical to production, but all “sensitive information” (passwords, names, emails, hashes, etc.) is erased in it. Fresh daily developer base is absolutely safe and is always available to all developers to download via a specific link. Thus, the developer launches the project in conditions as close as possible to the combat, without the risk of information leakage to third parties.
3. Questions Of course, the developer has questions about the project. But, first, he can answer most of them by looking at the project code itself (test for the ability to read someone else's code). Secondly, all negotiations of developers on the project take place through rigidly established channels of communication with the preserved correspondence history. This may be some kind of basecamp , but, usually, it is enough to have a group chat in skype and discuss comments in the form of comments for each task in a ticket tracker. By connecting the recruit to the chat, we give him access to all the information on the project that we have ourselves. Well, if you do not understand something, ask in the same chat.

As a rule, this is enough for the recruit to be able to independently launch the project on his local machine. And this is also an important test, it is often the selection that ends there.

Advantages of this model:

1. Maximum reduced risks . Developers do not receive any access to the server at all (excluding github). If you are afraid that a rookie will steal your code and launch his own project, then you are mistaken. If the code is simple and it is easy to run it, then there is no need to steal anything, it is easier to rewrite it again, and if it is complex and large, then to launch such a project you need more than a stolen repository (at least a user base). In addition, a successful project is far from code + base ... if this did not convince you and you, nevertheless, are afraid for your code, then it is probably so big that it’s time to break it into separate modules and repositories, then you can give each developer access to a specific code.
2. High speed connection and testing of a new developer. No HR problems. Got a letter from the finder? They gave access to git, link to db, task number and forth, after a day they asked for the result and looked at the development process in github.
3. Good consideration of the requirements of the developer. We also do not forget that the developer also has his own requests and requirements for the project, in our case, he immediately sees what he will work with, how clear the code is for him, how much he understands the principles of the project’s functioning in general, whether he wants to work with the people who wrote this code and Corresponded, etc.

Very interesting as the process of selection and inclusion of new developers in other teams?