A lot of people would disagree with me about this. Take that as you may.
To talk about the issue of an interviewee not being able to write out code with pencil and paper: Do you paint with crayons?
If you are an amazing digital artist in Photoshop, say Burt Monroy for example, then you should be able to paint with crayons right? If you work for Lucasfilms as a top-tier 3D artist who works in Maya, shouldn't you be able to chip Michelangelo out of stone then?
What most NON-CODERS, which I am assuming includes you, do not realize is that a programmer's brain is wired to work in a certain environment. We have learned for years how to code in particular ways, whether via a straight text editor(Textpad for me!) or an integrated IDE(Eclipse or Visual Studio for example).
So you take someone who's already stressing about making a good impression during an interview and then ask them to write down code on a piece of paper. That's the absolute worst thing you can do. You're asking the person to use a different part of their brain to tackle a problem that hasn't been trained for that job.
Put the person in front of a computer, such as a laptop in the interview room put there for specifically this purpose, and THEN give them a problem to solve.
If the person still can't pull code out of their ass at this point, then you're right. They're morons. Otherwise, you will be surprised at what some of these people can do that you've looked over.
For years I have had candidates code with pencil and paper and never had a single objection.
The purpose of the coding exercise was never to see what they would come up with or how well it ran, it was to learn more about them in the discussion afterward. And I have found that this was best accomplished with a big sheet of paper and 2 pens, (one mine, one theirs). I imagine a white board would work as well, but for 2 people it's not necessary.
I also found that they were more relaxed working off-line, where nothing could be judged or examined. It was just me and them and something specific to talk about. That's all.
If you ask an F1 engineer to fix a bicycle with a crescent wrench, do you think he is going to be lost without his $250K set of tools? I don't think so.
The blogger is not talking about major pieces of code, he's talking about fundamentals. So, yes, the programmer should be able to do it on paper. And I bet if you ask a Lucas Arts 3D artist to draw on paper a basic shape, he/she will blow you away with what they produce.
In addition to this, I suspect the interviewer would not object to minor errors in syntax, function names and the like if the code was fundamentally sane. The sort of problems he said he asked to have solved were trivial.
You need a better metaphor. I cannot imagine a painter who, when handed a crayon and told to draw something, couldn't at least produce a simple sketch. I just can't think of a single example.
Maybe it's a bit like asking a cook to write down step-by-step, the recipe and directions for a meal they've never cooked before. Without access to their learned abilities to improvise with given ingredients, smelling/tasting the mixture, comparing notes with similar recipes they have, etc.
Good cooks can imagine flavors and guess at timing and ingredients for food they've never tasted (much less prepared) just as good painters can visualize a work in their head before ever putting brush to paper.
Perhaps asking them to create with crayons a picture that looks like it was painted. Asking someone to, say, draw out a quick flow chart on paper would be fine, but to get running code I'd want to be able to run it as I go.
I do interviews on occasion and I usually ask for some source on the whiteboard. Generally I only do that with people interviewing for junior positions, though.
I usually ask for a quick implementation of the fibonacci algo in their favorite language. I also tell them that sloppy is OK - so brace placements, etc are not relevant.
I hardly think it's too much to ask for a candidate to implement a simple, standard algo in their language of choice on paper/whiteboard.
PHP programmers tend to do very poorly in this area, unless they are programmers who also do PHP. The problem to me seems to be that the PHP environment doesn't encourage experimentation with algorithms, data structures and low-level optimization. Add to that the more-or-less haphazard manner in which most PHP code is organized and you've got a scripter who'll freeze when asked to do a piece of mathematics on paper in their language. Also, most PHP programmers tend to be framework-users. And while using frameworks is good, using frameworks without automating elements of your problem domain (by creating your own little framework-on-a-framework) is generally bad because you end up repeating yourself a lot.
PHP is not a bad language, but it's a very, very bad language to have as your sole programming experience.
I want to respond to my own comment. After reading all of the responses I have to change my mind and agree with the precept of what the writer is saying. Hearing from the perspective of people who do interviews and hiring, they are right. It is a good filter of who is and is not an actual programmer.
It makes me also ask the question, are people who use interpreted languages really programmers? The code I write is conceptually programming, but I don't think in terms of how its compiled, but rather how efficiently its interpreted and ran by the web server.
Perhaps you can tell us the basis for your previous position. It sounds like you don't have experience with interviews or hiring, so what made you think that you knew what you were writing about?
I think there are two potential skills being evaluated here. The first is whether someone can think about and write code without being in front of a computer. The second (and more valuable, IMHO) test is whether they can code without resorting to copying-and-pasting from a tutorial or forum thread.
In more closed source languages like .NET you won't have the copy-paste problem nearly as much. In my time learning C# I found a great lack of freely available online resources with code snippets that worked in all situations as with PHP. Picking up PHP and making a site work was much much easier with the wealth of reference material that was around without costs associated with them. I would suggest that the copy-paste pitfall you mentioned depends largely on the language or platform that is being interviewed for.
Writing code without being in front of a computer is different in that you don't expect your napkin application to run and you won't list include files or even real functions in outlining a potential plan, does this detract from the usefulness of the napkin? No I wouldn't think so as it gives your brain a predetermined map to try and follow when finding the real functions to use or loops to create when solving an outlined problem.
I think it's that the term "programmer" is so loose in the PHP community that good programmers have gone away from PHP. I know that it makes looking for jobs intolerably annoying.
In interviews, you're talking about programming as people who know how to customize WordPress talk about how they can do whatever needs to be done in PHP. Heck, look at WordPress itself - it's a blog engine that takes 10x longer (or more) to render simple pages than it should. And that's the problem. A PHP programmer can simply be someone who knows how to make bad decisions and hack WordPress a little - and the salaries are often reflective of that.
So, while you may pay more, so many of us have just left. Yeah, there are bad design decisions (like having a million functions in the global namespace), but it isn't as big a deal as many make it out to be (since, as a web-only language, it's limited to web functions and they're usually quasi-namespaced as, for ex., mysql_*()).
The fact is that, because PHP programmers can be idiots who know how to guess and check, real programmers have left - the jobs available, money around, codebases to work with, coworkers to work with, etc. all reflect the fact that so many PHP programmers are really guess and check hack artists.
guess and check is a surprisingly good skill to learn and one that many people cannot master without years of doing it. employees with guess and check skills will help in fringe cases of development where one or more of the senior developers does not have any experience, instead of reading docs the tend to take a sledgehammer to the problem and can tend to bang a working version out very quickly in any given environment. guess and check hackers that are truly good will be the fastest to adapt to any changing situation in a faster paced development schedule and you might see them flounder in boredom in larger well outlined projects where they can't find problems to try and fix
this isn't to say that you, mdasen, doesn't find good guess and check hack artists, but just to put a positive spin on what otherwise looks like a negative comment to developers that don't have their language of choice memorized.
Let me provide a counterexample. Recently, I needed to do a rather complicated SQL query (via an ORM, so not as painful as it sounds). Anyway, I didn't know how to solve the problem, so I wrote a test case and tested various versions of the query. I had no idea what I was doing, really, and it took me a day to get the query to work. Then I realized that the test case was wrong (!) and I was back to square one. I read up on some more relational theory, thought about my problem a bit more, and then had the answer in an hour.
To make a long story short, writing code that you don't understand is a bad idea. It may appear to work, but it's probably broken and you just don't have the understanding to know why. If you don't understand code when you write it, what's the chance that you'll ever be able to maintain it?
If I were given a piece of paper and a pencil and expected to start writing out code, that, to me, aside from just being annoying, would raise serious questions about how well that employer was planning on treating me. If they can't even supply a cheap computer for me to write some code, what else won't they provide once I actually have to work there? Yikes.
While we had a lab full of computers in high school comp sci, we did all our main work on paper and on the chalk board, and all tests were on paper too. We had to learn to think things through in our heads. At the end of each year was a 3-month development window where we had to write a complete app (game, whatever) start to finish, so we did do some serious code for our age (this was 8-9 years ago now).
To this day, I bring a notebook everywhere and jot in pseudocode on the bus, in meetings, anywhere I can. I'm certainly able to think through problems better because of that. Programming is a written language, you don't need a computer to speak it, just to interpret it. And pseudocode is a great art to get good at. Highly recommended if you're looking to pick up a new language, just learn to program on paper and in your head instead.
So what they're likely looking at with the paper and pencil test is simply to see whether you can actually think in general, and not just debug your way through an assigned task.
I don't know if anyone else read the article who still actively "has" to develop in php.. but the problem he is asking them to solve with pencil+paper should be totally doable in a few minutes; even for someone fresh to the language as other than maybe the strcmp function you would need no real "library" knowledge.
I think it's clear that there are two kinds of "solid" php developers. The ones that have moved on to other languages/paradigms and love it (thus answering "where have they gone") and those who have moved on but still make their bread and butter in php but apply those new paradigms best as they can (cake php, fluent expressions, correct use of OO etc.). The problem with hiring the latter is they are most likely gainfully employed or more interested in doing their own thing.
Maybe you should try hiring people with aptitude and providing crash course training as well as further education incentives.
PHP gets a lot of bad press (some deserved, some not) -- but you can't fault the language. When PHP was first released, it was a major advancement over PERL and SSI which prevailed at the time. With the growing adoption of PHP5 and the upcoming release of PHP6, PHP should be back on par (or at least close to) many of its 'high-class' peers.
The slow migration to PHP5 by web hosts has definitely been a major bottleneck for the language. It's too bad that the extreme popularity of many PHP4-based apps is what prevented hosts from upgrading, thus giving developers little incentive to upgrade.
The good news is that the popularity of Rails and MVC has inspired a broad selection of excellent MVC frameworks for PHP5 (ZendFramework, KohanaPHP) and with PHP6 on the way and new web hosting architectures on the rise, there may very well be a resurgence in PHP.
Here is the answer: don't look for PHP programmers! Look for good software developer (Web experience will be a bonus), and this guy will easilly handle all these tasks and even more :)
Which brings up the obvious question underlying this whole article: Which kind of talented software developer is easy to find in Cyprus?
Cyprus is only slightly more populous than Vermont, where I'm told it's also very difficult to find development talent, despite the fact that it's a lot closer to a startup hub.
To talk about the issue of an interviewee not being able to write out code with pencil and paper: Do you paint with crayons?
If you are an amazing digital artist in Photoshop, say Burt Monroy for example, then you should be able to paint with crayons right? If you work for Lucasfilms as a top-tier 3D artist who works in Maya, shouldn't you be able to chip Michelangelo out of stone then?
What most NON-CODERS, which I am assuming includes you, do not realize is that a programmer's brain is wired to work in a certain environment. We have learned for years how to code in particular ways, whether via a straight text editor(Textpad for me!) or an integrated IDE(Eclipse or Visual Studio for example).
So you take someone who's already stressing about making a good impression during an interview and then ask them to write down code on a piece of paper. That's the absolute worst thing you can do. You're asking the person to use a different part of their brain to tackle a problem that hasn't been trained for that job.
Put the person in front of a computer, such as a laptop in the interview room put there for specifically this purpose, and THEN give them a problem to solve.
If the person still can't pull code out of their ass at this point, then you're right. They're morons. Otherwise, you will be surprised at what some of these people can do that you've looked over.