| What bothers me about all these is how irrelevant they all are to actual day to day programming on a project. Like okay cool you know how to do the Fibonacci exercise. What now? Do you know how to write SQL queries? Have you ever mapped an ORM to a data store? What about rate limiting an API? Ever had to setup Single Sign On? Have you ever scaled anything from 100 users to 100,000 users? How do you handle job running? Concurrency? How would you debug your server locking up due to 100% CPU usage? Ever configured a dev environment on local with xdebug? Breakpoints? Command line tools? Ever normalized data between multiple third party APIs? What does normalization even mean to you? What about unit testing? Mocking data pre-test and cleaning up after test? How do you make it fast? What's the autoloader? How do you properly setup composer? Tabs or spaces? Why? Windows, OSX, or Linux? Why? Favorite IDE? Why? Are their opinions so strong they can't work with others? On and on it goes. In the past 6 months at my job I've dealt with all of the above issues and more. I would still probably fail most of the exercise in your Github repo. Mainly because all of them are irrelevant to the actual work and honestly I can't be bothered to sit here and memorize various math algorithms that have quite literally nothing to do with the work. PHP comes with with 13 different sort functions. None of them test you for how to write a bubble sort. I'd rather a candidate know when to use one over another instead of knowing how to write just one or two of them from scratch. Here's the thing though. I've written bubble sorts before. In college. When learning C & Java. In no way shape or form do I ever practice them or actually remember them at a moments notice. I look them up like a normal person if I ever actually need them. When I interview a candidate I don't use any of these nonsense exercises. I have one small code exercise at the end which makes use of recursion. The rest of the interview is an open ended series of questions on systems and just basic "shooting the shit" style questions. The nuance of how you answer the questions tells me everything I need to know about a candidate. On the flip side if I'm the candidate and someone asks me one of these I know they actually suck at interviews and my immediate instinct is to walk out. I try anyway to be polite and not burn any bridges and most of the time I'll come up with a correct solution but again my initial instinct is "I don't actually want to work here anymore". So what do you do instead? Be creative. Have fill-in exercises. Write an abstract class and an interface and have them build you a class that implements both. Write some code with obvious mistakes. Have them fix it. Build a full from scratch login system. Have a user already in the database with a hash already there. Make them fill in the authenticate function. Watch them not use password_hash and ask them why. Make them use Google. No exercise should take more then 15 minutes. The majority of the interview should be you digging deeper into their previous roles. Have them tell you success stories or cool hacks they've put together. You'll learn way more about them both as a person and as a developer. |