3 tasks that filter out 9 out of 10 Senior PHP candidates

    Candidates - “Senior PHP”, with experience, go through the initial selection by resume / cover letter before the interview, that is, only those who look like decent programmers get interviewed. Interviews are conducted remotely - Skype / ICQ (without voice). Those. it is theoretically possible to google, although I ask you not to.

    So, the tests that drop the "type of programmers":

    1. count the number of hits

    Task: I have banner.php, let it display a static image, some kind of banner. We include it on the page.

    I just need to know how many times we showed it. Please write the code.

    If the candidate offers some simple solution, to count hits in the Apache logs, I complicate the conditions, for example, say "logs are off", or "let's use the database", or "how many are unique?"

    Surprisingly, only a few are able to offer something real. For some reason, everyone rushes to use sessions or store something on the client side. The most original was “you need to use a super-logger from facebook. I don’t know anything about him, but I highly recommend it. ”

    2. the basics of working with unix shell + a little creativity

    Task: I have cleanup.php which does something critical there. I need the script to run every 13 seconds.

    Most of them offer to hang on the crowns, I ask you to write down the steps, what should I do for cronjob to appear (taking into account that I have SSH access). Then it turns out that the crown has only minute tasks, and some kind of “hack” is needed. Again, it is possible to complicate the conditions if the candidate proposes a solution in order to understand how deep and wide he is in the “topic”. Most merge saying "I shove poorly in linux-shell, admins did everything for us."

    3. few databases - SQL (mysql)

    Task: I want to store my library in the database. I care about the names of the books and the authors - nothing else needs to be stored. Suggest a table structure.

    Half of the candidates do not know what many-to-many are and cannot decide which is better - store author_id in the books table or book_id in the authors table.

    If everything is ok with the structure, I ask you to pull out a list of books written by 3 co-authors. That is, get the report “book - number of co-authors” and filter out those with less than 3 co-authors.

    For 3 months, while I give this test, I can recall the names of the candidates who dealt with this in pure SQL with a single query.


    These three tasks weed out 9 out of 10 candidates. Sometimes I feel sad and vague doubts torment me - maybe I miss sensible programmers? Perhaps the candidates are worried and simple things “fly out of their head”, but then what will happen when they get on the team - “release tomorrow and our horse wasn’t lying around”? Maybe it’s worth setting up candidates in advance, saying, “be prepared to write code at the interview”? Wouldn't it be worse? What do you think, would it hurt you to go through an adequate interview?

    Also popular now: