Slashdot Mirror
Measuring LAMP Competency?
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?"
Look at things they have done! Not just the outside, check the code, look at the database structures etc.
The answer seems simple. Ask for guest access to a server that they configured. If they don't have something like that you could set up a simple lamp server and have them perform some basic tasks.
Get them to write a trivial app.
If it contains 'INSERT INTO table ('. $foo. ');'
Kill them.
If they can't talk intelligently about what they say they've done... next!
Free as in "the Truth shall set you..."
Personally I have no faith in certifications at all. I know tons of people who are certified out the yazoo and can't do a darn thing. I also knows tons of people with no certifications especially in open source where lots of us were working long before there were certifications, that figure things out on their own and dig for information. The people that are driven to dig are the ones that rock the house. Needing a course to learn is some what of an automatic fail to me. You will learn far more about which type of person they are in the interview than you will from a certification.
How to interview someone is seriously a topic on Slashdot? Must be a pretty slow day waiting for that Apple announcement.. Anyway I do the technical interviews at my large company (Fortune 500)all the time (not programming, so this will be just general advice). If you have someone that actually understands the topics ask the questions then it's easy to gauge someones knowledge. Hiring someone that knows what it is going on is important, but in my experience finding someone that has the right personalility is more so. Have your technical person narrow it down to like 3-4 potential canidates then have the hiring manager pick from those, remember that someone willing to do assigned tasks without arguement might be worth more than someone with a bit more experience but runs to HR 4x a week about minor things.
While I understand your position, hiring good programmers takes more than just knowledge of their medium. Hire the top 3 as temporary employees to see how they fit with your company then after a few months let 2 of them go and keep the best. A good work ethic and honesty can only be measured by experience with the employee and not from a resume. To gauge their knowledge of the medium, show them what you're working on and see what kinds of questions they ask about it, that's a great way to gauge their experience.
Why BNF?
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Generally I would have an interview with the applicants that seemed most qualified. It's the easiest way to see if someone is padding their resume or generally bullshitting. When the vacant look comes into their eyes as they spew forth buzzwords in answer to your technical questions, you know you've got a loser. If you can't separate the liars from the nerds in an interview, you have a real problem.
Also: do you need this person long-term? If not, I'd advise a contract with the person that uses more Agile methodologies, thus requiring more feedback from the developer, and less time between releases so you can see work being done. If the work starts to suck, at most you're out four weeks work, and you have everything from previous releases to give to a different developer. If you think you might want them long-term, perhaps a 6-12 month contract period as probation might be a good way to safely evaluate their work before committing to an expensive, long-term employment relationship.
Overall, I'd not worry so much about specific technologies. Zero exposure to LAMP would be bad, but a younger person who's willing to learn is cheaper and has something to prove. Just make sure your production environment is well-shielded from mistakes, and try to enforce some discipline on a younger developer. A more experienced developer will be well aware of the dev/test/prod environment, and generally make less mistakes, so the turn-around time will be less. However, experienced developers typically favor one technology over another based on their experience, so it might be harder to teach them new tricks, so to speak.
"Please describe the scientific nature of the 'whammy'" - Agent Scully
there is no higher proof of competency and ability than proof of prior work. certificates are like school courses. everybody can take one if one attends the courses, or passes an exam. practicing in the field however, is an entirely different matter.
portfolio shows that you not only know your field, but also you have properly and responsibly participated in projects, collaborated, and actually built stuff with it, and saw them to their completion.
that is the kind of people you want to hire. and nothing than a portfolio shows it better.
Read radical news here
You need to actually be testing their ability to write software. As a few others have pointed out, having them develop a simple web application as part of the interview process is probably going to be the best way to measure that ability.
Additionally, to test their integration skills, you could also have them attempt to develop a new page to be integrated into your company's product. Not only will this show off their software development skills, but will also give you some insight into their ability to inherit an existing software project and work with it (something that he vast majority of newly-hired developers will have to do).
when we went to the moon?
certification is a gigantic scam, so that PHBs can 'outsource' yet another job function while they collect huge paychecks for 'synergizing the optimal opportunity risk costs analysis paradigm and reduce opportunity costs while conforming with best practices metrics'. (ie, commit massive fraud, milk their good old boy network, and buy a golden parachute)
hooray for capitalism.
I take real production class skills or certifications any day. Know how to do something is one thing, actually making it work in the real world is another. I would be interested in what they have done and verify the work with the previous employers.
I was you, i would NEVER hire anyone with a certificate, NEVER. Obtaining a certificate is simply lost money, and lost time. Not mentioning the fact that every monkey with well designed short memory could remember a 2000 pages MS Server certificate Q&A, and become what? Monkey with MS Server certificate? And i am not joking, i really know such a people, who does not ever have a math degree, but who have a lot of "certificates".... Anyway, good look, you will need one.
First you define what you want:
Do you want technical certs? Then look for people with those.
Do you want people with academic background (data normalization, OOP, etc)? Then look for people with CS degree.
Do you want people with experience? Then look for people with relevant experience, and or do a practical test as suggested (which everyone can get their smart friend to do for them I'm sure)
Weight each one of the factors according to what he or she is supposed to be doing.
Systems analyst? Architecture design? Jr. code monkey? Overall hacker (jack of all trades, master of none)?
Then rank them in each factor. Most of those factores are qualitative more than quantitative by the way.
But sometimes, the best programmers are not the ones with the best qualifications, but the ones with the best fit into your business. 8 years php experience vs 4 years php experience IN YOUR INDUSTRY: I'll pick the 4 year experience guy.
please excuse my apathy
If they have the right buzzwords on their resume, bring them in and ask them technical questions relevant to your environment. Then, throw in a few questions related to other technologies on their resume that aren't directly relevant to your environment just to see if they're the type of person who likes to puff up their resume by listing stuff they don't really know. You have to have at least a passing knowledge of the stuff you ask about, of course.
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.
That's what probation periods are for.
If you try to quantify it, you'll end up hiring people who are good at gaming your system. That's a skillset, I suppose, but probably not the one you're looking for.
I'd say to either hire a consultant (consulting firm) or possibly look at Brainbench.com for certification & placement examinations. (Any testing is to be done on-site, in an allotted time-frame...) There may even be a service (such as Kelly services that would administer the testing, etc, for you). I'm in agreement with jvillain about the certifications, though. Just because someone is certified doesn't mean they're any good.
Look at the guys with an experience-based resume, not a certification/education-based resume. Some certs are good, but most good techs & programmers did something other than take a lame course, etc, in Visual Basic or "Web" programming. The best coders learned it because they had to.
I'd, personally, rather hire someone with no college/technical training that's been doing the work for the past 5-10 years, because he/she did it the hard way. That person learned it better, more thoroughly, and more completely. The benefit is they are more than likely still able to learn and work harder for you and your mission statement (I've seen this in quite a few cases).
Regardless, good luck!
--Stak
Holy happy hippy crap!
OOP techniques and security. The biggest benefit of LAMP is it's flexibility. You can literally weave 3 languages together in one page. That is also it's biggest downfall if people don't know how to structure a large application and use proper security techniques to prevent SQL injections and XXS attacks.
Define a small coding project, deliverables and all, and bring in each candidate to complete it as a pre-interview. Then call back those that did the best job.
Problem solved?
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Skip the alphabet soup. Do you really have no one on staff capable of recognizing competence?
If you don't, who were you planning to have manage the new hires? Who were you planning to have interpret your metrics?
As always, all IMO. Insert "I think" everywhere grammatically possible.
All right, candidate, here is a room with an internet connection, a MacBook, and, uh, a pitcher of water over there. In a couple of hours we'll be sending about 1000 connections per second your way so, uh, why don't you set up a secure registration form for a paywalled media site, really however you want, the content itself is just a dummy, what we want to see is how you keep track of the registration and authentication. Don't use any third-party solutions, do the actual coding. We'll look at security and performance. Good luck.
seriously, just do it this way and you won't be sorry.
I have twenty years experience developing client-server applications and a bachelor's degree, yet every position I apply for I am either
So, definitely ignore higher education and experience. Everyone else does!
It's the only way
1 - ok they know PHP?! Ask them to write a simple function (whiteboard will do it), but you also can ask the to do 'homework' or set up a dev env. in a laptop
2 - same for MySQL, do they know how to write a select, do they know how to use PhpMyAdmin at least?
If they refuse to do it then go for difficult questions. If they won't answer, just send them home
how long until
Our devs find that the best ways to test skills is to have people sit down with them and work on whatever problem they're currently facing. It allows us to see adaptability, thought processes, keenness and experience.
that you know demonstrates the ability to use the tools you have. It should be able to pull data from a DB, display it and accept data from the user and post it to the DB. Look for error handling and comments. What kind of naming conventions did he use. How crappy was his OOPs?
And, I would add a problem that could not be easily overcome. Maybe the DB UserID does not have update, just insert. How does he deal with adversity?
Finally, does he ask good quwestions and does he stick to the problem at hand?
Does he mind being referred to as a he when he is a she?
If they have any competency, you should easily discover it by having them set one up. Download Virtualbox and set up a few images (Ubuntu, Red Hat, FreeBSD, should only take a few hours while doing other things) and have them set one up. Apt, yum, port; you've basically got them covered, save for Solaris.
Now, if you don't know how it's actually done and you're trying to hire without having the competency yourself, then you've either got to get someone who has the competency to interview, or just guess like everybody else. I wish we all had a silver bullet for this stuff, but certifications in particular are not it, not when the companies providing them are paid to provide them.
Give em a GRE practice test.
How many more years will slashdot have an off-by-one error on your Score in your profile?
First off, throw all the resumes with certifications in the circular file. Seriously: that's the first sign they don't know what they're doing.
After that, you're back to the main problem of interviewing technical candidates. To do this successfully, you need at least one good technical person to participate in the interview. That person should be able to ask questions about experience and pose scenarios that probe the candidate's depth of knowledge. The interviewer also needs to be nimble enough to move between topics to gauge overall competency - the candidate may be weak in one area, but overall strong. If the interviewer only focuses on the weak area, you'll risk losing a good candidate.
For specific skills, it's also good to have a few technical questions with definite right answers. I prefer showing code and having them find bugs or telling me what the output is. I keep the code simple enough that a good person can spot the problem in a few minutes, but tricky enough that they may get it wrong with the first guess. That helps to see how they work through tougher problems. Language agnostic problems are best - e.g., problems that focus on control flow constructs common to most languages work well.
Anyway, good luck interviewing. It's tough to sort through all the noise, but there are good people out there.
-Chris
You should ask questions until you're confident that the person has answered their self-ranking accurately, but if you have to ask about more than 5 skills, you probably don't trust the person and you should end the interview.
I should add that technical skills are quickly obsolete, so unless you're hiring contractors, which you're apparently not, you shouldn't use skill in specific technologies as the primary criterion for hiring decisions. Ability to learn, people skills, and work ethic are much more important and harder to teach. Of course, if they have few technical skills, then their ability to learn may be low, so they're not exactly independent criteria.
I think you're looking in the wrong direction here. You've seen the resumes -- you know who is qualified. Maybe bring up a couple of technical questions to verify their qualificaitons. But the way my company interviews, you're not worried about that. You want to find the best worker. Our interviews are almost 100% "what would you do" or "how did you handle x." In my experience, it makes dealing with the people who do end up getting hired a whole lot easier.
Whale
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.
Play buzzword bingo with the CV:
ie, find the 'resume term-of-the-week' and ask them about it: if the candidate can speak about it intelligibly, they know something about it, and increase the difficulty.
in the past, the big buzzword was Java. Now it tends to be Python.
I sit on the interview committee for my group. I look over all resumes of candidates I interview before they step into my office, so I know what's written and what they 'claim to' know. I'll ask questions, and if the candidate has something on there that cannot be explained or defended, that candidate just failed. I don't like people who add crap to resumes for no reason.
as far as the lamp testing goes:
Linux:
- installation [non-package] of the configure, make variety
- configuration files, where they sit, how to edit
- differences between etcpasswd and etcshadow, and why hashes only [not passwords] are stored and what salts are
- chroot jails
Apache:
- modules. explain
- apache conf
- virtual servers
MySQL:
- how to design a database [ie, here's a DB task. how would you solve/implement?]
- how do you [personally] send SQL commands to the server? the mysql command window, perl, php, python, etc. what hooks are you familiar with?
- pivot tables, one to many, many to one, foreign keys
Perl/Python/PHP: [preface: I am not a big user of Python]
- how would you implement [x data type] in Perl?
- External Perl Libraries -- how not to reinvent the wheel
- Why to use PHP? Why fully dynamic pages are not good in a high-traffic environment? Ways to have 'dynamic' pages generated while keeping the actual pages 'static'
- What resources do you consult? And how?
OOP/MVC:
- I ask implementation questions, and get the candidate talking. Someone proficient in OOP/MVC should be able to talk about the concepts easily without much prodding. Why, how, best practices, etc.
Speaking as somebody who just got a bunch of certifications in several areas to fill up the time during unemployment; certifications don't mean shit. Yes, they can get you hired more quickly, but they are no measurement of competence.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Are you asking how to quantify someone's LAMP experience or are you asking how to interview someone for a programming position? Seems like the latter to me.
it's a sig, wtf?
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.
If you get to the blame allocation phase of your project, and I really hope you don't, then that's when certificates come into their own.
You can come up with the most perfect slashdot-based system of determining LAMP competency, but when push comes to shove, what a manager wants to see is commercial certificates.
I know and you know that they don't mean shit, anyone can pass them. But they're official bits of paper which means they're *quantifiable* and *indisputable* which makes them gold.
So the question you should be asking is not 'how do I tell if they're competent'...but 'do I value competence when I could be fired if they fail the project?'
No-one got fired for buying IBM...plus ca change.
Business/App ideas are like arseholes: everyone's got one, they're mostly shit, but very rarely they contain a diamond
I usually like to ask questions like:
How do you start/stop web server?
Where are the standard debug logs for web server, php/perl?
What's the difference between threads and processes?
If the average http connection lasts 1s, what is the maximum number of connections you can serve over 1 hour with a pool of 50 sockets?
Then I have them write a short piece of code in whatever common language they like for sorting.
Then I give them a basic mathematical equation and have them write the code to implement it.
Next I ask some common skill questions, such as what to check when there are no incoming users, debug common trace dumps/stack dumps, how to optimize SQL queries, and how would they mitigate/protect against hackers and other similar security questions.
Lastly I ask about how they feel about build it vs COTS, OSS software, bug fix management, tools they like to use, their favorite/worst projects and then have some open questions.
In other words, ask questions about the job they will do, get to know how they interact a bit, how deep are their skills, and what their hobbies are. If you've got the time, try doing a code review with them... mostly I'm looking at a basic skill comprehension, the ability to interact well with overs, the ability to defend a position or compromise, and how well the existing team feels.
I said no... but I missed and it came out yes.
When UML first came out, it was this HUGE thing with many IT managers. They wanted it in a candidate and they wanted 2+ years experience. As anyone who started out in OOP with designing and implementing without UML, we basically thought in the OOP language of our choice and designed and implemented from there: UML seemed redundant and overly complex - it was easier to design it in C++ or Java and then translate it to UML for the people who gave a shit about it and the designs came out better that way.
My point is that many folks may have years and year of experience and be very good at what they do but are not very familiar with "MVC" or any other models or acronyms or buzzwords that were created (usually by academics after the fact) BUT, they know the concepts intuitively. For example, when C++ first hit the market, we C programmers looked at it and thought, "OK, putting code into a structure with the data. I can see how that can tighten up development but it won't make anything better."
You want to weed people out? Do this. Grab the candidates that you like and then sit them down and ask them how they would implement something.
Anyone can memorize buzzwords and parrot them and sound like they know what they're doing.
RIP America
July 4, 1776 - September 11, 2001
Give them a test box and ask them to install Linux/BSD from ground up.
Ask them to install LAMP and configure the most efficient way as possible.
Make sure they work *very* hard like this guy if the job involves round the clock work.
The desire to abstract metrics from what will ultimately be a person working for you is self-defeating. You will find out more about their capabilities and understanding through a 5 minute conversation than you will from hours of creating and applying metrics. Remember, you are looking to hire a person to be a programmer, not a programmer weighted down by watery flesh.
PHP/MySQL web programming is a low-end job. So you want second-rate people who aren't totally incompetent. That stuff isn't rocket science.
You may be better off finding some people who will fit in well with your organization and have some interest in the business, and have done a little web development. They can learn PHP/MySQL in a month or two. They're likely to come up with something that makes business sense.
and let chips fall where they may.....
I know, commenters are supposed to answer the questions not pose new ones, but I am curious about what LAMP certifications you identified as established and well recognized?
I have been considering shifting gears lately and I know I can code and I focus on secure and error-free coding. But being able to prove I know what I know is pretty important in cases. I don't want to be someone's employee if I can avoid it and there are loads of opportunities in small to medium businesses who are looking to have their applications written in ways that are cost effective and stable. (seriously, sometimes Linux servers are too damned reliable. I have two deployments at different client sites that I haven't had anything to do with in like two+ years and they are still running strong without my help. I would love for them to run updates and such, but as these are internal servers not exposed to the internet it's not quite so critical anyway. A former employer's site is still running my servers unmodified/updated for about as long as well... oh well! It works well enough that they didn't need me any longer.)
Anyway, certs might be good to have. So which are the best to get?
Prior to employment you can only measure Potential. Actual competency can only be measured when they actually perform their jobs. Keep the good ones, cut the bad ones loose.
Hope is the currency of fools
Ask them to speak about some site they have done, and they are proud of.
See if they are able to a) Tell specifics about the implementation and b) Communicate them adequately.
I've hired a couple programmers in the past and there is always one question I ask that I have found sorts out some of the better candidates. The question - "I've just requested you to do some task and you find you really haven't worked out that type of task in the past and aren't fully sure the best approach. What do you do?" The answer I'm looking for is basically they'll let me know that's a new area for them, but that they'll go out and find examples of that type of task and research it and find out how to make it happen. If they say anything along the lines of having me help them, or ask to go to a class, or anything along that line it will automatically set up red flags. And of course, just answering the question "correctly" doesn't automatically mean they are good at doing that, but you can dig deeper into how they'd research it, etc. I've been a programmer for over 25 years now and while there are certain core things that a computer can do and some it can't, the actual processing of it is what matters and it's nearly impossible for you to remember every little detail of every language and system, the real power is in knowing where to look to quickly get your answer. And as a final important talent, a person needs to be good at understanding and conversing specifications from someone that is not technical. Just my thoughts on what I've looked for....
as well as basic computer science concepts such as BNF, data normalization, OOP, MVC, etc.
Put 10 seasoned programmers in a room and, without access to references or preparation, ask them to write the BNF for some subset of a well-known language, normalise a database in stages up to 5th normal form, give a detailed description of OOP implementation in any language (not just "how is inheritance formed?" but "demonstrate polymorphic behaviour - suggest how it might have been implemented - describe its disadvantages" etc.) and ask them to fit some app description into MVC pattern.
You know what? Zero of them will succeed in all of your tasks. And, dear reader, if you claim that you will then you are lying.
You know why? Because testing like this doesn't reveal anything. I passed University with top grades throughout because I knew how to bone up for an exam and cough up the syllabus as requested, as well as having a moderately mathematical head. I can demonstrate prior performance and I can grasp new concepts. I can remind myself quickly of old concepts when given access to a reference.
But I don't have some magical savant-level ability to memorise everything I've ever done (and, experiments on savants suggest, if I did then I'd lack the skills to apply my elephantine knowledge to solving general commercial development problems). It's never hindered me. This sort of ability might be necessary if I were, say, a field intelligence agent(?), and not being able to concoct the right deception within a subsecond time interval might result in my death. Otherwise, it's just a dog and pony show.
The most worthless of technical interviews. Absolutely meaningless because it doesn't address the true core competency necessary of a programmer - problem solving.
I write in a slew of languages, but I do more day-to-day in just one. It doesn't take anyone who has broad experience to jump between languages and platforms so the "manual memorization" interviews are worthless in these cases. A couple of general questions would be appropriate to check for padding, but a question like "name the 4 different values that property X can hold in language Z" is completely worthless (I actually got that question once) because that information is available within any decent IDE so memorization isn't required.
Knowing what you want to do in an application and designing the solution is the important part. I think too many technical interviews turn into massive "gotcha" sessions where the interviewer wants to look like a guru, when they have had plenty of time (and resources) to look up their own answers.
So, when I interview candidates, I ask them questions about solving problems while brushing up against technical details. This allows me to gauge how they think (or do they just type what are told), and if they understand the technology terms.
A good Java programmer who has done some PHP and can solve problems like a champ, for example, will quickly make the language transition, but may not answer correctly all the "gotcha" questions.
Hire a good thinker. The rest will take care of itself.
Ask the candidate to give a short presentation on a software project they worked on in the past. they can describe database design, frameworks used, reasoning behind programming environment choices etc. You'll get a good feel for their technical knowledge, grasp of a project and communication skills. Have someone in the interview who can throw technical Qs at them from time to time.
Simple! Put a minute on the clock and see how many acronyms they can regurgitate. (Any overachievers must be handled with caution, since there is a high likelihood that they are gunning for your job.)
Technical ability isn't going to help nearly enough if they don't understand software engineering principles. What SDLC methodologies have they used? What do they like and don't like? What source code tools do they like? What is Brooks' Law? How do they work with QA? Have they supported software they have released or has it gone to another team?
And understand their answers. Say they don't like the daily Scrum in their AGILE environment. Why? Is it because it's pointless in that environment - no real problems are addressed, brought up, no code is reviewed, no items gone over? Or do they just find it boring?
Technology is important. It's also important to have engineers and not programmers. 10 times out of 10 I'd hire and engineer with proven SDLC experience without the specific experience in the specific technology at hand*. My experience is that having an engineer that uses and respects the processes in place is infinitely more valuable than getting someone with mastery of the technology.
*Within reason. I'm not hiring a LAMP expert for an embedded C job, but hiring a LAMP expert for a web-based Java job? Yeah, I'd consider that.
Get one of your most curious and bright engineers to interview them with a view to answering the question, "Do They Have A Pulse?"
That, and team fit, are better predictors of success at your company than any of the other stuff, in my experience.
Development tests are very useful in that they can give you an idea of how someone works and what kind of quality to expect. Tests can be done in house or you can let them take them home if you'd like.
Provide a set of tasks and ask that they provide, for example, brief technical documentation, the code, database schema, and anything else relevant. Intentionally provide a task or two that doesn't have enough information - see if they ask for clarification (good thing) or just make up whatever they please (bad thing) and see if it is what you wanted.
Love sees no species.
The whole idea of LAMP is that it's an easy-to-learn, easy-to-deploy stack. Any competent developer should be able to learn this, quickly. Even if you could assign a "LAMP Competence Metric" (say a 0-10 scale) to a person, a competent developer who is a 2 in LAMP will be a 9 much more quickly than an incompetent developer who is currently a 6.
When I hire coders, I like to see how quickly they can understand a system via standard UML architecture diagrams. I like to see if they can implement a basic logic task using their choice of language, and I want that implementation to be straightforward, and I want it to use the coder's chosen language's foundation libraries instead of reinventing the wheel.
I also like to get a feel for how experienced they are in working with any of the various system development processes. (Hint: "What's that?" is a bad answer. Cowboy Coders are unwelcome at my company.)
Regarding testing basic computer science concepts, I like to ask candidates to differentiate one thing from another. For example, given your list of concepts ("BNF, data normalization, OOP, MVC"), I'd ask:
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Given how you and perhaps your organization seems to work, you should just look for developers who are good at going to forums and asking other people for advice on how to do their job.
I'd be pretty dubious of a PHP programmer with a cert. You probably just want to know if they can think. To that end programming exercises are good. Just give them a fairly simple task and 2 hours or so. For LAMP, I'd probably just ask them to build a simple CRUD contact management app. Just ask for FIRST_NAME, LAST_NAME, and EMAIL. Allow them to install tools they need.
This tests that they can:
1) Create a table
2) Create a web page
3) Know the proper times to GET and POST
4) Know SQL syntax and how to used prepared statements for SQL injection attacks
5) Filter their variables
And bonus points for:
1) Install PEAR or other 3rd party libraries for database abstraction, templating, etc.
2) Write unit tests.
3) Use Ajax properly for all operations.
Lots of people have said: "have them design a trivial app". My experience is that a) a trivial app will be so trivial as to tell you nothing or b) take so long as to be unreasonable for an interview. It is a good idea in principle but hard to pull off. Something you could try is think back to the hardest exam you had in school what was a good problem on it. Try maybe: Write a derived type for use in this way... plus test cases, plus documentation. But ask talk with these folks do a code review together on a sample of their code/design review on a page of their's. Give them a short synopsis of a problem you had internally (and solved) and have them lay out a plan of attack. Check their references; good references can tell you a lot. And remember a probationary period is important too because an interview that lasts three months rather than a day is going to tell you a lot more about their work habits, coding style and ability to work with your team.
Oh yeah and like most people here are saying... most certifications in technology mean nothing more than the certified has worked at a job where the boss bought into the certification scam or they have too much time on their hands.
Comment removed based on user account deletion
Give them a bug, in your real software product, that traces back to an operating system level setting, and does not initially expose this in the error. (for instance, say max. open files is set to 20 on the box, and a php script opens 100 file handles and doesn't close them) Tell them to trace this, and suggest a fix, and give them a couple of hours. If you can debug an environment you don't know, it proves that you're able to understand new concepts, and even trace weird bugs in them. Any monkey can program PHP, anyone with enough time can get a degree, not much guys know how to find a bug properly and fast.
Quack damn you!
They show you can pass a test. Further, depending on them to gauge people's knowledge indicates possibly that the folks doing the interviewing, and CERTAINLY the HR department, have no idea what they need, or what might show someone is qualified, and is used in place of actual knowledge of what is needed.
HR departments, esp., are 90% (at a guesstimate, based on my personal experience, and from my friends and acquaintences) not merely utterly ignorant of what they're hiring for, and so have no idea what transfers and what doesn't, but don't *care* to learn (which would let them do their jobs better, and be better for the company they work for).
Come the Revolution, we won't waste ammunition, we'll lead the HR depts into the parking lot, throw asphault on them, and *pave* them into the roadway.
mark
lol...
Just because the U.S. is a republic does not mean it is not a democracy. Democracy/republic are not mutually exclusive.
Put the candidates into a dark room. The first to turn on the lights has demonstrated lamp competency.
Give me Classic Slashdot or give me death!
Certifications are for: ...
1) Making employees feel loved and as though the have 'leveled' somehow. Job satisfaction etc
2) Getting people raises when required by HR.
3) Locking talent into a vendor's product. (Give a guy a certification and he will be pidgin holed into a technology and an organization will fill itself with narrow but deep talent with a single product and be collectively afraid of every moving away from said technology.)
IOW, _don't _ use them to assess knowledge or mastery of something.
Make a team of people who are mostly peers to the position.
Give them the opportunity to ask questions of each candidate.
Give some members who care extra time to ask tough questions inside their area knowledge.
IOW, you should have talent.
Describe what role this person will fill and let your team vet them.
That works.
Sit them in front of a nice clean virtual machine and tell them to get a basic PHP page up and running. They have to install apache/php/mysql. If you want to cut down on the time, download the stuff first. Should take about 20 minutes.
-- A cat is no trade for integrity!
Comment removed based on user account deletion
Ask them questions to see how their mind works. Are they good problem solvers?
Dev tests are a waste of their time and an insult, certs can't be trusted, and even prior experience can be faked. Maybe "helping launch a high traffic website" involved user acceptance testing and someone else of their team actually wrote the backend java app for handling searches (I've seen that level of fibbing).
Meet them in person and ask yourself:
Would I enjoy working with them?
Do they approach problems in an intelligent way?
etc.
Most people in Computer Arts that are truly gifted, tend to not do a typical interview very well. If you ask simple questions that EVERYONE should know, they tend to fail miserably. Why? Because they do things so much they don't have to think about these things EVERYONE knows.
What I tend to do is get someone talking about what they like to do most in Computers. Someone that is truly into computers, love to do side projects, and love to solve problems.
Ask them what computer system they have at home. If they just say, I have a dell. More than likely, they are not THAT into Computers as an art. If they go into detail of what ram, etc. then they probably like to dig into things a bit.
Ask them about what they do on the side. If they talk about getting into various open source projects. Most Computer art people tend to talk excitedly about different projects they worked on and how they solved the problems they ran into.
Finding truly gifted Computer Art people is usually different than finding people in other departments.
Scott Carr
I interviewed earlier this year with a company looking to hire a developer. I have plenty of experience with the language they wanted, and they gave me a "live programming test". In a conference room, with the whole dev team in attendance and asked me to program in front of them (on a projection screen for all to see). There was no warning at all this would take place. This was the single worst experience of interviewing in my life. I made mistakes I would normally have never made because I really needed that job, a lot was on the line, and my brain would not switch to programming mode. While I can consider that to be a (possible) test of how you perform under fire, I really don't see how it applies to someone who sits and programs all day long. Even peer programming won't bring around that level of stress, not even close. I did end up getting an offer, but I turned it down since I happened to get a better offer at the same time, and that whole test left a bad taste in my mouth.
Bottom line: I really don't recommend doing a test such as this, there are plenty of conventional methods available for determining someone's proficiency. Ask to see code samples, give tests (that are judged afterwards), technical interviews; all of these are better options..
Ask them if they truly love LAMP or if they're just saying that.
For your security, this post has been encrypted with ROT-13, twice.
I used to do a lot of hiring for LAMP resources and found that often, someones framilarity with any language had little relationship to their ability to troubleshoot and debug code. If you are looking for project work with clearly defined objectives and deliverables (what IT project is EVER clearly defined) then LAMP proficiency is good enough). Peronsally, like to give them a busted website running on an issolated VM and two hours to fix it. They can have google, and whatever reference material they need and ask any questions they want. To torture them, do everything from messed up permissions on directories, bad apache configs, bad code, dynamic code, wonky databases, and bad SQL Queries. See how far they get but also how they troubleshoot. What do they prioritize first? Do they write quick scripts from the command line to test database connectivity? The goal is not to get the website functioning but to see what they fix, how they fix it, and what priority they placed which pieces.
-- Kind Regards whtdrgn101
... what you think it does.
Metrics.
Your question is something like:
Can I create a metric using certification as a variable that is correlated with ability to do the job?
I don't think you really want to do that.
You could with a lot of data about employees and try and do something like do a regression analysis and compare the 'has certification X' variable to the likelyhood 'employee X' got a good performance review.
That would give you an equation that would tell you if cert X was positive or negative correlation... ... but that is a lousy idea. It is going to be a lousy variable. You have a lousy sample size ... and the bias is going to be huge and nobody should give you that data.
You don't want a real metric, you want to ask a person questions and make assessment of how much of what you know he knows and delegate to other people to assess other areas.
I've often wondered why employers don't bring a laptop into the interview, with a simple programming task or two, and ask the programmer to write a program that does X, with access to all available tools, the internet, etc. You'd be amazed at how many "experts" cannot do simple things like open a file, read from it, append a character to the end of each line, and print it back out. Or, do generic bubble sort (not to mention q sort or other, more advanced methods).
A small test would be a much, much better demonstration of skill than asking people about random concepts. I would say the ability to look something up, quickly comprehend it, and then apply it to a real world problem is of much more use than a guy who has memorized (but does not understand) a bunch of bullshit.
Or any other form of web development.
Right...because nobody puts out web applications, right? Everything is client-server, with specialized pieces of software that have to be installed on every endpoint. It's not like mail, CRM, or even the configuration interfaces of network devices have any kind of web-driven front-end...although, even if they did, I'm sure the code needed for that functionality would write itself.
For your security, this post has been encrypted with ROT-13, twice.
Which part of that, specifically, do you find offensive?
It's not offensive so much as funny.
You don't, by chance, do any web programming do you? If so, what's the URL? Just curious is all...
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
I didn't say that.
I merely stated that such tasks were relegated to people with next to no competence.
are formed by a review of work already done and peers.
Check the persons peer list and work already done.
If you like what you see hire him.
If you use certifications, university diplomas as a governor in the process you corrupt it and you deserve what you get.
-hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
If you don't already have someone on the interview panel who possesses in-depth knowledge of the required skills, then good luck to you sir. I have interviewed candidates for jobs in Information Security with masters' degrees in comp sci who were nothing more than glorified GUI-slingers.
Did you ever wake up in the morning, with a Zombie Woof behind your eyes? -- FZ
Hire them on a 3 month trial / evaluation contract... if they are good keep them.. if not dont renew.
There is also a candidate with a good portfolio, a lot of experience, and no certification.
I don't know this guy but I'm sure he's extremely well qualified for the job and you should hire him ASAP because he's about to miss another mortgage payment.
At my last job, they sat me down in a conference room with a laptop that had the wireless card yanked. They gave me a piece of paper with some database tables and asked me to write a web app that would let someone add, remove and view entries in those tables. They gave you 45 minutes to write a working web app, in the language of your choice, with no outside references and no way to actually run of test any of the code. Along the way I noticed that they had a couple errors in their schema.
We got to talking after the assignment was done and apparently they had been using that hypothetical DB for a long time and nobody had pointed out and fixed the errors. I found that amazing, so I asked how many people had actually finished the assignment. They said that nobody had given them code that actually ran, that there was always a syntax error or plain old typo somewhere. They went on to say that they didn't really count that against anyone since they wanted to see facility with the language of choice, coding style, general knowledge, ability to work under pressure, etc. So I had to ask: "Uh, did my code run?" And it did.
I don't know if it's because of the way I write code or because I've been doing it for a while, but I was just totally blown away that nobody they had interviewed could come up with 400 lines of code that actually ran. They had dudes with advanced CS degrees who couldn't write a simple web app that worked. It's mind boggling.
At the time I was a little scared of the interview process (the practical part was only 1/3 of the total interview process). But I think it's a good method.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Looking for certification is a red flag that there is something wrong with your interview process.
Neither HR people nor (non-technical) managers can determine if a candidate is qualified for a technical position. Only another technical person will be able to tell, either by asking probing questions or watching the candidate write some simple code. You must have a technical person present at the interview.
If you are looking for certification, that tells me that someone non-technical (or even worse, a computer) is trying to weed out candidates. Why should the weeding out be done by the people who are the least qualified to judge the technical skills of the candidate? Choosing the best few resumes and weeding candidates out through phone interviews should be done by the technical members of the team.
My experiences have shown that familiarity with only specific technologies (blinders), having certifications (read a book, but trying to impress), and previous education (we use to make efforts long ago, but please hire me now) don't really show anything, usually...
So I'd say, don't measure LAMP competency at all, or even the # of certificates they possess. Instead, during the interview process, ask them questions like the following; which help get to the "meat" of it all.
1) Are you comfortable learning new things? ...
2) If you are hired for this position, how would you go-about "getting up to speed" with this development project?
3) Explain: Modularity, Encapsulation, Tiered Application Design, OOP, big-O, Security Concepts, GOF (Gang of Four), UML, Unit Testing, Fault Injection, Caching, etc.
4) What kind of work do you find interesting?
5) Being faced with a code issue, what sources of information would you turn to in order to troubleshoot and ultimately resolve?
6) During a code review, you are presented with a function/method 5,000 lines long. Is that a reasonable length and why?
7) You have a general utility function that is very handy and could be used in many places / projects. Do you copy/paste as needed, or place into a common library?
8) What is version control / configuration management software? Why would you use it?
9) Your manager has asked that you add a SpellChecker to an HR Personnel application. You found an external web service that allows you to send text to and retrieve spelling errors back. Why might using this external service be bad? [Extra Dependency To Maintain, Security Problem, etc.].
10)
I didn't say that. I merely stated that such tasks were relegated to people with next to no competence.
But they shouldn't be. That's why you have so many problems with SQL injection attacks, for example.
Now, aesthetics of a site should be left to artists, but if you want your code to run right and be reasonably secure, you really need a software engineer doing your PHP implementations.
LAMP and competency should not appear in the same sentence.
How many candidate engineers does it take to change a light bulb?
but some people go out and get the certification so they can get past the HR droid
Yes, this is a massive problem. In order to get to the face-to-face you have to go through the screening process. This is normally carried out either by the HR trainee or, worse, by a recruitment "consultant". All they've been given is a tick-box of "must-haves" (i.e. a wish list of tangible qualities) and told to go through a pile of CVs.
All they'll do is toss the ones which don't meet the criteria.So you can be the best LAMP-er in the world, but unless you have the random qualification that someone though might be useful you don't even get a chance. So while certification bears no correlation to usefulness in the real world, it's a necessary stamp on your CV to get you through the door.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
I was interviewed once for a job where they presented me with a page of C code and asked me to find any problems with the code.
They didn't like my answer and needless to say I didn't get the job:
Code Lacks structural cues
Code Lacks meaningful naming of: functions, variables, constants - barring this, code lacks comments to explain (nonsense) names
Code contains functions and constructions written such that it appears someone is trying to be "clever" instead of clear - some embedded compilers (of the time) may prefer these mechanisms, if required for efficiency these constructions should be commented as such
Review of Code was shoddy or non-existent
Solution: Train or fire the programmer and rewrite the code.
I have encountered so much code like this before and since - you can use a refactoring methodology / unit tests / whatever you want but trying to shake a bug out of code written that poorly is not economical.
I just hire people that are smart, good problem solvers, and seem to have a personality.
.. talking to them helps. Find people who are curious and ask questions rather than say 'mememememe' in their interview. Ask them about tough problems they have fixed, and see if they know how to do problem isolation. See if they have a general knowledge beyond development, a developer who knows nothing about network bandwidth utilization or database storage is useless unless you are just going to hand him finished specs and want a code monkey.
None of that other shit really matters. Someone who is smart, works well with others, and is a good problem solver can pick up anything without all that formal training and will probably be better at it in a few months than someone who is an average developer.
How to tell if someone is smart?? Well
Explore how they learn new technologies. Do they take a class, or do they go buy a book/research online and 'play'. If they are presented with new technology, do they respond with 'I don't know how to do that' or 'I don't know how to do that, but give me a couple of days'.
Let someone else hire the programmers with a lot of letters after their names, find the truly good ones that are too busy doing shit to take a class or get certified.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
I'd hire the guy that smells like weed. Then I'd ask him: "Hey new guy, you gonna keep all that weed to yourself?"
Here is a simple question that tests a wide degree of SQL knowledge. I have the table drawn on the page with a number repeated. There is a single table with a single column. The table has 5 rows, 3 rows have different entries and 2 have the same.
Write me a query that shows all values that occur more than once and the number of times it occurs. (The correct answer is the duplicate value and 2.)
The have 60 seconds to write the query. If they cannot or are majorly wrong, then they don't know dick about SQL. Any 12 year old hacker can do a select statement or a INNER JOIN.
To all the haters our there, yes this is relevant if you have ever had to clean 33,000+ rows of data for an insert.
if you cant answer this question yourself; why the hell are you involved in the hiring process?
Dealing with SQL injection or XSS certainly doesn't require engineering expertise. It only requires common sense.
You need to encode data in a specific way to embed it in some other data which is under a specific format under which some characters have special meaning. The fact that most web developers don't even understand this -- or just barely enough to apply it to SQL injection and XSS because they've been told to -- says wonders about competence in the field.
Because I believe strongly that the truly competent are doing LAPP. In my experience MySQL's a freaking code cowboy magnet.
My favorite thing to try, is start a new lamp amazon instance, start up apache, load up a few virtual hosts, with some random webpages in each. Give the applicat root access to this testing server and tell them to make a few changes to files in each of them (requiring a few changes to various php configs in order to accomplish it)
Competency against MySQL does not compute.
As a programmer, if I were to pick someone to work with me, I would judge him by:
In an interview I would just look for bad hygiene or a really obnoxious laugh. I might be able to talk with them and get some impression of their working style (minimalist (like me), blustery formalist (bad), pragmatist (better), etc.). But I don't think I could decide just on an interview whether they're good, or if I myself could show in an interview that I was good.
But it is dead easy for me to judge a programmer if I saw a few functions, database queries, etc., that they've written. Such would show the answer many interview questions, including ones that would be hard to word and easy to lie about. If I had my druthers I would like to see a lot of code --- several files, maybe even a whole app. That would tell me more than any other what level they're at and also whether their taste clashes or matches mine (and so we would work peaceably together)
If I was asked to do something at a job interview and did not have my FireFox start page with links to my local documentation trees for Java, links to web documentation, megabytes of carefully ordered IBM PDFs, my O'Reilly books over my shoulder in my usual arrangement, etc I would be hard-pressed to do ANYTHING. Plus remember professionals have a LOT of code they go through - I don't usually remember how to do something, but I know I did it several years ago and still have the code that did it. A programmer in a normal working context is going to be a lot different than one under a microscope in an interview.
My favorite example of this sort of thing is length of a string. I have to look this up all the time. Is it strlen() (C, PHP), length() the function or len(), string.length the property, string.length() the method, string.len, string.len(), etc? After you have used C, Java, JavaScript, PHP, Python, and Perl for a few years, how could you ever remember stuff like this?
And asking people about Apache or Tomcat without reference material is criminal. Tomcat is the most bizarre, insane thing I have ever seen. Apache isn't far behind.
You are asking if there's a way to optimize the outcome, that is, the persons you hire were the best ones to higher and the ones you rejected were the best ones to reject. Can't be done. So make your choices and take your chances. Go strictly by paperwork (cognizant that the mercenary and mediocre may have gotten their certifications to improve their chances at the first cut.) Or, take all the time and interviews needed to find out which quadrant the applicant belongs along the Know-Their-Stuff / Pleasant-To-Work-With Cartesian axes.
There are no guarantees. Mistakes will be made.
I think every company deals with that same dilema, especially when the base language is PHP. I've found there is a vast range of competency with PHP coders, which I believe is largely due to these tech colleges cranking out graduates with barely enough skills accomplish a task, let alone doing it more efficiently with layered logic. I myself have been coding using PHP for 10 yrs+ all with MySQL or PostgreSQL as the backend, and not to be boastful, but have used about every possible method, tricks for improvements, and know all the possibilities forwards and backwards. I do not however have one of these certifications, or even knew they were really available or widely accepted as credited. Despite the lack of being certified, I have designed, built, and maintained literally hundreds of databases over the years, as well as acted at the DBA - although I'm far from a DBA (I do know my strengths and limitations LOL) and could only manage to do some simple DB optimization, clustering, replication, and what not.
If I were to be one of your applicants and you did choose to require or gave great credit towards those who were certified, then I would likely be passed over. I believe that you'd find it more common than not that applicants aren't certified. I had plenty of occasions being both the interviewer and the applicant, which in my opinion the most effective and least time consuming is to come up with a case scenario problem and have each applicant solve it right then and there - before even any discussions or name exchange. 8-) Have it require the code solution, the DB schema, and freedom to use whatever modules, tools, or whatever they are comfortable with. It's important to make the problem presented something that could be done many ways obviously, as well as have a most likely lesser known slick solution method. This way you get a chance to see their coding style, ability to problem solve, knowledge of solution techniques and methods, design and logic, practical application skills, and even formatting and comment habits. I believe it's better than just code samples or viewing previous work, since it's directly applicable to their current state. Plus you can talk about it after, with questions of why did you choose this method, and whey structure this into these blocks, etc.
The interview process may take quite a bit longer, but not for you - the company hiring for the position. For you it just takes an available cubical or room with a basic computer, or even just paper and a pencil will work. I know there are some problems or task available out there that are designed exactly for this purpose. There is one involving a mechanical clock that uses steel balls and a series of chutes that you create the software version of that is pretty good. Any way you look at the hiring process, it isn't much fun and you don't get a very accurate idea of exactly what they are capable of until you see them in action, which this is about as close as it gets - short of a trial period hire. LOL
...that's an oxymoron.
Note: This is not about the bragging rights, but it definitely comes off that way.
I've been developing web apps from roughly 1996 through current. I can write effective clean non-exception throwing OOP code in nearly any web oriented programming language you'd like (minus JSP or Ruby, skipped these entirely, though I'm sure I could troubleshoot that stuff just as well as most developers dedicated to those environments could). For 7 years between 2001 and 2008 I've been doing 90% of my work in LAMP, WAMP, or WIMP or whatever variation of 'PHP & SQL' you'd like to pick. When MVC frameworks like Codeigniter and the later spinoff Kohana came out, I already had my own version that I used for myself developed 100% by myself being used. I'm not claiming to have invented MVC, and actually ended up switching to open source MVC frameworks away from my own development just because of the support and community (and some of the stuff was just flat out done better than my own version). In the last 3 years however I've switched almost entirely over to ASP C# MVC (and now ASP MVC 2). Same for javascript and javascript libraries (jQuery & Mootools have been popular requests from clients lately). All the flash stuff, actionscript, flex, whatever. SEO and content syndication in mind..
Sheesh I can go on forever. I don't think there's much in web that I can't do, and do decently well, if not better than most people I run across. /Headexplode
I'm sure there are plenty of people out there who specialize in one area or another that are exceptionally better than I will ever bee at 'XYZ' langauge and environment, but my biggest selling point when doing an interview for a consulting gig is that I can or have at least tried to 'do everything'. Most firms that I do work for LOVE the fact that on monday I can be working on X client's drupal website in PHP/MySql, and on wednesday I can be doing maintenance, updates, and cleanup on Y client's website in an ASP C# (Non MVC) environment, and thursday sit in on a board meeting as a technical consultant with Z client who wants to spend a bunch of money on SEO, SEM, and SMO improvements to their web presence. My background in 'web' is extremely well rounded. I am a web developer, not a ______ developer. Its my own very strong opinion that if you're going to work in 'web development', you need to know as much as possible about past, present, and in all cases 'upcoming' languages and trends.
The best thing about my resume too is that, well I don't have any certifications or college 'training'.
This is just my far sided opinion and take it for whatever you want to take it as, but: If I were hiring a developer to work on any of my websites, and he or she came in boasting about any college or certifications, with little to no portfolio, I would not hire that person, even if it meant that I had to hire no-one at all. Unless it was for say, a no brains maintenance or data entry job (Here ya go, go put these 900 photos on the website, and if you do it manually and it takes more than an hour just go home).
Certification/Degree only to me says that this person saw someone like myself and the amount of money I typically pull in, and got into this field exclusively for the money potential.
If you're going to hire someone, hire the ones that are (in this case) LAMP developers because they LOVE web development. They LOVE their career. They LOVE troubleshooting and fixing (website) things. They LOVE learning things. Ask them how many O'Reilly books they own and what their favorite source(s) of information are online for when they get stumped. Ask them how many other web developers they know, and what the other web developers they know are doing. Ask them about their hobby projects or about anything they're working on in their spare time. Ask them what their favorite language is and why? Ask them about their opinions on X and Y trends. Do you like flash, no? Why not? What's your stance on HTML5? How do you propose integration of HTML5 contents on new
OK, I'm an old-timer, and when I was working in the field, it was mostly as a generic embedded-systems or C-programmer. I see some prim replies to the 'pounding on the table' bit about how they wouldn't work in such an 'unprofessional' environment. Well, back in the wild and wooly 70s and 80s and even the 90s, the unprofessional places could be the most fun! I actually got to go to Cape Kennedy and put my hands on a real space shuttle while working for a very small 'unprofessional' outfit. I never had an interview with the pounding on the table bit myself. My favorite interview question was when somebody said they wanted to test my comfort level with C. They asked me how long it would take to write code to do something. I forget exactly what, but it sounded complex at first but after a moment of thought, I realized it was pretty simple. It took me a few seconds to get up the nerve to say 'about half an hour' (I was really thinking maybe 5 or 10 minutes) because I kept thinking I must be missing something. But when I said it, the guy just nodded his head and said 'OK'. That was basically the whole interview. (I didn't take the job because I was waiting and waiting for the company's bureaucracy to get me a security clearance and in the meantime I got another job for more money.)
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
You could try job simulations like this one: http://www.hirequality.ca/jobsimulations.html, seems to be something that could scale more easily if you're looking for multiple positions and/or a lot of candidates.
The difference with PEs and MDs is that they have legal liability for their work. When a PE signs off on a document, he or she and their firm have professional liability for the correctness of the design. The same is true (in a slightly different sense) for MDs. I've never been a big believer in software certs, although they are a way of measuring someone's focus in completing the project. Also useful at big companies as a way of training and measuring progress. Not a substitute for a good degree and relevant real-world experince in a well-managed team. (The worst offenders are cowboy (or cowgirl) coders who have no team experience or who have just worked in a one- or tw-person team with another cowboy.
Look for good team experience.
transfer rates slow - how do you not know its a problem with the network ? ddos attack, dodgy nic,cable and or switch port - exactly why you think an average lamp stack programmer would or even should be able to fix that?
That's it. Get that and google them. I am business_kid. You will see in a second where I hang out, what sort of interests & knowledge I have. Certs are no certainty - they show a professional. But I knew a mechanical engineer with a good degree who was in reality only a 'biro engineer'. He could talk a good job, but niot do it.Previous work measures flair. A short test is going to have to be be too short.
Sure, in real life, people do yell at each other.
However, even with "explaining the role-playing model", yelling at a woman during a job interview is dicey. Be smart - don't do it, even during an interview. Interviews are more stressful than "real life" to begin with. And doing it later on, on the job, could end up with you either in the hospital (when co-workers intervene or you get maced) or in court.
So, what are you going to do? Just shout at the guys during interviews? That's sexual discrimination.
Here's a thought - conduct the interview in a fashion that communicates that you want the opportunity for both of you to get to know each other better professionally, to decide whether it's a good fit.
Hazing recruits was supposed to have gone out years ago.
Back when I was 22 and just out of school (in the 2002 recession) was sending resumes everywhere. this one company sent out a programming challenge via e-mail. I don't remember all the details now, but it was in a language called "J" see http://en.wikipedia.org/wiki/J_(programming_language). I think it was taking a bunch of numbers from a file and doing some quick transformations, then printing the output. The program was trivial, however it was in J. Anyway it served to filter out people who didn't want to learn anything new. Even if you hire a PHP/MySQL expert, they still have to learn the firm's business requirements. Also things always change, if you go from PHP to Perl or ASP.NET will you need to fire them and hire new people, or can they keep working for you?
Anyway the company had hundreds of applicants but the challenge narrowed it down to 10 or so which they invited to an interview. They also said they liked my solution more than all the others because I bothered to change the decimal precision to get the exact output they put on their sheet, instead of just the answer in the default output....Sadly I got lost and never made it for the interview...Oh well. But I'm sure whoever they got was competent. I definitely could have done the job.
Anyway after working with graduate freeloaders on group projects and 3 companies professionally for 7 years I can say that what you need to do is push people out of their comfort zone. Find out if they are willing to learn something new. You should invent your own programming language, and give that to candidates to solve a (trivial or nearly trivial problem). If they cannot take the time to learn your simple language to solve a trivial problem, do you think they will take the time to learn the business requirements for a piece of software? Also say you hire a PHP expert, what happens if you like Django/Python more.....do you need to fire them and rehire them? Also I'm not sure what level candidates you are hiring. But a typical university education does not teach you PhP, OOP (nothing more than an object holds procedures/data), etc.. Also normalization depends. But it is really simple to learn if you don't know it. I always confuse the ones after the first 3. So I refer to a book/web page but the concepts are easy enough. Still does a typical web jockey need to no normalization (especially if you employ a DBA already), probably not.... Even for a normal corporate database you probably don't need more than 3rd normal form. Still the more advanced ones (at least Boyce Codd and 4th) are easy enough with a book. I wouldn't hire or not hire someone for that. I'd much rather an open mind and willing to learn.
You, as many managers do, are overthinking the hiring process. It sounds like you have some good prospects. Interview them. Take them to lunch. Hire the one you like.
This is not a marriage; it's not forever and it doesn't need to be perfect. If the person you hire has skill deficiencies, there is something called professional development. At least you've hired someone you like and that fits in. Right?
I just talked to a headhunter. The job description was three pages of requirements for what I considered a mid-level position. I am overqualified for the job, but I didn't meet the requirements, which sounded as if the hire would be performing brain surgery via robotic avatar on a nuclear powered rocket -- in flight!
I get a little tired of reading that I need 7+ years of solid, demonstrable experience in C++, Unix, Linux, Windows, Mac OS, PHP, mysql, postgresql, oracle10, python, ruby, java, .net, javascript, xhtml, css, h.264, Photoshop, Flash, Acrobat, Word, Excel, Powerpoint, Lotus Notes, Drupal, Zend, cobol, fortran, basic, punch cards, hypercard, abacus, etch-a-sketch, basecamp, social media, twitter, Premiere, Motion, Pagemaker, as well as the abilty to manage projects, budgets and people while changing the wheel bearings on the company travel trailer -- all for the stellar salary of $45k!
Don't be the jerk that writes those kind of job descriptions and tries to hire only the person that fits the bill exactly. Because I can tell you from experience: Not only are you a jerk, but you'll be working with one, too.
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).
I ask them one simple question. How well do you function in hostile environments with passive agressive managers, virtually no mature processes, and colleagues that will not answer your emails, phone calls, or pleas for assistance?
Not a necessary stamp on the CV to get through the door, by far.
Atleast not in web development anymore. It used to be, but that's not how it's today.
Pulsed Media Seedboxes
I guess you missed the part where I said "My interviews were more for sysadmin stuff", so they would be applicable to folks I hired. I'd have other questions for LAMP developers, but I didn't have any examples off the top of my head.
Serious? Seriousness is well above my pay grade.
chmod -R 777 / solves everything. What I need is a version of chmod that works across the cloud. cloudmod -R 777 /.
Plus shorter passwords make the system work faster so a password like 'a' is way better than 'KJH*&^hgjhg232gjhGj7'.
If you need something to CYA, then get someone with a certificate. If you got hired because of certificates, then hire someone with a certificate. But make sure they don't have one as good as you or better.
In larger organizations with HR departments, one needs a token to pass the hire-wall. That token is a certification, or a degree. In places where department heads do the screening of resumes, a cert is not so important. But the hotjobs-craigslist jobvertising trend has made it so any decent position will inundate the hiring person with tons of resumes, most of them not even remotely suited for the position. Back when people had to buy a stamp and mail a resume, they were more thoughtful about where they applied and there was less of the hiring person's time wasted.
Perhaps what is needed in this day and age is exactly that: advertise, but tell people to snail-mail their resumes in. Sure, postage is a small cost for someone who is even remotely serious but those who consider it a 'long-shot' won't bother.
give me $30k in consulting fees and i'll tell you who to hire.
Linux Apache Middleware PostgreSQL -- a brighter LAMP.
Women? Dude, you're talking about a Network Manager interview...
You're moving in the wrong direction with that sort of interview anyway. If you want good developers then you need smart people. Smart people don't always test well but if your interview is comfortable and encouraging and you focus on hiring good people rather then good developers then you find yourself with a team that can learn anything new, conform to current company standards and are more pleasant to work with.
Frankly, it's been my experience that companies that interview the way you're looking to go are often staffed by very educated idiots. If you're looking for people who really know their ABCs but can't write a sonnet for the life of them then standardized testing is certainly the way to go. My team has been careful to not go that way and we have managed to put together an incredible group. Granted we have people who range wildly in knowledge and expertise with regards to LAMP but all of them are eager learners and honestly I could careless if they know why something works or why it's a better practice. As long as they do it correctly.
Asking anything more than "can you recommend a good place to start" is not helping matters. In the future generations, the ability to execute cogent Google searches will be more important than actual experience.
Anyone pruned from the interview process because they (quite correctly) thought "ask for help" is a reasonable response, owes you a Thank You note. I shudder to imagine what it must be like to maintain the existing code base in such a place, where half the implementation is wedged-in copy-pasta sample code snippets from whatever web sites.
- T
Hmm, captcha is "roulette", as in "What your rejected applicants have won at".
Dealing with SQL injection or XSS certainly doesn't require engineering expertise. It only requires common sense.
You need to encode data in a specific way to embed it in some other data which is under a specific format under which some characters have special meaning. The fact that most web developers don't even understand this -- or just barely enough to apply it to SQL injection and XSS because they've been told to -- says wonders about competence in the field.
Ah yes, the "Nerd Hierarchy".
marketing < sales < finance < sanitation < management < support < web developer < gui developer < software engineer < "real" engineer < whateverthefuckyoudo.
Your ego is only surpassed by your ignorance and the laughs it brings.
My technique is to generate discussion about an array of "basic concepts" (not BNF for this case, though) plus any concepts specific to the position, and anything on the resume should be fair game for detailed discussion. We've used this approach to get a reliable feel for whether the applicant has a good foundational background, and whether the resume holds any misrepresentations. For example, we had an applicant for a Java development position who described his involvement in using AOP in a Java project on his work history. When asked about it, he deflected; he couldn't even answer very basic follow-up questions on AOP, let alone using it with Java. I didn't expect him to write some example AOP/Java program on the spot without outside references, but he should have been able to talk intelligently about it and describe his prior work on it (barring some NDA).
As to BNF, I can't see why it's in the list, at least not for a PHP/MySQL position. It's useful to know if you're learning a new language and want to review the BNF. I could certainly see it being relevant if the job involved language design or implementation, maybe even for a position where developing DSLs was a key task, but not for the position described in the summary.
- T
Never have mod points when I want one.
you had me at #!
The last place I worked at, it was unfortunately an every day occurrence.
My last job was like that, he yelled frequently and at everyone. He even yelled at his boss, the company owners, and people from other companies. He was allowed to get away with it because he was the go to guy when there was a problem, he knew his shit. And though he yelled at us, those who worked under him, if you could put up that it then he would also cut you some slack at tymes.
Falcon
Should there be a Law?
I don't know a single workplace I've ever been in where someone acting like that wouldn't be disciplined or fired.
My boss at the last place I worked at yelled at people frequently, even his bosses and company owners. They let him get away with it because he was effective at his job and he was the go to guy when a problem came up. Those of us who worked for him and put up with it he'd also cut some slack occasionally, it wasn't all yelling. However not many people could put up with his yelling. When I was laid off after 3 years I was the newest guy on the crew, but not because I was the last one hired, a few others were hired after I was but none of them lasted more than a few months.
If that happened now though I may just walk away, depending on how the compensation is and how bad it is.
Falcon
Should there be a Law?
Let's all play "spot the PHB".
Anyone who uses MVC/OOP and PHP in the same paragraph is just churning out buzzwords, without any thought to what they are asking for.
PHP is the ultimate NON-separated language, where you are allowed (even encouraged) to mix HTML, SQL and code all in one "script" ... why do you think there's a glut of PHP coders (and crappy, vulnerable PHP code) out there ?
I can't even begin to imagine how you'd implement MVC ... not without switching to a real language first.
I've actually seen one of our providing companies respond "chmod -R 777 /" as a solution to a bug we filed with them.
I've had a tech do `chmod -R 777 $HOME` to "solve" a permissions problem. Typical case of someone knowing too little and too much at the same time.
Of course, he auto-LARTed because once he'd done that "just to make sure", he could no longer log on to the server because ssh refused to use his authorized_keys :-)
I always look for communication skills, business sense, math skills, and yes, of course technical skills too.
And at least 5 years of experience, which I agree is not very community friendly.
If so, it's because they self-educate, and having done so at the start, continue. This quality trumps all others in time, and being unqualified can help this quality develop. But that's still unusual.
How to identify it? I usually ask a question at the start about the recent/upcoming versions of the language we use, and which of it's new features they expect will change the way they work. So in PHP I'm looking for a discussion of closures, late static binding, and maybe even traits/mixins -- things other languages have had for a while, and a conceptually strong programmer will be anticipating. This question usually identifies the best candidates at the start. It also gets you into their programming mindset, technical depth and self-education habits pretty quickly. If no answer, go on with pure technical questions.
It sounds like HR or the hiring manager doesn't have the skills to assess prospects. The LAMP stack hiring process is no different than hiring anyone else. If you don't understand what you are looking for, you post in forums like this one.
Although not techy, I had a stint as a Home Healthcare director and had ~200 nurses to keep hired. At first I went through their resumees with a fine tooth comb, grilled them, tried various weighted systems etc.. but after hiring 10-15 people I began to realize, especially in this women-centric field, the ones who performed best were simply the ones who got along. I came to realize, you can teach skills and procedures, but you can't teach fitting in. As long as they had the basic skills to do the job, the personality weighed more than anything else. Do they smile, do they look you in the eye, are they happy, do they talk intelligently. I got pretty good at picking out who would fit in and who wouldnt and after hiring close to 100 nurses only had 2-3 who didnt work out after the first couple years. A smart happy employee, regardless of certs and degrees, will take you a lot farther than someone who is a master of their trade and pisses off co-workers.
In hiring programmers, I would ask for an example of their work as a way to judge their basic competency. What is it, what does it do, and how well does it work. If they have no examples or only 1/2 baked ones, they are not driven and wont be for you either. After that, simply, will they make your office a happier place.
I know.. hard to quantify.. still.. hire the person, not the paper.
Codility.com screens job candidates for fundamental programming and CS. Won't help you much with verifying the understanding of MVC, but will definitely weed out those who cannot write solid code, raising your chances of not having to interview dummies.
There's nothing wrong with that...
Thanks for sharing your ignorance with us. Looks like you have not yet heard about HTTP header injection.