Measuring LAMP Competency? 453
An anonymous reader writes "Our company is getting ready to hire a number of programmers. While the majority of the prospective candidates do have good-looking resumes, we are looking to see if we can get some clear metrics in the assessment process. After a little research we have learned that there is a well-established PHP + MySQL training and certification process, and some of the candidates are already certified. There is also a candidate with a good portfolio, a lot of experience, and no certification. Most of the applicants also have some college/university science-related education. So our goal is to be able to somehow measure LAMP overall competency as well as basic computer science concepts such as BNF, data normalization, OOP, MVC, etc. How do Slashdot readers go about this kind of characterization?"
Forget certification, look at some projects (Score:3, Interesting)
Since you're looking to recruit a number of people, I'd say that their ability to work together - personalities, maturity, compatibility are at least as important as skills and experience. So don't just pick the top X according to how they rank at interview, consider if you think they can work together as a team.
Technical Interviews (Score:3, Interesting)
After you've established a baseline technical competency, ask them to solve a few simple programming problems to measure their problem solving ability. Doing them in PHP or Perl is obviously a bonus since you're dealing with LAMP, but pseudocode should be fine in a live interview type of situation. Don't judge things like missed semicolons too harshly, they're probably nervous. Concoct some basic scenarios dealing with the L or A part of the LAMP stack to judge their troubleshooting ability. Ask them for some SQL statements to pull certain data from a hypothetical database for the M part.
Interspersed throughout should be questions that judge how well they'll fit into your company culture and how easily they can learn new things or deal with new and unexpected situations. For these, concentrate on asking about past experiences of that type rather than asking canned hypotheticals that everyone has already seen on the Internet and knows how to answer.
A person's technical competence is not a reliable predictor of success. It's part of the equation, but his or her ability to learn and grow with the company, as well as the ability to fit in with your company culture, is much more important unless you're just looking for temporary contract labor.
Also, don't be afraid to ask your friendly neighborhood PHB. If he's taken any sort of business classes at all, and didn't spend the entire time Facebooking instead of paying attention, he should have plenty of insight on effective hiring.
Re:Portfolio. Previous work. certificates mean zit (Score:2, Interesting)
How do I show my enterprise app that runs on Solaris and Oracle to another company? If it isn't a webapp, how do you truly show a portfolio?
Look for Good Architects (Score:1, Interesting)
Bring them in and put them in front of a whiteboard. Discuss the project you need done and ask how they would approach it. They should be able to explain it and diagram it. This alone will show how far their compentencies go in each part of the lamp stack as well as OO and other key concepts.
Are you qualified? (Score:2, Interesting)
If you have to ask how to interview software engineers for competency, maybe you are not qualified to be interviewing software engineers.
Good experience is far more important than any certification. Wanna see if they can design and build software? Give them a problem that requires they outline a design and then have them code up specific pieces like DB table schema, table queries, classes, templates etc.
Give them a bug, 4 levels deep. (Score:2, Interesting)
Re:No faith (Score:5, Interesting)
That's a pretty bold assertion. I assert that it is not true.
Although... most certifications are entry level. They only say that you've read the material, have done some practice and have a basic understanding of the theory. They *try* to test for experience, but the Cisco, Microsoft and Linux certs can be passed without experience. I've written others, but I've seen few certs which contradict this.
Intermediate industry certifications mimic designations. They require nomination/sponsorship and years of experience, also point systems to maintain certification. They're much harder to fake.
All of these certifications make a reasonable minimum requirement. That's all. Most people I've met who are anti-cert seem to be resentful that they'd have to study material to acquire product knowledge in an area they've never seen, nor expect to see. Those people of course are missing knowledge. Maybe it's relevant to their jobs, maybe it's not. They'll never know, and they might spend weeks trying to figure out some problem because they don't know the capabilities of the software/tool/product.
Now I have to get back to work fixing some device which was deployed by some self-taught boob who didn't adhere to best practices for the device... probably because they used the default configuration without knowing what the defaults were. They of course moved on, and are probably telling people that certifications don't matter...
Re:Previous work (Score:3, Interesting)
As I've found, there's always some degree of yelling in high dollar production environments, especially where a few minutes of outage can be the difference between a highly profitable day, or a huge loss. Hell, people freak out when a Windows file share stops working, or Outlook eats their mail. I've never seen a warm fuzzy workplace that involved a production environment and/or deadlines, that didn't have the occasional loud emotional moments.
When I've interviewed, the yelling is only a small part, during the roleplay part. The rest of it was a fun conversation with plenty of joking around. If they can't laugh at my jokes, they won't be very entertaining to work with. :)
The last place I worked at, it was unfortunately an every day occurrence. It was always something, which sometimes included outages at tier 1 providers that we were not directly connected to.
"Oh my god, this guy in [insert random city] called saying he can't reach us! Fix it now!"
[traceroute to see where the problem may be]
"There's an outage on [insert another provider]. We'll have to wait for them to fix it."
"No, call them now! Get it fixed!"
"We're not their customer, I can't call them. They'd just hang up on me."
"Do it anyways, I don't care, get it fixed!"
[calls 3rd party provider, and gets hung up on]
"They hung up on me."
"Call [some sales minion] at [our provider]! He'll get it fixed."
[calls sales minion, gets told he can't do anything]
You see where this goes. About 30 minutes of people running around like idiots, and suddenly like a freakin' miracle the 3rd party provider fixes their problem and the world is saved yet again. Of course, they always want a written report explaining in detail why the outage occurred, and how could we avoid it in the future, and of course the report would need to be read in a lengthy meeting. Multihoming and putting our own network on a better provider with better peering agreements were always shot down, so this whole thing was repeated every few weeks. I liked the options of not answering the phone any more, and investigating the problems after they were already resolved. It made life a lot simpler. :)
Re:No faith (Score:4, Interesting)
Although... most certifications are entry level. They only say that you've read the material, have done some practice and have a basic understanding of the theory. They *try* to test for experience, but the Cisco, Microsoft and Linux certs can be passed without experience. I've written others, but I've seen few certs which contradict this.
Woah, there, buddy.
Yes, there are entry level certificates for a lot of things:
A+ - anyone who puts this on a resume who is going for anything other than a repairman is stretching.
MCP (Microsoft Certified Professional) - you have passed any one MS test
PMP - congrats you're a PHB-prototype.
etc.
But, there's a LOT of pooh-poohing of certs around here, and some of it isn't warranted.
For example: People who have a CCNP have passed four different cisco tests, including a troubleshooting one. That could be crammed for probably, as it's strictly a multiple choice test, but most people who have a CCNP probably have at least a decent familiarity with Cisco equipment.
People who have an MCSE have passed 7 Microsoft tests. Yes, you can cram for this and learn in books / etc, but - it's still more difficult than people think. How many people do you actually know that have gone as far as really getting their MCSE? There's a lot, but not as many as who think that it's just a piece of paper and stupid test. There's some higher level domain configuration and troubleshooting, etc.
And the RHCE (which I recently got) is a literal hands-on test - they hand you a broken linux box which you have to fix, and then a list of things to make it do via whatever method you think best (i.e. sendmail or postifx, as long as it delivers mail etc).
Certifications are not the end-all be-all of knowledge measurement. But, they're not completely worthless either. I see people on slashdot all the time who are like "I don't trust someone with a certification", or "I trust someone with an RHCE less than I trust someone without one!". That just doesn't make any sense.
~X
When I started here... (Score:3, Interesting)
The company I'm at now had an interesting review process: I sat in a cubicle with the two lead developers. One asked me matter-of-fact questions: what would you do in x situation? What is your proficiency with the Linux command-line? How long have you used PHP and how have you used it? Have you ever configured a server? The other programmer, however, had some more interesting questions - bringing up ridiculous scenarios that had simple answers, yet the question itself was laden with red herrings to make you really think about it.
After this interview process, it came time to do a couple quick programming tests: fizz/buzz is a standard here, just to make sure you're sane. There is also a simple "Build an HTML form that submits here, do x y and z with the returned data." Simple tests are usually the best, as we have a sort of wall of shame for people who did not have any clue what they were doing. Example: One person asked if they could install Dreamweaver so he could do the Fizz Buzz. Another wrote in the comments to his HTML form test: "
<!--another API i dont know. Lets see if this gets the job done --!>
<form action="testMe">
<form textfield = "username">
</form>
These are the people you don't want to hire. I understand you're looking for something perhaps more rigorous, but a set of simple, common sense tests is a great starting point. Have them grep a file for a pattern - did they use and/or understand regular expressions? Did they use them when they didn't need to? How about making an .htaccess file that does some basic functionality. Have them create a table with an auto_increment'ing ID and write a form/PHP page to store information in it (and see if they know about basic data sanitizing). And of course, Fizz Buzz!
Weed out the incompetents/overachievers and then take a few for a test run - make sure they understand and conform to your coding standards, make sure they have the ability to learn and understand your processes (how your MVC works, a general understanding or willingness to learn your DB structure, etc).
Re:No faith (Score:3, Interesting)
Sorry, RHCE, MCSE and CCNP are entry level. They're NOT easy, but if you don't have any work experience to back them up, then they dont' mean that you know very much about the technology.
I did the MCSE years ago, I'm working on the CCNP, and I work in intermediate roles. I don't do the certs because I'm looking for a job, I'm doing them to broaden my knowledge.
I've dealt with lots of clueless RHCEs (seriously) and heaps and heaps of clueless MCSEs. Without exception, they lacked experience. The CCNP is harder to find twits, but personally I think it's because it's virutally impossible to get a CCNP without access to $250k worth of hardware... which means you've probably got the experience.
The CCNP twits I've dealt with took courses paid for by their employers.
I agree completely that it's tiring to hear people say oh, a "RHCE, I wouldn't hire them". The RHCE is a damned hard cert and probably means that you know what you're talking about. But... it'll only prove a minimum level of knowledge. I'd look immediately at the experience after that. If you came out of some career training school and got your RHCE with no sysadmin experience (hard to believe, but these people are out there), I'd only consider you for the simplest of roles.
Congratulations on the RHCE. I'd only take the cert if my employer would pay for it. And although I have over 12 years experience with Linux, I'd expect it to be a gruelling cert to earn. Sadly, you have yet to meet the guys who have it and dont' know a make script from a kernel module.
Re:Ignore the certificates (Score:3, Interesting)
MVP stands for Model-View-Presenter. What differentiates a Presenter from a Controller is that a Controller creates an appropriate model (or models) and a view of some kind, connects those together and tells them what to do. It might also do ACL checking and the likes before. Then, the view fetches data from the model(s) and displays it (for a very liberal value of "display", as might be the case with, say, an RSS feed generator). That's right: the view is an active element of the system, usually implemented as an object using some kind of a base class just like the controller and it can access the model. Of course, the model should be strictly read-only for the view - all things good and sane are lost for the application when some moron calls a method of a model that modifies data from inside the view. A good framework might employ safeguards against this, but a good design comes first to protect against such idiocy. One could argue that the view just becomes a second controller with a different set of responsibilities, and it's actually an interesting and somewhat reasonalbe point of view, but that's just what MVC really is.
The Presenter, on the other hand, does not relay the model(s) to the view and tell it what to display. Instead, it fetches *all* the data itself and spoon-feeds it to the view, which is usually a purely passive construct. As a side effect of this, the Presenter is usually involved in some presentation-related data postprocessing such as pagination and sorting, that a Controller should never do. Hence the name. On the other hand, this allows for a "dumb" view, such as those used by CakePHP - it's just a bunch of HTML files with embedded PHP snippets that display the data. Much less flexible than MVC, but also much simpler to implement and use.
Of course, neither is better than the other. They're just two somewhat different variations of the same idea, each with their own advantages and disadvantages. The only problem is that uninformed people call MVP "MVC", which is plain and simple wrong and indicates some degree of ignorance of the subject, which is never a good sign.
Personally, I'm using a hybrid solution that will invoke an MVC-style, class-based view when it exists and fall back to MVP-style spoon-fed templates otherwise.
Re:Previous work (Score:3, Interesting)
I've interviewed with them 3 times on the phone (three interviews each). Some of their questions just plain don't make sense. From what other folks have said, it's just to see how you handle stressful situations.
Like this question...
G: "How does telnet work?"
Me: "Can you please clarify the question?"
G: "How does telnet work?"
Me: "Well, it is an application which opens a TCP connection to a server, normally on port 23, but can connect to anyTCP port where you are expecting ASCII data".
G: "Tell me more. How does telnet work?"
This went on for about 10 minutes, where I finally had to give in and say "I must not understand what you're looking for, so I don't have a better answer for you."
During another interview, the interviewer started asking Python questions. I told him that I don't know Python. I'd never touched Python. Python is not listed anywhere on my resume. He spent about 15 minutes on Python questions. During another interview set, where the interviewer was very pleasant and did ask me questions in my skill set, what the Python questions were all about. He said that there was a little holy war over there. Half the company wanted to use Perl. The other half wanted to use Python. It was a constant conflict. As with most holy wars, lots of people have their preference, but don't make a big deal about it. Others will make a huge deal over it just for the sake of doing it. That interviewer probably had a hard on for Python, and didn't want any non-python people on the team.
In all 3 sets of interviews, I was always interviewing for sysadmin positions, so I thought it was very odd to get in depth questions regarding programming, except for maybe some basic shell scripting. I've known sysadmins who couldn't write the first line of code, but I prefer the ones who can at least modify easy shell scripts. :)
You got the trip to their office though? Congrats. I'm hoping to get that invitation sometime soon.