In our company, as the head of software development, I do technical interviews for new developers. Last year I had more than 70 job interviews for Junior or Senior PHP developers in European countries.
My favorite resource for job postings is LinkedIn. There I can post many filters and reach interested parties in a targeted manner. Some negative experiences are that the filters don't work as well as intended and you also get candidates from countries that you didn't include in the filter, but that's another topic. In the end, you will receive enough candidates from the regions you have selected.
First, I go through all existing CVs to get an idea of the candidates. I am particularly interested in the professional experience, in which companies she/he works or has worked. Visit each company's website on the resume to give me an idea of the complexity of the business so I can get a rough idea of the complexity and quality of the software she/he creates. I am also interested in whether she/he has ever worked for a German employer. I will describe this point in detail in a separate post soon, but in short, the work culture in Germany is very demanding in terms of punctuality and commitment to colleagues and customers. In other countries, one would observe a casual style, which is not very popular in business life in Germany.
Other positive skills I can see from the resume are working with other programming languages and a GitHub account where I can browse some of the developer's projects. If you can show your projects, that's much better than 1000 lines on your CV. As an experienced developer, I can see immediately how the candidate thinks and uses the programming language. Does she/he have an idea of clean code, how does she/he solve certain problems, what are the names of her/his variables, methods and classes, does she/he stick to certain code styles, has she/he written any automatic tests at all? All of these are criteria for the level and experience of the developer. If the developer hasn't yet managed to produce clean, tested, and readable code, I wouldn't even consider him/her for the next part of the interview. Not to sound arrogant, but such a developer would cost our company time and money because other developers would have to fix and test their code afterwards.
After sorting out a few good candidates, I contact them via private message for the next phase. I read in a very good book that it is important to have at least one face-to-face interview with the candidate to test their knowledge before offering a programming task. This way you are polite to the candidate and you can also inform them about the business of the company. Ultimately, the candidate also decides for the company, which is of greater importance in the current market situation where there is a shortage of good developers everywhere. Therefore, as an employer, you should not become arrogant, because more companies are looking for good developers than there are good developers on the market. As an employer, you should always keep this in mind.
After the first introductory meeting, I finally give the candidate a programming assignment as homework. For this, I have set up a separate Gitlab instance with our Dev-Ops, where the candidate is invited and the task is waiting directly in his repository. This way I can also review the work with Git and later directly conduct a code review process as if this were the daily business for the developer.
For the task, I used our Dev-Ops to prepare the whole dev environment with Docker, where the candidate just needs to run "make start" and everything else works without him having to think about it. I have established this way through long observation, because firstly, knowledge of Docker and virtual environments is not a must for us, but nice to have, and secondly, different developers have different configurations on their machines, which I can hardly please anyone now because of the test task having to reinstall everything to fulfil my desired configuration. To ensure that the result of the test task is not affected by configuration problems, I can recommend this approach to everyone. Has worked very well so far.
The task itself is a simple refactoring task of a class probably written in PHP 4. I didn't use proper coding standards. Everything is written in one class and coupled together. Many code smells were used on purpose. The input and output parameters are queried from arrays without major validations. There is no adequate error handling and notification for a potential user.
The goal of the task is to end up with a clean construct that follows the principles of clean code. Everything only communicates via interfaces and is not directly coupled. The input and output parameters are mapped via DTOs and properly validated. There is clean error handling with messages that make sense to a potential user. Of course, no automatic test should be missing, because for me that is one of the most important criteria as to whether a developer has worked on demanding projects or not.
After we've done a few rounds of code review comments, I decide whether or not to move on to the next round of the interview.
I am happy to have shared our process with you. Of course, I am happy to receive constructive feedback and suggestions.