This Dev For Hire

Next response to “Where did all the PHP programmers go?”

Yesterday I have read a very interesting article touching the subject of hiring PHP programmers with a conclusion that most of the people complain about the interviewing process rather than answering questions. It’s a very interesting read, so take a moment and get back to me when you have finished - Where did all the PHP programmers go?. Now, those are very good points but I have to admit that I too have been interviewed on paper too many times. And it has some major drawbacks:

1. Writing on paper is different than writing on screen. When it comes to programming, you can’t prepare interfaces upfront and fill in the details later just because you can’t insert new text between already written lines. And that’s a thing you do constantly while writing code. Of course it’s very easy to give your potential employees more familiar environment - you can give them at least a basic text editor (like notepad) on your laptop. It will really help (my own experience speaking)
2. PHP is a messy language. It’s interfaces are very inconsistent so it’s very hard to memorize it all. Good IDEs (not a Dreamweaver) negate this effect. You can give your interviewees an access to the manual. When a programmer writes code he constantly uses the manual when he needs it. Why do you want to test his memory and not his skills?
3. Programmers are used to look at a code that has syntax highlighting turned on. Looking at a plain black text is just a senseless handicap - you can’t see things you see everyday in a snap. You have to actually browse and read everything every time you have to look IN THE CODE for something you wrote earlier.
4. PHP veterans use libraries. Standard public ones as well as their own. They seldom work with pure php function calls nowadays. Especially when it comes to database calls and some obscure mysql functions (ie. you don’t have to know the difference between mysql_fetch_assoc and mysql_fetch_array from the top of your head!).
5. You don’t need to know sorting algorithms by heart these days - all decent languages come with sort functions already implemented in the language. What you need to know is what sort method to use in which circumstances. If quicker sort is harder to develop you use the easiest one (like easiest built in function in the language). Premature optimization is a root of all evil they say. You use better sorting solution when the easiest one is not performing well. But this is after you test the almost finished software.
6. And last - experienced programmers will be much more handicapped by all this than novice programmers. That’s because novice programmers are learning on the very low language level (think function calls) while seasoned programmers are thinking globally on much higher level. They generally think OOP and interfaces which are de facto language independent. Not to mention they are used to their working conditions stronger and then even changing color of hightlighted variables can result in slower thinking.

So, the bottom line is - first make sure what you want to accomplish and then make your tests accordingly. Most of the interviewers are testing memory instead of programming skills. And when they do test skills they test some basic stuff rather than things which will be required on the job.

UPDATE: If you’re interested in a more practical interviewing process you may want to read Nick Jenkins’ reply to the same post here - http://blog.nickj.org/2008/06/05/response-to-where-did-all-the-php-programmers-go/.

See you next time.