Ok, so it's rant time. If there's one thing that gets to me, it's interview questions. Having been on both ends of the interview table, it's quite apparent that a lot of agencies (or should I say their staff) seriously lack interview skills. I'm referring more to the type of questions and challenges they pose to their candidates than to their actual technique.

Furthermore, there are a few practices in place by many agencies today that I feel are both archaic and profitless.

Imagine this scenario. You've applied for a job, you get an email response saying that your credentials look good and they would like to set up a meeting with you. Attached, you find a Word document containing questions that you need to answer in order to actually pin down an interview date. I have seen this quite a few times and here are some of the actual questions I've seen:

• What is the purpose of the PHP function strlen?
• What are the arguments accepted by the PHP function str_replace and in what order?
• What are the main differences between PHP4 and PHP5?
• What is a stored procedure in mySQL?
• What does JSON stand for?
• What does AJAX stand for?

Ok, so firstly, why are these questions stupid. Well, the one on stored procedures is ridiculous because strictly speaking, the question answers itself in that a stored procedure in mySQL is a procedure that's stored within mySQL.

Asking what order arguments are handled by various PHP functions is universally stupid. Developers don't memorise what order function arguments are passed. Sure, you're likely to remember the ones for the functions you use often, but you're not going to memorise them all. The amount of times developers go to php.net/function_name to get a function's arguments or argument order in a day is countless.

Finally, the whole act of sending questions to people in an email (be them stupid questions or not) is frankly ridiculous. You will not find a candidate that will honestly sit down and answer them all from memory, leaving out or 'best guessing' the ones that they don't know. At the end of the day, they want this job, if they don't know the answer to one of the questions, they're going to Google it! Think before you send documents full of questions.

Ok, next up. Stupid questions during interviews. Given, asking the questions above is more practical in a face-to-face interview environment than via email (although they're still stupid questions) as your candidate can't consult Google to give you the answers. However, people interviewing candidates need to realise that most developers don't have an eidetic memory. They aren't going to memorise every single PHP function and its arguments and the order in which they are passed. That's what the PHP documentation and Google are for. Like it or not, developers consult these resources countless of times every day, regardless of level or ability.

So with this in mind, avoid stupid questions. Questions like 'What does the ksort() function do' is redundant and isn't much of a reflection on a developers ability. Ok, so a developer should have a basic knowledge of what the most common PHP functions do, but few know all of them off the top of their head. I say this because if we need a function that does something and we don't know what it is, we consult Google or the PHP documentation. If that fails to produce a solution, we write one. Simple.

Another one that's had its time. The fizzbuzz test. For those of you who aren't familiar (and I don't think there are many who aren't!), the fizzbuzz test was a test devised to (apparently) test a developers reasoning skills by posing them with a problem they have to think about and then producing the best way they believe to solving it. It's usually posed something like the following:

"Write some code that counts from 1 to 100. For each number, if it is divisible by 3, print the word 'fizz'. If it is divisible by 5, print 'buzz'. If it is divisible by both 3 and 5, print 'fizzbuzz'.

Just to clarify, a classic textbook answer would be:

for($i = 1; $i <= 100; $i++) {
	if($i % 3 == 0 && $i % 5 == 0) {
		echo 'fizzbuzz';
	} else if($i % 5 == 0) {
		echo 'buzz';
	} else if($i % 3 == 0) {
		echo 'fizz';
	}
}

If you have someone who is a bit more masterful with PHP and wants to show off their knowledge of ternary operators, you might get something like:

foreach(range(1, 100) as $i) {
	echo ($i % 3 == 0) ? (($i % 5 == 0) ? 'fizzbuzz' : 'fizz') : (($i % 5 == 0) ? 'buzz' : '');
}

Both answers are perfectly acceptable and would 'pass the test' so to speak. The issue is that because this test has enjoyed so much popularity, everybody knows how to do it - proving nothing about your candidate's ability. How would you feel if you hired a new developer who answered all your questions on what PHP functions take which arguments, completed a successful fizzbuzz test and then came to work for your company and started writing SQL queries directly in your layout code? Big mistake right? And it's your fault for not structuring your interview process in such a way that you know you're getting the right person.

So what is a good interview process? Well, in my experience, they are few and far between. However, I can give you my own thoughts on this and leave it up to you to regard them how you please.

First up, don't ask too many close ended questions like those mentioned earlier in this post. One that I do ask and have also encountered, is "What are some simple measures you'd implement to improve the performance of a high availability website" mainly because it isn't as closed ended as it would first appear.

Obviously, the number of options here are great. Some very simple ones would be:

• Compressing or minifying front end assets (i.e. CSS and specifically JavaScript).
• Insuring that the database tables are correctly indexed (i.e. any fields that are being used to search for or order result sets).
• Insuring that the database fields are cast correctly (i.e. if you're using an on off flag, make it a boolean field instead of integer), and also making sure that the length of fields is set appropriately (i.e. if you're storing a postcode in a VARCHAR field, you only need a limit of 8 or 9, not 255!).

Some more advanced answers would be:

• Using a CDN (Content Delivery Network) to handle assets (i.e. images or videos)
• Caching your content (HTML for example) using something like APC or Memcache
• Building a site off a framework in the first place - lots of which (Symfony, Zend etc) have very well optimised code and caching systems built in.
• Server clustering and load balancing (and having separate mySQL servers for reading and writing)

Another good example is to ask them to write a class that does something. A fairly typical one is writing a class that describes an animal ~insert fluffy animal breed here~ - usually a dog. This is a good concept, but it's relatively simple. You'd have properties for gender, breed, name, appearance etc, and methods for things like bark (if said animal is a dog of course), walk, wag tail etc. But that's all simple stuff. What I'd look for is depth of thought. For example, it would need to eat, so perhaps you'd have a hunger property. As the the 'eat' method is run, it decreases the hungary property. This just demonstrates a good depth of thought rather than your basic object skeleton that anybody with some basic OO knowledge could do.

Another good suggestion for this (depending on your business type) is to ask the candidate to write a simple basket class or a basic version of something you use quite a lot. Taking a basket class as an example, you'd want to see methods to add and delete items from the basket, as well as having quantity and price parameters for each item in the basket (which in turn, affect the basket price). It'll need methods for porting the basket around (serialising the object and storing it in a session rather than just having the whole basket stored in session variables for example).

It would seem like companies that are particular in their hiring process (Facebook, Apple, Google, Amazon etc) truly have this hiring process down to a T. Here are some of my favorites:

"Given the numbers 1 to 1000, what is the minimum numbers guesses needed to find a specific number if you are given the hint "higher" or "lower" for each guess you make." - Facebook.
This is great because it requires the candidate to not only demonstrate logic, but also math and reasoning. There is no 'easy way out' of this question.

"There are three boxes, one contains only apples, one contains only oranges, and one contains both apples and oranges. The boxes have been incorrectly labeled such that no label identifies the actual contents of the box it labels. Opening just one box, and without looking in the box, you take out one piece of fruit. By looking at the fruit, how can you immediately label all of the boxes correctly?" - Apple
This little gem is a favorite of mine and took me a good amount of thinking to work it out.

So there you go, that's another infrequent post from me. In summary, don't send candidates questions sheets for them to Google and spare a little thought for the way you are actually going to interview them because it could make the difference between having an average development team and a great team.