How do I interview programmers

    Here, many tell how they conduct interviews. Well, I also decided to tell how this happens with me.

    I am a leading developer. This means, in particular, that I can independently decide on how many and what kind of specialists should be hired to carry out the project. The salary level, as a rule, is initially determined by me, then the director / owner of the company approves it.

    As for the salary. Usually in such topics they write, they say, "you offer a low salary, but you demand a lot." So, the following describes the interview of the minimum complexity, which I conduct with all candidates for any position and at any salary. Those. In my opinion, this interview should be held by anyone who calls himself a programmer, regardless of salary.

    Yes, what kind of programmer are we talking about. I am developing web projects - website engines, online auctions, hosting management systems, intranets and other nonsense, where there is a base, engine and web interface. Accordingly, I am recruiting employees who are versed in such things.

    I do not ask philosophical questions such as "By whom do you see yourself in five years." This is the human resources department. I speak with candidates solely on technical topics.

    The interview consists of two parts - theoretical and practical. In the theoretical part, I ask the candidate to briefly tell what he knows about all the technologies mentioned in the resume.

    Here, as a rule, candidates make the first mistake - they write in the resume what they really do not know. Classic dialogue:

    - Where did you use XSLT?
    - Well ... they told us something at the university about this ...

    Or (real case):

    - Are you familiar with the operation of DNS?
    - Well, yes, there it was ...
    - Well, tell me, what level is the domain vkontakte.ru?
    - Well ... of a high level, probably ...

    I can understand if a person five years ago used some rare, not widespread technology in the project, and now does not remember how it worked there. But if a person says "good knowledge of MySQL" in a resume, but in fact, "Yes, I don’t remember, it was a long time ago and, to be honest, I worked with muscle a little ..." then this is a big fat minus. If you don’t know something, don’t powder my brain and don’t take time.

    In general, the theoretical part is highly dependent on the candidate’s resume. Regardless of the resume, I usually ask two questions - “What is the most difficult project you have done” and “Have you ever worked with any external APIs, such as payment systems or Google cards”. If you had a business and clearly tells - this is a plus. A remark such as “receiving notifications from Yandex money sucks, webmoney has been made much more convenient (with the rationale for this opinion)” is a big fat plus.

    The set of practical questions I have long settled down and looks something like this:

    1) Testing of SQL knowledge

    Task: “There is a table with two fields - Department and Employee, it is necessary to display those departments in which more than five employees work.” The

    candidate’s understanding of the work of group functions is checked . and the HAVING operator.

    Half of the people with the group are familiar theoretically. The other half, familiar with the grouping, most often produces the following result:

    SELECT otdel FROM table WHERE COUNT (sotrudnik)> 5 GROUP BY otdel

    This option, of course, does not work, since aggregate functions cannot be used in the WHERE clause.

    Rare units are generally familiar with the HAVING transcendental operator. At the expense of HAVING'a I have a bzik. Personal observations show that if a person knows and knows how to use HAVING, then this is an intelligent person who read the documentation and solved practical problems. It's like a litmus test.

    A candidate who cannot write this request immediately gets a big bold minus.

    2) Testing the knowledge of the working environment

    Task: “The test.local site is open in the browser, you need to find the directory where the files of this site are located.”

    Checks the candidate’s knowledge of the DNS system (determine the IP of the server), the ability to work with SSH (go to the server), understanding what sites give a certain web server (no tricks, Apache is used), the ability to read the Apache config and find the DocumentRoot directive there, pointing to the desired directory.

    In a significant part of people (this surprises me and makes me laugh at the same time), the brain explodes when trying to understand what “test.local” is. The next part is lost at the resolving stage of this host (they do not know about host or at least about banal ping). Well, not everyone else can read the Apache config. It is especially difficult to read the config in which virtual hosts are moved to a separate file with the Include directive.

    3) Testing the knowledge of Perl

    Here I have this position: I never ask tricky questions, the answer to which you’ll immediately understand the hell, but if you realize that, you won’t use it anywhere with benefit. Those. these are questions like “what will happen if I write print $ i ++ + ++ $ i” or “write a recursive regular expression to check nested brackets”.

    The standard task is quite simple: “Write a script that reads a text file, processes it line by line, and displays the result in a browser. The file contains e-mails, processing consists of checking e-mails for validity using a regular expression. ”The

    ability to create an executable perl script, the ability to work with files, the experience with regular expressions and the ability to display the result in readable view in browser.

    Many, having written the script “hello world”, calling it from the browser and receiving a 403 Forbidden error, get into a dead end. I don’t know how it turns out, but many are not aware that the script needs to be made executable. And who in the know - those often can not remember the command change permissions chmod.

    Further a mystical mystery is reading from a file. If the opening of the open descriptor is familiar to almost everyone, then loop through \not everyone guesses.

    I ask you to write the regular for checking e-mail as much as the candidate is able to do this in a few minutes. If the writing of the regular period takes longer than five minutes, I ask you to stop there. In almost 100% of cases, the result is as follows:

    /\w+?@\w+?\.\w+?/

    I consider this result unsatisfactory. Usually in this case I ask “backfill question” - “what is an invalid character that will pass this test?”. In response, I want to hear "underline." Almost none answers.

    And, finally, the output to the browser is another stumbling block. About half do not realize that the output of the result itself should be preceded by the output of the HTTP header. The other half, which remembers that something needs to be withdrawn, does not remember what exactly needs to be withdrawn.

    According to the situation, I can also ask you to complicate the script - make the check into a separate function, put the function into the module, and, for the most sensible, make the module object-oriented. About a quarter of the candidates reach these complicating steps.

    The results of the interviews invariably upset me. The vast majority of candidates are terrible.

    Also popular now: