As a non technical IT Recruiter I find this suggestion VERY useful as a generic (basic) qualifier of applicants.
The logic is there and makes sense.
Thanks VERY much for the tip - brilliant!

Great points… I see this so much. Hiring good talent is so important to the success of a product/company and separating the wheat from the chaff is getting harder and harder. Similar to this recommendation I also practice the following; Ask the applicant to think of two projects or products or deployments – whatever fits the category, one good, which they considered was successful and one bad, which they would consider a failure. Then have them describe why was there success/failure in each case. I found that this really separates those who think things through, who choose to build an awareness of the overall context of the projects they work on from those who only care about writing some code and are completely oblivious to the other dynamics affecting a project.

One other option to ensure good hires is to always have an opening posted on your website weather you are actually hiring or not. Good technologists come when they are available not when you need them. So in this manner at list I get a heads up – hopefully – when they are available.

Hi Ester!

IT managers rarely know what to ask when a programmer is led into their office during a job interview.

As a (previous and future) Director of IT, I've had my share of experience in hiring developers. In most cases, I have hired developers that I understand and while I could easily quiz them on their knowledge, I almost never do. Back in '99 I actually wrote up my thoughts on this in the article Nerd Herding. A non-technical manager should not try and evaluate a developer. It's the height of arrogance to think that there is a magic question that they can ask a developer to "separate the true subject matter experts from the tyros". The very premise of your post is that the manager is not knowledgeable, in your scenario, how can they be expected differentiate a good answer form a bad one?

If a non-technical manager is required to hire a developer, my advice is to call in another developer, or as I propose, several developers, and let them evaluate the potential hire. IMHO (and for the record this comment IS an opinion piece) this is a much more successful way to hire qualified developers. (The side benefit is that watching your existing developer staff interact with the new hire will give you an idea of whether the person will fit in personality-wise...and how they fit in is 50% of the hiring decision.)

One final word on the PHP article, as I've stated before, you can say that it was an opinion piece, but it was not presented as such. It was presented as a factual article from a subject matter expert. The response from the community, especially since several leading members of the PHP community (not me…I’m just a reporter, others) took the time to respond, should tell you that maybe you got it wrong there and should reconsider it.

Oh and just so you know, my bulleted list of when I would not use PHP is this:
* Real-time server processes
* Anything that requires persistent state.
* Long running server processes
* Desktop applications (Yes, it can actually be done but I would never do it)
* Windows server processes (and I’ll get hate mail for that but this is MY list)
* Graphical applications (since these are usually desktop applications, that would cover it but I felt it necessary to list it separately)

Notice the absence of words like "scalable" and "security"?

Thanks again for posting on my blog,

=C=

As a developer who enjoys programming in Ruby, PHP, C, Javascript, Java, Perl, and Erlang what I'd love to see is a response to that PHP article you're referring to where all the factual lies (as disproven again, and again, and again by those "Low-level people" you keep ignoring) are finally revealed as truth. I'm sure Google will cooperate if you dig deep enough into anything written pre-1999 when at least some of it was then true.

The truth is that the article was never going to be responded to the way you're seeking because the article was a piece of factual abuse. The comments posted were an often emotional reaction to what the PHP community realised was a horrific attack on PHP which lacked any semblance of fact, truth or reality. One cannot debate lies when the liar insists they are truth. The only part anyone agreed with - which seems oddly to be only part you're plying as an excuse that the commentors don't agree with - is that PHP is not a good fit for every, or even most, programming tasks. Let's look at how many languages I have learned and use before you turn that one on me. I'm not even a rarity in PHP.

This sudden burst of advice just pronounces this magazine's continued blindness to how atrocious the referenced PHP article is. It is a laughable litany of factual errors, lies, outdated failings, and poorly conceived advice with precisely zero basis in reality. Your response to these failings has been frankly disgraceful. No amount of comments, additional insulting articles dressed up in a professional advice packaging, or attacks on the responses the article has garnered will change that.

The article speaks so much for itself, that I invite any programmer of any level to go read it right now. I'm dead serious. If you believe PHP is total crap - still go read it. If you don't like PHP, you'll probably find it hilarious - until they reach your preferred web app alternative language. There is a tipping point where intelligently delivered criticism of a language drops off the cliff into a steaming pile of babbling garbage, and this is one of the finest examples I've ever seen. It's tripe.

Why don't you, as editor, respond to the comments pointing out the flaws instead of this transparent attempt to redirect attention to the one facet of the article nobody has been disagreeing with - especially since anyone can see your ridiculous ploy if they can read. I might then have some modicum of respect for your editorial prowess.

As for a clear cut response to the PHP article in question. One of PHP's most enlightened community members has delivered a comprehensive retort for your viewing pleasure:
You Use PHP to Troll WHOM?! You Used PHP to Troll WHOM?! (PHP and Enterprise Scalability Part 1/5)

Respond to that if you can. It's so comprehensive, it had to be broken into 5 parts to cover all the facets.

I am sure most of the experts like me reviewed all three articles, and printed to PDF for later use. These scripting languages like Java serve their purpose and the articles are well articulated. But good old fashion C, C++, and low level Assembly for firmware can not be replaced.

There are far more techoweenies out there that can write script, and far fewer can debug the mess created by them. For that application the word “Wrappers” comes to mind.

Yes it is faster, but unfortunately it is easy to hack, creates security issues, and the boss saves money because he or she can get a scripter at cheap, cheap , cheap..... It come down to this "you pay for what you get", if you want "disposable" code so be it, place it in file 13 and “forgetta bout it”

Cheers,

George Ingram, "Old School", wasting my words again to Idiots